Plan versus code: matches, omissions, additions and drift become visible before closure.
SKILL // CHAIN STEP 05
/10x-impl-review - plan versus code
Review exists to doubt - instead of performing the "looks good" ritual.Review exists to check - instead of accepting "looks good". /10x-impl-review compares the actual implementation against the plan: two parallel subagents look for drift and hazards, the commands from the success criteria are actually run, and the result lands as a report with a verdict and a list of findings ready for triage.
/10X-IMPL-REVIEW // THE PLAN'S PROMISE CONFRONTED WITH THE DIFF
The problem: acceptance without checking the promises
"Ritual calms the machine. Understanding tells you whether it works."
- a useful heresy, cogitator detachment"It works, let's merge" is acceptance without checking whether the code kept the plan's promises. Drift, dangerous decisions and convention violations accumulate quietly - every phase adds a little, until the divergence becomes the architecture. /10x-impl-review catches it before it sets in.
Two scopes: a single-phase review (fast, right after the phase closes) and a full plan review before merge. Two modes: a fresh review with triage, and resume - a saved report is opened later and triage picks up from the unresolved items.
most useful before merge - the bigger the diff, the easier the drift between what the plan promised and what the code does.
Review checks more than code quality: it verifies that the implementation matches what was approved.
From a plan and a diff to a saved report
The input is plan.md (change-id, a path or a phase number) and the actual state of the repository - the diff is taken since the plan date. Matching the plan's file list against the diff's file list yields three classes: expected (in both - verify the content), unplanned (only in the diff - investigate and flag), missing (only in the plan - potentially unimplemented).
The output is a report in the change folder's reviews/ - saved always, regardless of whether triage starts now, later or not at all. Along with the save, change.md gets the impl_reviewed status.
- Input
- plan.md + the diff since the plan date; alternatively a saved report (triage resume)
- Output
- a report in context/changes/<change-id>/reviews/ with a verdict and findings carrying a Decision field
- Verdict
- APPROVED / NEEDS ATTENTION / REJECTED - with partial verdicts across six dimensions
The plan and code enter review as independent sources, making differences visible.
Two subagents, real commands, triage
- 01 · Context
- the plan read in full, state from the Progress section, rules from lessons.md taken as given - violating an accepted rule is a stronger signal than a generic style remark.
- 02 · Scope from git
- commits and the diff since the plan date; the list of changed files versus the plan's list determines what is expected, unplanned and missing.
- 03 · Drift subagent
- for every planned change it reads the actual file and rules: MATCH / DRIFT / MISSING / EXTRA - divergence of intent, not of formatting.
- 04 · Quality subagent
- in parallel: safety (injection, secrets, authn/authz), performance (N+1, missing pagination), reliability (error handling at the boundaries), data safety, and consistency with the patterns of neighboring files.
- 05 · Criteria for real
- commands from the automated criteria are actually run, the results compared with the declarations; manual items ticked off with no trace in the diff are flagged as possible rubber-stamping.
- 06 · Report
- findings sorted by severity, max 10 (related ones consolidated); the write to disk and the status stamp happen always before asking what comes next.
- 07 · Triage
- a loop over the findings: fix now, fix differently, skip, or record as a lesson in lessons.md; every decision goes back into the saved report, so triage can be paused and resumed.
the review analyzes and reports by default - code edits happen only in triage, when the user explicitly chooses to fix a specific finding.
Review reveals matches, omissions, extras and drift, then orders findings by impact.
A finding - evidence rather than opinion
Every finding carries evidence in the formula "the plan said X, the code does Y" with a file:line location, plus a fix proposal with a trade-off analysis. Two fix options appear only for a genuine dilemma - weak alternatives are not invented for the sake of it.
The pair of dimensions: severity says how bad it gets if the problem is ignored; impact - how much deliberation the decision requires. These are orthogonal axes: a CRITICAL with low impact is an obvious one-line fix, while a WARNING with high impact deserves more thought than many a CRITICAL.
- Severity
- CRITICAL / WARNING / OBSERVATION - the weight of the problem if ignored
- Impact
- LOW / MEDIUM / HIGH - the cost of the decision: from a quick fix to architectural stakes
- Dimension
- one of six: Plan Adherence, Scope Discipline, Safety & Quality, Architecture, Pattern Consistency, Success Criteria
- Evidence
- a file:line location + a Detail juxtaposing the plan's wording with the actual code
- Fix
- 1-2 options with strengths, costs, a confidence level and an explicit blind spot
- Decision
- PENDING → FIXED / SKIPPED / ACCEPTED / DISMISSED - a report field updated during triage
APPROVED - everything passes or at most 2 minor warnings; NEEDS ATTENTION - multiple warnings or one non-critical FAIL; REJECTED - any critical FAIL (safety, serious drift, data, failed tests).
One comparison produces four explicit verdicts instead of mixing every concern into a vague mismatch.
What /10x-impl-review does not do
- Does not fix quietly
- code changes only on the user's explicit choice in triage - and then minimal, targeted edits, without refactoring the neighborhood.
- Does not flag style
- minor stylistic differences, when the code works and delivers the plan, are at most observations - not warnings.
- Does not spare the plan
- if the plan itself was flawed (e.g. a dangerous approach was planned), the review flags the plan - not just the code.
- Does not argue with "skip"
- the user's decision is recorded without debate; in a phase review it also checks whether the phase broke the assumptions of earlier phases.
- Does not touch the archive
- reviews are not appended to archived plans - an outright refusal.
back to step 05 (review) on the Core Skills Chain page - the context of the whole chain and the neighboring steps.
The agent may find and prioritize a problem, but a risky exception does not pass without conscious approval.