Analyzes a coding session's logs to identify inefficiencies, errors, or missing guardrails. It proposes concrete improvements to the agent's environment, such as adding automated checks, refining navigation pointers, or updating coding standards.
Say it in your own words; the assistant finds this recipe by itself. Examples:
Use this skill after a coding session to review what went well and what didn't. It is ideal when the user wants to improve the agent's future performance by fixing environment issues, adding missing tests, or clarifying instructions. It is also appropriate when the user notices the agent struggled with navigation or made repeated errors that could be prevented by better tooling.
The user has asked for a retrospective. You are suggesting improvements to the coding agent's environment to improve future runs.
Call the Skill tool with writing-for-agents for the writing style guide.
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.
Look for candidates for improvement in these categories.
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.
package.json/build-tool lint/check scripts, its CI workflow), so a check that already exists but sits unwired or silently broken is the finding, not a reinvention. A repo with no guardrail (no pre-commit hook and no CI job running its lint/typecheck/test command) is itself a finding: an un-linted repo is a standing missed opportunity, not a neutral default. Use when the agent made a mistake an automated check could have caught, or the repo has no guardrail at all.CODING_STANDARDS.md for genuine judgement calls (cross-file consistency, "matches the surrounding style," anything no guardrail could ever substitute for). Use when the reviewer agent failed to catch a mistake.Information access: look for opportunities to increase the agent's access to information. Teeing dev server logs, readonly access to third-party services. Use when a crucial piece of information was not available to the agent.
Present these candidates to the user, in order of severity.
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.
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.
This means that the review agent should be responsible for imposing coding standards, not the implementation agent.
You have access to several files in the repo:
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.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.writing-for-agents skill.LICENSESKILL.mdagents/openai.yamlVendored from mattpocock/skills, commit 5beb35b040e3, path skills/engineering/retro, licence MIT. The upstream licence file ships inside the skill.