|
| 1 | +--- |
| 2 | +name: retro |
| 3 | +description: "STUB — not functional. Raw design ideas for a retrospective skill, awaiting a /writing-for-agents pass." |
| 4 | +disable-model-invocation: true |
| 5 | +--- |
| 6 | + |
| 7 | +The user has asked for a **retrospective**. You are suggesting improvements to the coding agent's **environment** to improve future runs. |
| 8 | + |
| 9 | +## Steps |
| 10 | + |
| 11 | +1. Call the Skill tool with `writing-for-agents` for the writing style guide. |
| 12 | + |
| 13 | +2. Read the primary sources for the session the user specifies. This may mean searching through session logs on this machine. If the user doesn't specify a session, default to the current one. |
| 14 | + |
| 15 | +3. Look for candidates for improvement in these categories. |
| 16 | + |
| 17 | +- **Navigation**: how easy was it for the agent to find the right files? Are there hidden dependencies between files? Would a **navigation pointer** make it easier? _Use when_ the session took a long time to find a piece of information. |
| 18 | +- **Automated checks**: are there automated checks that could catch errors the agent made? Linting, typing, tests, filesystem linters? _Use when_ the agent made a mistake that could have been caught by an automated check. |
| 19 | +- **Coding standards**: should the **reviewer agent** be given a new rule to enforce? Should an existing rule be removed or clarified? _Use when_ the reviewer agent failed to catch a mistake. |
| 20 | +- **Global AGENTS.md**: are there any steering instructions that should be moved to coding standards (or automated checks) instead? _Use when_ the AGENTS.md file is particularly large - in the repo OR the user's global scope. |
| 21 | +- **Tool economy**: did the agent make expensive tool calls that could be streamlined? Is there any custom tooling (CLI's, MCP's) that is particularly token-inefficient? _Use when_ the agent made an expensive tool call. |
| 22 | +- **No-ops**: look for instructions in steering files that don't modify the agent's behavior. _Use when_ the steering files are large and unwieldy. |
| 23 | + |
| 24 | +4. Present these candidates to the user, in order of severity. |
| 25 | + |
| 26 | +## Reference |
| 27 | + |
| 28 | +### Implementation vs Review |
| 29 | + |
| 30 | +Remember that all work goes through two stages: implementation and review. The implementation agent has the most **context pressure**. They are responsible for exploration, writing code, and debugging failures. |
| 31 | + |
| 32 | +The review agent has the least context pressure - it receives a diff, so no exploration needed. It often does not need to write code or debug. |
| 33 | + |
| 34 | +This means that the review agent should be responsible for imposing coding standards, not the implementation agent. |
| 35 | + |
| 36 | +### Files |
| 37 | + |
| 38 | +You have access to several files in the repo: |
| 39 | + |
| 40 | +- `CLAUDE.md`/`AGENTS.md`: these files are pushed to the context window of any agent working in this repo. They should be used incredibly sparingly, usually only for **navigation pointers** to other files. |
| 41 | +- `CODING_STANDARDS.md`: this file is read during review, not implementation. Add **navigation pointers** to docs folders if the standards file gets more than 1,000 lines long. |
| 42 | +- Docs: use docs as references files, pointed to by other files. Look for existing docs before writing new ones. |
| 43 | +- Skills: use skills for docs (since their description goes into the agent's context window), or for user-invoked commands. Follow the advice in the `writing-for-agents` skill. |
0 commit comments