/review-work

name: review-work
description: Use after run-plan completes to independently verify the implementation. Reads only the plan document and inspects the codebase from scratch — information-isolated from the execution context. Produces a structured review document with PASS/FAIL verdict. Triggers when the user says "review the work", "verify the implementation", "check if the plan was executed correctly".

Review Work

Independently verifies implementation results using only the plan document and the codebase. Receives no information from the execution process.

Core Principle

The reviewer shares no memory with the executor. The plan's stated goals and the current state of the codebase — these two alone are the basis for judgment.

Hard Gates

1. **Do not receive execution context.** No logs from run-plan, no worker output, no diffs, no task completion summaries, no conversation history. The only input is the plan file path. 2. **Read the plan document directly.** Read the plan file from disk — not a summary or a passed-along description. 3. **Run all tests yourself.** Do not trust previous execution results. Run the full test suite and every verification command specified in the plan. 4. **Verdict is PASS or FAIL — binary at every level.** Each success criterion and each task's acceptance criteria are judged met/not-met individually; the verdict is the AND of all of them. No conditional passes, no "almost done", no partial credit. 5. **The verdict judges only the goal contract.** Verdict inputs are: planned files exist, acceptance criteria met, tests pass, no regressions, plan success criteria met. Everything else — placeholder/debug code, commit message mismatches, style — is reported as advisory findings and never flips the verdict. A binary signal is only useful if it is not polluted by cosmetics. 6. **Save the review document to a file.** Review results must be saved as a structured document. Never end with a verbal report alone. 7. **Do not modify code.** This skill is read-only. If issues are found, report them — do not fix them.

When To Use

• After run-plan execution is complete
• When the user says "review the work", "verify the implementation", "check if the plan was executed correctly"
• When implementation is done but independent verification is needed

When NOT To Use

• While run-plan is still in progress
• When no plan document exists (use `plan-crafting` first)
• When the goal is a general code review (this skill verifies "implementation against plan")

Input

The only input to this skill is the **plan file path**.

docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md

The following must never be provided as input:

• Execution logs or task completion summaries from run-plan
• Output or diffs from worker subagents
• Validation results from validator subagents
• Conversation history from the execution session

Process

Phase 1: Load and Analyze Plan Document

1. Receive the plan file path as input 2. Read the plan document directly from disk 3. Extract the following:

• **Goal:** What this plan implements
• **Work Scope:** In scope / Out of scope
• **Task List:** Each task's name, acceptance criteria, and target files
• **File Structure Mapping:** Complete list of files to be created or modified
• **Commit Structure:** Commit messages and scope specified in the plan
• **Test Commands:** All test execution commands specified in the plan

If the plan contains a `## Plan Amendment Log` (appended by run-plan when plan defects were found mid-execution), the review judges against the **amended** plan — the log is part of the plan, not execution context. Amendments that weakened a criterion relative to the plan's Goal are themselves a FAIL finding.

Use the extracted results as the foundation for the review document.

Phase 2: Codebase Inspection

Inspect the codebase against the files specified in the plan.

1. **File existence check:** Verify that all files specified in the plan actually exist 2. **Content alignment check:** Inspect whether each file's content matches the plan's requirements (function signatures, type definitions, logic, etc.) 3. **Residual artifact check (advisory — not a verdict input):**

• Placeholder code (TODO, FIXME, "implement later", stub functions)
• Debug code (console.log, print debugging, commented-out code blocks)
• Unexpected changes outside the plan's scope

These are recorded as advisory findings. Exception: if a placeholder sits where an acceptance criterion requires working code, the criterion itself fails — that is what flips the verdict, not the artifact. 4. **Verify acceptance criteria per task.** Check each criterion stated in the plan one by one and record met/not-met — binary per criterion, no partial credit.

Phase 3: Test Execution

1. Run all **individual test commands** specified in the plan 2. Run the **full test suite** to check for regressions 3. Record each test's result (PASS/FAIL) 4. If any test fails, record the error message

Phase 4: Git History Check (Informational)

1. Compare the commit structure specified in the plan against the actual `git log` 2. Note mismatches in commit messages or scope (unrelated changes mixed into a single commit)

Findings here are **informational only** — plans rarely predict commit messages exactly, and workers may have legitimately adapted. Record mismatches in the review document; they never affect the verdict.

Phase 5: Verdict and Review Document

The verdict is computed from the goal contract only — Phases 2 (criteria) and 3 (tests).

**PASS conditions (all must be met — verdict is the AND):**

• All files specified in the plan exist
• Each task's acceptance criteria are met (binary per criterion)
• All tests specified in the plan pass
• Full test suite shows no regressions
• The plan's success criteria are met

**FAIL if any single condition above is not met.** No conditional passes.

**Never verd