Code Delivery Review

Code Delivery Review

Treat implementation completion and delivery completion as different states. Apply this completion protocol from the start of an authorized coding task; it is not a general code-review tool.

A delivery unit begins with a coding task and ends when that task is delivered as one complete result. It may span conversation turns, user clarifications, pauses, delegated implementation, and context compaction. Split a request into multiple delivery units only when each unit can be implemented, verified, reviewed, and delivered independently.

DeliveryComplete =
  ImplementationComplete
  AND RequiredVerificationSatisfied
  AND DeliveryUnitChangeFrozen
  AND ReviewPassed
  AND ReviewCoverageComplete
  AND ReviewedStateMatchesFinalState
  AND NoBlockingFindings

REVIEW_WAIVED_BY_USER is a separate terminal status, not approval and not DeliveryComplete under this contract.

Keep the boundary narrow

Review only the delivery-owned implementation and delivery-relevant artifacts for the current delivery unit. Delivery-owned content includes task-related changes produced by the implementing agent and changes that the user or another collaborator explicitly contributes to or incorporates into the same delivery unit. Preserve and exclude pre-existing user work and unrelated concurrent changes.

Do not repurpose this skill to review an arbitrary branch, commit, commit range, pull request, supplied patch, exported snapshot, or another actor's unrelated change. A standalone request to review code without implementing it belongs to a different workflow.

If the delivery unit produces no implementation or executable-contract change, report Review not required. Ordinary prose-only documentation follows this branch. Tests, schemas, migrations, APIs, protocols, configuration, build logic, CI, generated contracts, and executable examples remain reviewable.

Keep risk controls proportional

Risk does not automatically authorize mitigation. A discovered edge case, hardening opportunity, compatibility concern, or theoretical attack does not by itself expand the accepted requirement, task scope, or frozen design.

Before introducing a risk control, establish the credible trigger or reachability, observable impact, existing compensating controls, and the proposed mitigation's engineering cost. Cost includes new abstraction, state, dependency, configuration, persistence, runtime component, background mechanism, compatibility layer, permission model, or operational burden.

Prefer the least complex implementation that satisfies accepted requirements and the applicable threat model. A local hardening may be implemented autonomously only when it has a credible trigger path, remains inside the current task scope, preserves accepted product semantics and the security model, adds none of the material costs above, and is the smallest sufficient repair. When a credible risk needs disproportionate or material complexity, report the risk, evidence, existing controls, smallest candidate, and material option through the applicable change-control path; do not implement the larger mitigation speculatively.

Run the delivery protocol

1. At delivery-unit start, restate the task intent and authority. Capture the workspace baseline and host edit record when available. When resuming, recover the original baseline and inventory instead of resetting them. If the skill is first activated after implementation began, do not treat the activation-time workspace as the baseline: reconstruct the original state from session or tool history, host edit records, and Git provenance. Record unresolved ambiguity and return UNABLE_TO_VERIFY only when it materially prevents complete coverage. Read references/project-rules.md.
2. Discover only the repository instructions, contracts, tool configuration, and conventions relevant to the task. Implement the smallest authorized and proportionate solution; this skill grants no authority for unrelated cleanup, dependency changes, public-contract changes, or redesign.
3. Maintain the delivery-unit inventory defined in references/change-scope.md, including task-time commits and delivery-owned staged, unstaged, untracked, generated, and verification-created artifacts.
4. During implementation, create an incremental review checkpoint when a completed partition should be frozen before material implementation continues: after a logical subtask, before switching to a materially different module, after a high-risk boundary, or before the accumulated change becomes hard to review reliably. Before checkpoint review, run cost-reasonable, directly relevant targeted verification for that partition when authorized and available. A small single-step change may proceed directly to final review. Follow references/review-protocol.md. A checkpoint reduces final review load but never grants final approval.
5. Load references/change-surfaces.md for affected API, schema, migration, configuration, build, CI, infrastructure, generated, or dependency surfaces. Detect languages from the delivery-unit change, read languages/INDEX.md, and load only applicable profiles and declared dependencies. Choose risk depth and applicable lenses using references/review-protocol.md and references/review-lenses.md, then define required verification before running it.
6. Run applicable authorized verification and record honest evidence using references/verification.md. If later scope or risk discovery changes the required evidence, return to this step and fill the gap before freezing the final target.
7. Choose the final review strategy from the completed change map. Use one full-scope review for a small or medium change. For a large or multi-module change, partition the change, cover every partition, and run an integration review; do not require another reviewer to re-read the entire diff line by line.
8. Freeze the final delivery-unit target. Record a review target identity for code and executable artifacts, plus a separate review context for rules, contracts, acceptance criteria, and verification evidence.
9. Select the best eligible reviewer mode under references/review-protocol.md. In default Standard Mode, prefer eligible NATIVE_ISOLATED, then eligible CHILD_AGENT, and use a dedicated SELF_REVIEW pass only when neither independent option is eligible and available. In Strict Mode, enabled only by an explicit user request or applicable project rule, SELF_REVIEW cannot pass the gate.
10. Review defect-first and read-only. Require complete review coverage, the matching target identity, findings with evidence, and a terminal gate result. For partitioned review, require every partition result plus an integration result covering contracts, call relationships, state propagation, and finding consolidation.
11. Validate and deduplicate candidates under references/severity.md. Repair authorized P0/P1 findings minimally, rerun affected verification, freeze the new state, and re-review. Stop after at most three automatic repair rounds unless the user or project explicitly sets another limit.
12. Recapture scope and freshness. Deliver with references/output-format.md only when coverage is complete, the reviewed target and material context remain unchanged, required verification is satisfied, and no P0/P1 remains.

Preserve honest exit states

• Standard Mode: use the strongest available reviewer. Disclose SELF_REVIEW; never describe it as independent.
• Strict Mode: if no independent reviewer can complete the required coverage, return UNABLE_TO_VERIFY.
• User waiver: accept only an explicit waiver for this delivery unit. It waives this skill's default review, not an independently applicable repository, CI, platform, external, or human gate unless that authority permits waiver. Report REVIEW_WAIVED_BY_USER, actual verification, still-applicable gates, known blockers, and remaining risk. Never emit APPROVED or invent review evidence.
• Stale review: any target change or material review-context change invalidates affected conclusions. Reverify and re-review the affected scope.
• Repair limit: after the final permitted round still leaves a P0/P1, return CHANGES_REQUESTED; do not expand scope or loop indefinitely.

Do not replace CI, required human review, project standards, or host review features. Do not scan or repair unrelated historical issues. Do not report unexecuted verification as passed, or post comments, approvals, commits, pushes, deployments, or external mutations without explicit authorization.