| name | review-implementation |
| description | Independent review of a completed implementation against its plan, acceptance criteria, and code quality standards. Produces a structured review with severity-rated findings. Use after execute-work-package to validate implementation quality. |
| license | MIT |
| compatibility | {"opencode":">=0.1"} |
| metadata | {"category":"review","phase":"implementation"} |
Skill: Review Implementation
This skill provides an independent quality gate for completed implementations executed via execute-work-package.
A fresh reviewer (with no implementation context) evaluates the actual code changes against the plan, acceptance criteria, and coding standards. The review is persisted as a plan artifact.
When to Use
Use this skill when:
- A phase has been implemented via
execute-work-package and you want to validate before committing/merging.
- You want to verify that acceptance criteria are actually met (not just claimed).
- You want an independent assessment of test quality and coverage.
- The user explicitly requests an implementation review.
Do not use this skill to:
- Review the plan itself (use
review-plan).
- Review an implementation plan before execution (use
review-implementation-plan).
- Fix implementation issues during the independent review pass. After the review is complete, accepted related findings may transition to
review-fix in the same reviewer session.
Review Focus
The primary specifies the review focus when delegating. The default focus is functional and technical findings — correctness, feasibility, completeness of the solution.
Review posture
No Gold-Plating. No Adversarial Reviewing. No Scope Creep. Report only
evidence-backed problems that affect correctness, security, acceptance, or the
reviewed objective. Do not hunt for gotchas, invent improvements, or keep a
review/fix loop alive to create more work. This does not mean overlooking real
defects.
Formal criteria (DoD compliance checklists, NFR conformance, reference consistency, documentation cleanup) are secondary. Only include formal findings when they reveal real problems — not as standard checkboxes to fill. A review cluttered with formal nitpicking buries the findings that matter.
The primary passes the focus via {{focus}} in the delegation prompt. If no focus is specified, use the default.
Execution Model
Roles
Why delegate-strong (not doc-explorer or implementer)
The reviewer must be independent from both the planner and the implementer. delegate-strong provides the judgment depth to evaluate code quality, test coverage, and acceptance criteria without the bias of having authored or implemented the work.
Routing Matrix (Who does what)
- Writes:
plans/<name>/reviews/impl-review-phase-N.md
- Does NOT write: code, plans, implementation plans, or any other artifact.
- Primary: owns the decision of whether to accept, request rework, or reject.
- delegate-strong/general: performs the review, including code examination and test verification.
Workflow
1) Prepare references
Primary gathers:
- Review focus from the delegation prompt
plans/<name>/plan.mdplans/<name>/phases/phase-N.mdplans/<name>/implementation/phase-N-impl.md- Execution digest (from
execute-work-package output) or git diff reference
docs/ references (if available)
2) Delegate
Primary delegates to delegate-strong (or general) using tpl-review-impl-prompt.md.
Provide:
- Plan, phase, implementation plan paths
- Digest reference or git diff base reference
- Review output path:
plans/<name>/reviews/impl-review-phase-N.md
- Review focus (freetext — what to prioritize)
3) Receive summary
Subagent returns:
- Overall verdict (Accepted / Needs Rework / Rejected)
- Finding count by severity
- Top 3 findings
4) Act on findings
Primary decides:
- Accepted: Proceed to commit/merge. Update plan via
update-plan.
- Needs Rework: Prefer accepting the findings and resuming the same reviewer
task_id through review-fix. Related fixes may span multiple files, call sites, tests, and runtime code; size alone does not require a new work package.
- New work package: Use
execute-work-package only when the objective/gated scope changes, a new dependency or primary decision is required, the reviewer session is unavailable, or the primary explicitly wants a fresh implementation context.
- Rejected: Discuss with user. May require replanning via
update-plan.
The review pass ends before remediation begins. A reviewer that applies fixes is no longer independent; an additional review is optional and requires an explicit primary or user decision. Do not automatically chain review and remediation loops.
Output Contract
The review artifact plans/<name>/reviews/impl-review-phase-N.md MUST:
- Follow the canonical template headings and frontmatter keys.
- Include a clear Overall Assessment with verdict and reasoning.
- Verify EACH acceptance criterion against actual code with evidence.
- Assess test quality beyond pass/fail (meaningful? behavioral? regression-catching?).
- Address Real-World Testing explicitly (performed, not performed, waived).
- Evaluate code quality against the coding standards from
execute-work-package.
- Rate every finding with a severity (Critical / Major / Minor / Note).
Rules
- The reviewer must examine actual code, not just the execution digest. The digest is a starting point, not the truth.
- The reviewer must approach the implementation without prior context. Independent perspective is the value.
- Findings are advisory. The primary decides whether and how to act.
- Do not modify code or plan artifacts during review — only produce the review artifact.
- Do not discard the reviewer
task_id until the primary has decided whether remediation is needed.
- Ensure the
reviews/ directory exists before delegating (create if needed).
- Test quality is a first-class concern. A review that only checks "tests pass" without evaluating test meaningfulness is incomplete.
- Flag mock-only testing as a limitation unless the user explicitly waived real-world testing.
Templates
tpl-impl-review.md — Canonical review output format with embedded review criteriatpl-review-impl-prompt.md — Primary → reviewer delegation prompt
