The user has asked for a ****. You are suggesting improvements to the coding agent's **environment** to improve future runs.
## Steps
1. Call the Skill tool with `writing-for-agents` for the writing style guide.
2. Read the 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.
3. Look for in these categories.
- **Navigation**: how easy was it for the agent to find the right files? Are there hidden dependencies between files? Would a **** make it easier? _Use when_ the session took a long time to find a piece of information.
- **Automated checks**: are there automated checks that could catch errors the agent made? Linting, typing, tests, filesystem linters? Read the repo's own check command first (its `package.json`/build-tool `lint`/`check` scripts, its CI workflow), so a check that already exists but 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 , 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**: should the **reviewer agent** be given a new rule to enforce? Should an existing rule be removed or clarified? Classify the violation first: a **mechanical** one (a fixed syntactic pattern, a banned API, an import shape, a file-location rule) gets a , full stop: a custom rule in the repo's own linter, a new pre-commit hook, or a new CI job, whichever the repo's language and existing guardrail make cheapest. Default to building the check over writing the rule. Reserve `CODING_STANDARDS.md` for genuine **** (cross-file consistency, "matches the surrounding style," anything no guardrail could ever substitute for). _Use when_ the reviewer agent failed to catch a mistake.
- **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.
- **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.
- **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.
- **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.
4. Present these candidates to the user, .
## Reference
### Implementation vs Review
Remember that all work goes through two stages: implementation and review. The implementation agent has the most ****. They are responsible for exploration, writing code, and debugging failures.
The review agent has the least - 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.
### Files
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 , usually only for **s** to other files.
- `CODING_STANDARDS.md`: this file is read during review, not implementation. Add **s** to docs folders if the standards file gets more than 1,000 lines long.
- Docs: use docs as references files, . Look for existing docs before writing new ones.
- 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.
Source metadata
---
name: retro
description: "Conduct a on a coding session."
disable-model-invocation: true
---
“the coding agent's environment”
- Direct source： 目标对象被限定为代理环境。
- 机制不是修补单次症状，而是追问仓库为什么允许问题发生，再改入口、检查、标准或信息通道。
- 这样能让一次会话的成本产生跨会话收益。
“Read the primary sources for the session”
- Direct source： 复盘必须先读会话的一手记录。
- 它把泛泛而谈的“最佳实践生成器”约束成证据驱动诊断器。
- 这能降低为了填满分类而编造通用建议的风险。
“a check that already exists but sits unwired or silently broken is the finding”
- Direct source： 先读取仓库已有检查命令和 CI，再决定是否需要新机制。
- 它优先修复断开的反馈回路，而不是看到问题就重复建设。
- 这同时控制维护成本，并揭示“已有能力未真正生效”这种更深层故障。
“a mechanical one ... gets a deterministic check, full stop”
- Direct source： 固定模式违规必须进入 linter、pre-commit 或 CI。
- 规则类型决定承载介质：机器能判定的交给机器，只有机器无法替代的判断才留给文字。
- 这避免“把自动化问题写成一句容易被忽略的提示词”。
“The review agent has the least context pressure”
- Direct source： 实现代理承担探索、编码和调试，审查代理只接收 diff。
- 因此编码标准由审查阶段施加，而不是继续挤占实现阶段的上下文。
- 这不是简单减少文本，而是按角色的信息负载重新安排规则。