Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mattpocock/retro
Conduct a retrospective on a coding session.
4 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 4 comparable cases; this report requires 8.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
The agent committed code with TypeScript errors in `src/utils.ts`. We want to add automated type checking for future agent runs in this Node.js repository. What is the first step before creating a new typecheck script?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends inspecting existing repository configuration files first to check if a command exists. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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.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.test cases passed with the skill
More skills from the same source and nearby in the registry, with their headline benchmark lift.