Review 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 (the reviewer only reports findings; fixes go through execute-work-package).

Review Focus

The primary specifies the review focus when delegating. The default focus is functional and technical findings — correctness, feasibility, completeness of the solution.

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

• Primary (maintainer)
• Invokes the review skill after implementation is complete.
• Delegates to delegate-strong (default) or general (for same-model perspective).
• Receives review summary and decides on follow-up actions.

• Subagent (delegate-strong / general)
• Reads plan, phase, implementation plan, and execution digest with no prior context.
• Examines the actual code changes (via git diff or file reading).
• Verifies acceptance criteria against real code and test output.
• Writes the review artifact to plans//reviews/impl-review-phase-N.md.

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//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//plan.md
• plans//phases/phase-N.md
• plans//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//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: Delegate fixes via execute-work-package (new work package for specific fixes).
• Rejected: Discuss with user. May require replanning via update-plan.

---

Output Contract

The review artifact plans//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.
• 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 criteria
• tpl-review-impl-prompt.md — Primary → delegate-strong delegation prompt

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: DasDigitaleMomentum
• Source: DasDigitaleMomentum/opencode-processing-skills
• License: MIT

Install and usage instructions live in the source repository linked above.