# Code Delivery Review

> Apply automatically from the beginning of software engineering tasks expected to create or modify implementation code, tests, schemas, APIs, migrations, configuration, build logic, CI, or other executable repository artifacts. Track the coding task as one delivery unit through implementation and verification, use incremental checkpoints when useful, and require review coverage before declaring delivery complete. Also apply when resuming the same coding task after interruption or context compaction. Do not use for standalone review of arbitrary branches, commits, pull requests, user-supplied patches, or read-only code review requests.

- Skill: `lifei6671/code-delivery-review` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds@latest add lifei6671/code-delivery-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lifei6671/code-delivery-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: lifei6671 (https://skillmd.com/u/lifei6671)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lifei6671/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.

```text
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](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](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](references/review-protocol.md). A checkpoint reduces final review load but never grants final approval.
5. Load [references/change-surfaces.md](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](languages/INDEX.md), and load only applicable profiles and declared dependencies. Choose risk depth and applicable lenses using [references/review-protocol.md](references/review-protocol.md) and [references/review-lenses.md](references/review-lenses.md), then define required verification before running it.
6. Run applicable authorized verification and record honest evidence using [references/verification.md](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](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](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](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.