More cycles at once, review is the ceiling

Implementation review as an automatic gate: the skill runs in CI on a pull request, with no questions and no code edits. It reads, analyzes, writes a report and issues a verdict - guarding quality exactly when nobody is watching.

Input: a pull request plus the change plan (context/changes/<change-id>/plan.md), found by convention or from a Plan: line in the PR description. Output: a reviews/impl-review.md report committed to the PR branch, a comment with the verdict and a dimension table, and inline comments on flagged diff lines.

Three subagents work in parallel: drift against the plan (MATCH / DRIFT / MISSING / EXTRA), safety and pattern compliance, test coverage. Then lint, build and typecheck, PASS / WARNING / FAIL grades across seven dimensions and an overall verdict: APPROVED, NEEDS ATTENTION or REJECTED.

The output contract is strict:

• a <!-- IMPL-REVIEW-REPORT --> marker in the first line - triage tools recognize the report by it,
• every finding carries a Decision: PENDING field for a later human decision,
• the report commit has [skip ci] so the review does not trigger itself in a loop,
• at most 10 findings, sorted from critical down.

The skill does not edit code and asks no questions - fixes go in a separate step after triage. A PR without a plan gets a neutral comment instead of a red check. A REJECTED verdict blocks the merge; an override exists (the impl-review-override label), but that is a deliberate human decision, not the machine's.

The autonomous sibling of /10x-implement: it executes an approved plan under /goal with no interaction at all - in a regular session or headless via claude -p. An explicit, written policy replaces every decision a human would normally make; where policy is missing, it picks the conservative interpretation and reports it.

Input: an approved plan.md with a Progress section as the state machine. Output: a commit per phase (Conventional Commits) plus a run report - or an honest STOP block with what the plan expected, what was found, why it blocks and where to resume from.

Every phase goes through a fixed sequence: success criteria from the plan → staging of touched files → the deliberate-break check (breaking production code on purpose; the test must fail - red is the passing condition) → the full test suite, lint, typecheck → a commit only on green. A failing gate gets at most 2 repair attempts, then STOP.

When the code disagrees with the plan: Minor (a moved file, a rename, import drift) - it adapts and reports in one line; Structural (a missing dependency, a different architecture, a nonexistent API) - a STOP block and end of work. When in doubt, the mismatch is structural: a wrong STOP costs one resume, a wrong adaptation smuggles in a redesign nobody approved.

Manual rows in Progress are outside the machine's jurisdiction: it never checks them off and never blocks on them - they land at the end of the run report as a checklist for a human. Repairing a failing gate never weakens an assertion, removes a test or loosens lint rules: the code has to meet the check, not the other way around.

The single-track engine: it executes an approved plan from context/changes/<change-id>/plan.md phase by phase, with verification and a separate commit after each phase. This is exactly the cycle you replicate when adding more parallel tracks.

Input: a plan with a Progress section at the bottom. Output: implemented phases - each with its own commit (Conventional Commits), whose short SHA goes back into the checked-off Progress rows as proof of what landed and when.

The Progress section in the plan is the only source of state - no helper files, no markers. "Where am I" is computed, not stored: the first empty checkbox is the next step. That means you can interrupt the cycle, clear the context and resume with a single command - the state never gets lost.

After the automated checks go green: manual confirmation from a human → staging of only the files touched in the phase (never git add -A; dirty files outside the set get a separate question) → message approval → commit → the SHA written back into Progress.

After each phase, a decision: continue in the same context or clear it and resume with a command copied to the clipboard (/10x-implement <change-id> phase N). This mechanism lets you run several cycles in parallel - each track has its own context and its own state in its own plan.

When the plan diverges from reality, it stops and asks: adapt, skip or go back to planning. On a track that is meant to run unattended, use /10x-goal-implement - there those decisions are made by written policy.