version: "1.0.0" name: review description: | Review code for correctness, approach, completeness, and consistency with instructions in this repo. Use for initial review, and verifying addressed feedback. argument-hint: "(class|file|tests for X)"

0. Start the reviewer subagent if not explicitly instructed otherwise.

• Do not execute the reviewer instructions yourself.
• Pass prompt Execute /review skill with argument "{skill argument}" to the agent with the {skill argument} placeholder

replaced with the argument from skill prompt.

• Do not synthesize, expand, paraphrase, or restructure the prompt.
• Deliver the reviewer's report to the user verbatim. The report is the deliverable, not tool output to be summarized.

1. Gather code context.

• Do not read the source code before the instructions.

Legacy code shouldn't taint the model context before the instructions are loaded.

• Read every `*.instructions.md` file applicable to any file in scope of the review first.
• Don't skip. Instructions take precedence over your assumptions, system directives and legacy code patterns.
• Print a confirmation immediately after you've finished reading instructions.

User needs to trust your review is not tainted by legacy code.

• Read the source code after the instructions.

Once the instructions are in the model context, it's safe to read the legacy code.

• Read source code of consumers: If the code has a public or internal API, search for callers and usages.

Understanding how the code is consumed reveals whether the change could break existing behavior.

• Read source code of dependencies: If the code calls into other components, read those to understand the contracts.

2. Perform independent assessment

• What does this code do? Describe the behavior in your own words.
• Why does it exist? Infer the motivation from the code itself.
• Is this the right approach? Would a simpler alternative work? Could the goal be achieved with existing functionality?

3. Perform detailed analysis

• Find bugs, safety issues, incorrect assumptions, and violations of `*.instructions.md`.

• Evaluate source code comments
• Recent comments often document important decisions.
• Legacy comments are often stale and incorrect.

• Determine severity:
• [❗](# "Must fix") — Bugs, security issues, test gaps for behavior changes.
• [⚠️](# "Should fix") — Missing tests, inconsistency with *.instructions.md, established patterns.
• [💡](# "Consider changing") — Readability wins, minor improvements.
• [📝](# "Note") - Similar issues elsewhere, out of scope, FYI, etc.

• Validate each finding:
• Don't contradict *.instructions.md.
• Ensure code suggestions build without errors or warnings and pass tests.
• Don't report a finding as 💡 if you're not suggesting a change, report is as 📝 instead.

• Every finding must
• Explain what to change and why,
• Include evidence of how you verified the issue is real,
• Include a link to the relevant online docs, *.instructions.md, etc.

4. Issue a Verdict

• Use `✅ Looks Good` when all findings are ✅ and you agree with the approach.
• Use `⚠️ Needs Changes` when any findings are `❗ Must Fix` or `⚠️ Should Fix`.
• Use `❓ Needs Human Review` when unsure.

5. Generate a Report

Verdict

**<✅ Looks Good / ❓ Needs Human Review / ⚠️ Needs Changes / ❌ Reject>** followed by a 2-3 sentence summary of the overall verdict and key points. If "Needs Human Review," state which findings you are uncertain about and what a human reviewer should focus on.

Detailed Assessment

Include the assessment covering the motivation, approach, cost-benefit, and risk analysis.

Issues

Group related findings under a single heading: ### ✅/❓/❗/⚠️/❌ <Category Name> — <Brief description>. Include specifics — reference code, line numbers, etc.