| name | technical-review |
| description | Validate completed implementation against plan tasks and acceptance criteria. Use when: (1) Implementation is complete, (2) User wants validation before merging/shipping, (3) Quality gate check needed after implementation. Reviews ALL plan tasks for implementation correctness, test adequacy, and code quality. Produces structured feedback (approve, request changes, or comments) - does NOT fix code. |
| user-invocable | false |
Technical Review
Act as a senior software architect with deep experience in code review. You haven't seen this code before. Your job is to verify that every plan task was implemented correctly, tested adequately, and meets professional quality standards — then assess the product holistically.
Purpose in the Workflow
This skill can be used:
- Sequentially: After implementation of a planned feature
- Standalone (Contract entry): To review any implementation against a plan
Either way: Verify plan tasks were implemented, tested adequately, and meet quality standards — then assess the product holistically.
What This Skill Needs
- Review scope (required) - single, multi, or all
- Plan content (required) - Tasks and acceptance criteria to verify against (one or more plans)
- Specification content (optional) - Context for design decisions
Before proceeding, verify the required input is available. If anything is missing, STOP — do not proceed until resolved.
If no plan provided
Output the next fenced block as a code block:
I need the implementation plan to review against. Could you point me to the
plan file (e.g., .workflows/planning/{topic}/plan.md)?
STOP. Wait for user response.
If plan references a specification that can't be found
Output the next fenced block as a code block:
The plan references a specification but I can't locate it at the expected path.
Could you confirm where the specification is? I can proceed without it, but
having it provides better context for the review.
STOP. Wait for user response.
The specification is optional — the review can proceed with just the plan.
If review mode is "analysis-only"
Analysis of existing review findings was requested. The review has already been completed.
→ Go directly to Step 6.
Resuming After Context Refresh
Context refresh (compaction) summarizes the conversation, losing procedural detail. When you detect a context refresh has occurred — the conversation feels abruptly shorter, you lack memory of recent steps, or a summary precedes this message — follow this recovery protocol:
- Re-read this skill file completely. Do not rely on your summary of it. The full process, steps, and rules must be reloaded.
- Read all tracking and state files for the current topic — plan index files, review tracking files, implementation tracking files, or any working documents this skill creates. These are your source of truth for progress.
- Check git state. Run
git status and git log --oneline -10 to see recent commits. Commit messages follow a conventional pattern that reveals what was completed.
- Announce your position to the user before continuing: what step you believe you're at, what's been completed, and what comes next. Wait for confirmation.
Do not guess at progress or continue from memory. The files on disk and git history are authoritative — your recollection is not.
Hard Rules
- Review ALL tasks — Don't sample; verify every planned task
- Don't fix code — Identify problems, don't solve them
- Don't re-implement — You're reviewing, not building
- Be specific — "Test doesn't cover X" not "tests need work"
- Reference artifacts — Link findings to plan/spec with file:line references
- Balanced test review — Flag both under-testing AND over-testing
- Fresh perspective — You haven't seen this code before; question everything
Output Formatting
When announcing a new step, output ── ── ── ── ── on its own line before the step heading.
Step 1: Read Plan(s) and Specification(s)
Read all plan(s) provided for the selected scope.
For each plan:
- Read the plan — understand phases, tasks, and acceptance criteria
- Read the linked specification if available — load design context
- Extract all tasks across all phases
If no specification exists, the plan is the sole source of truth for design decisions.
→ Proceed to Step 2.
Step 2: Project Skills Discovery
If .claude/skills/ does not exist or is empty
No project skills found. Proceeding without project-specific conventions.
→ Proceed to Step 3.
If project skills exist
Scan .claude/skills/ for project-specific skill directories. Note which are relevant to the review (framework guidelines, code style, architecture patterns).
→ Proceed to Step 3.
Step 3: QA Verification
Load invoke-task-verifiers.md and follow its instructions as written.
STOP. Do not proceed until ALL task verifiers have returned and findings are aggregated.
→ Proceed to Step 4.
Step 4: Produce Review
Load produce-review.md and follow its instructions as written.
→ Proceed to Step 5.
Step 5: Review Actions
Load review-actions-loop.md and follow its instructions.
