retro

The user requested aretrospective. You are proposing improvements to the coding agent'senvironmentto improve the experience of subsequent runs.

Steps

1. Call the Skill tool and pass in writing-for-agentsto get the writing style guide.

2. Read the primary source material for the session specified by the user. This may mean searching the session logs on this machine. If the user did not specify a session, default to the current one.

3. Look for improvable candidates in the following categories:

• Navigation: How easy is it for the agent to find the right files? Are there hidden dependencies between files? Anavigation pointerwould make things simpler? Use when the session takes a long time to find a piece of information.
• Automated checks: Are there automated checks that could catch mistakes the agent makes? Linting, type checking, tests, filesystem linter? First read the repository's own check commands (its package.json/the build tool's lint/check scripts, its CI workflow), so that findings land on checks that "already exist but aren't wired up or are silently broken," rather than reinventing one. A repository with noguardrails(no pre-commit hook, and no CI job that runs lint/typecheck/test) is itself a finding: an unlinted repository is a long-term missed opportunity, not a neutral default state. Use when the agent makes a mistake that an automated check could have caught, or when the repository has no guardrails at all.
• Coding conventions: Should thereview agent be given a new rule to enforce? Should an existing rule be removed or clarified? First classify the violation:Mechanicalviolations (fixed syntactic patterns, banned APIs, a certain import shape, file location rules) always go through deterministic checks: add a custom rule to the repository's own linter, add a new pre-commit hook, or add a new CI job, whichever is cheapest under the repository's language and existing guardrails. By default, prefer building checks over writing rules. Leave CODING_STANDARDS.md for truejudgment calls(cross-file consistency, "consistent with the surrounding style," anything a guardrail can never replace). Use when the review agent fails to catch a mistake.
• Global AGENTS.md: Are there some guidance instructions that should instead become coding conventions (or automated checks)? Use when the AGENTS.md file is especially large: whether in the repository or in the user's global scope.
• Tool economy: Did the agent make expensive tool calls that could be streamlined? Are there custom tools (CLI, MCP) that are especially token-hungry? Use when the agent made expensive tool calls.
• No-ops: Look in the guidance files for instructions that do not actually change the agent's behavior. Use when the guidance file is large and hard to manage.
• Information access: Look for opportunities to improve the agent's information access. Tee out the dev server's logs, read-only access to third-party services, etc. Use when the agent lacks a key piece of information.

1. Present these candidates to the user in order of severity.

Reference

Implementation vs review

Remember that all work goes through two phases: implementation and review. The implementation agent bears the greatestcontext pressure. They are responsible for exploring, writing code, and debugging failures.

The review agent has the least context pressure: it receives the diff and does not need to explore. It usually neither needs to write code nor debug.

This means the review agent should be responsible for enforcing coding standards, not the implementation agent.

Files

You can access several files in the repository:

• CLAUDE.md / AGENTS.md: these files will be pushed into the context window of any agent working in that repository. They should be used extremely sparingly, usually only to point tonavigation pointers。
• CODING_STANDARDS.md: this file is read during review, not during implementation. When the standards file exceeds 1,000 lines, add newnavigation pointers。
• Docs: use documentation as reference files, pointed to by other files. Before writing new documentation, first check whether existing documentation already exists.
• Skills: use skills as documentation (because their description enters the agent's context window), or as user-invoked commands. Follow the advice in the writing-for-agents skill.