// Use when explicitly requesting an independent code review, after subagent-driven implementation slices, before merging high-risk work, or when verification finds evidence, baseline, architecture, compatibility, or retirement uncertainty that needs reviewer scrutiny.
Use when the user explicitly sets an Aegis goal with /aegis-goal, Aegis goal:, or asks to define goal, success evidence, stop condition, or task boundaries before work.
Use when about to claim work is complete, fixed, passing, verified, release-ready, or ready to commit, merge, publish, or hand off.
Use when defining new features, product behavior, UI/component design, architecture choices, contract changes, or ambiguous medium/high-complexity work before implementation.
Use when the user explicitly asks for first principles, first-principles review, Occam's razor, or when a complex decision has ambiguous goals, competing constraints, repeated fixes, fallback growth, duplicate owners, or architecture/product direction risk.
Use when the user asks to create, write, update, amend, supersede, or evaluate an ADR, architecture decision record, durable architecture decision, decision log, or baseline sync after architecture-changing work.
Use when starting a turn or checking Aegis skill routing.
| name | requesting-code-review |
| description | Use when explicitly requesting an independent code review, after subagent-driven implementation slices, before merging high-risk work, or when verification finds evidence, baseline, architecture, compatibility, or retirement uncertainty that needs reviewer scrutiny. |
Dispatch aegis:code-reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history. This keeps the reviewer focused on the work product, not your thought process, and preserves your own context for continued work.
This skill is the canonical review-request workflow for method-pack implementation work. Use it to request review only after you have enough evidence, enough context, and a clear authority boundary for what the reviewer is being asked to assess.
Core principle: Review early, review often.
Findings First: Reviews lead with concrete findings before summary. Use bugs first, risk first, tests first. Strengths and general assessment are still useful, but they must not bury correctness, evidence, architecture, or retirement problems.
Review readiness is not merge approval. A review can reduce uncertainty and
recommend readiness, but it does not replace verification-before-completion
and does not grant completion authority.
Mandatory:
Optional but valuable:
Before you leave this workflow, you must be able to state:
Review in this method pack is advisory and evidence-oriented. It is not authoritative completion by itself.
1. Gather minimum review inputs:
recording-architecture-decisions was used, or should be used, when
an ADR action or baseline sync closure is in scopeIf you cannot answer these, stop and gather them before dispatching review.
2. Get git SHAs:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
3. Dispatch code-reviewer subagent:
Use Task tool with aegis:code-reviewer type, fill template at code-reviewer.md
Placeholders:
{WHAT_WAS_IMPLEMENTED} - What you just built{PLAN_OR_REQUIREMENTS} - What it should do{EVIDENCE} - Fresh tests, commands, logs, or verification already available{COMPATIBILITY_BOUNDARY} - What existing behavior or interfaces must not break{RETIREMENT_NOTES} - Old owner / fallback / patch / duplicate branch and expected disposition{BASE_SHA} - Starting commit{HEAD_SHA} - Ending commit{DESCRIPTION} - Brief summary4. Act on feedback:
[Just completed Task 2: Add verification function]
You: Let me request code review before proceeding.
BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)
[Dispatch aegis:code-reviewer subagent]
WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
PLAN_OR_REQUIREMENTS: Task 2 from docs/aegis/plans/deployment-plan.md
EVIDENCE: pytest tests/index/test_verify.py -v -> 12 passed
COMPATIBILITY_BOUNDARY: Existing index format and CLI flags must remain stable
RETIREMENT_NOTES: Legacy repair fallback still exists in old helper; remove once new path covers all four issue types
BASE_SHA: a7981ec
HEAD_SHA: 3df7661
DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
[Subagent returns]:
Strengths: Clean architecture, real tests
Issues:
Important: Missing progress indicators
Minor: Magic number (100) for reporting interval
Assessment: Ready to proceed
You: [Fix progress indicators]
[Continue to Task 3]
Subagent-Driven Development:
Executing Plans:
Ad-Hoc Development:
The review request must prompt the reviewer to inspect at least:
scope: requirements | architecture | bothrecording-architecture-decisions handoff when ADR action or
baseline sync closure is in scopeIf the review only asks “is this code good?”, it is underspecified.
Never:
If reviewer wrong:
See template at: requesting-code-review/code-reviewer.md