retro

The user asks for a retrospective. You need to propose improvement suggestions for the coding agent's environment to improve future run results.

Steps

1. Call the Skill tool and specify writing-for-agents, to get the writing style guide.

2. Read the primary sources of the session specified by the user. This may mean searching for session logs on this machine. If the user does not specify a session, use the current session by default.

3. Look for improvement candidates in the following categories.

• Navigation: How easy is it for the agent to find the correct files? Are there hidden dependencies between files? Could navigation pointers make locating easier? Use this when the agent took a long time to find a piece of information.
• Automated checks: Are there automated checks that can catch mistakes the agent made? For example, linting, typing, tests, or filesystem linters? First read the repo's own check commands (package.json/build-tool in the lint/check scripts and the CI workflow), so that if a check already exists but is not wired into the process or has quietly stopped working, the real finding is that problem, rather than reinventing a set of checks. If the repo has none at all guardrail(no pre-commit hook, and no CI job that runs a lint/typecheck/test command), that itself is a finding: a repo not covered by lint is a long-standing improvement gap, not a taken-for-granted default state. Use this when the agent made a mistake that could have been caught by an automated check, or when the repo has no guardrail at all.
• Coding standards: Should reviewer agent be given a new rule to enforce? Should an existing rule be removed or clarified? First classify the violation:mechanical violations (fixed syntactic patterns, banned APIs, import forms, file location rules) must be handled by a deterministic check; depending on the language the repo uses and the existing guardrail, choose the lowest-cost approach: add a custom rule to the repo's own linter, add a new pre-commit hook, or add a new CI job. By default, prefer building checks over writing rules.CODING_STANDARDS.md is only for truly judgement calls(cross-file consistency, "matches the surrounding style", and any judgment that no guardrail can replace). Use this when the reviewer agent did not catch a mistake.
• Global AGENTS.md: Are there steering instructions that should be moved to coding standards or automated checks? Use this when AGENTS.md in the repo or the user's global scope is especially large.
• Tool economy: Did the agent make expensive tool calls that could be simplified? Is there custom tooling (CLI, MCP, etc.) that is especially token-consuming? Use this when the agent makes expensive tool calls.
• No-ops: Are there instructions in the steering files that do not change the agent's behavior? Use this when the steering files are large and hard to maintain.
• Information access: Are there opportunities to give the agent more information? For example, teeing out dev server logs, or providing read-only access to third-party services. Use this when critical information is unavailable to the agent.

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

References

Implementation and Review

Remember, all work goes through two phases: implementation and review. The implementation agent bears the greatest context pressure, and is responsible for exploring, writing code, and debugging failures.

The review agent bears the least context pressure: it receives the diff, so it does not need to explore. It usually also does not need to write code or debug.

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

Files

You can access several files in the repo:

• CLAUDE.md/AGENTS.md: These files will be pushed into the context window of any agent working in this repo. They should be used extremely sparingly, usually only containing navigation pointers to other files.
• CODING_STANDARDS.md: This file is read during review, not during implementation. If the standards file exceeds 1,000 lines, you should add pointers to docs folders within it. navigation pointers。
• Docs: Treat docs as reference files, pointed to by other files via pointers. Before writing new docs, look for existing docs first.
• Skills: Use skills to host docs (because their descriptions enter the agent's context window), or for user-invoked commands. Follow the recommendations in the writing-for-agents skill.