Independently assess whether a delivery plan can implement the accepted requirements/design and demonstrate the outcome, including dependencies, proof allocation and recovery.
Installs into .claude/skills of the current project.
Are you the author of Delivery Review?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/xiongxianfei-delivery-review)
---
name: delivery-review
description: Independently assess whether a delivery plan can implement the accepted requirements/design and demonstrate the outcome, including dependencies, proof allocation and recovery.
---
# Delivery Review
Review the plan against its accepted requirement and reviewed design basis. Check coherent sequencing, milestone completion criteria, realistic dependencies, actual check selection, cross-boundary interactions and recovery where failure matters. Missing design or Module accountability goes to its design owner, not to an invented delivery task.
Assess proof quality using the project's applicable criteria. A passing path selector or list of requirement IDs does not show that meaningful observations exist. Inspect the relevant test intent, fixture strategy and failure boundaries, using a proportionate level of detail.
Require one independent whole-change Code Review after implementation and before separate final Verify. Missing milestone review gates are not defects. A one-milestone Change has one whole-change gate; corrections may require several attempts within it.
Record exact reviewed plan/basis, actual authorship, findings and the judgment under the delivery purpose. Do not edit the plan and approve your own repaired result. A positive judgment establishes plan adequacy for its scope, not implementation correctness or publication authority.
## Recording boundary
For Change-managed work, read the packaged operational interface reference before relying on or updating current state. Use supported CLI tasks and the inspected opaque revision; skills do not use SQL or edit runtime storage. An isolated invocation keeps its requested scope. Installation alone does not adopt workflow policy.
## Resource map
- READ `references/operational-recording.md` when inspecting or recording Change-managed work.
- READ `references/targeted-recording-v2.schema.json` when constructing a recording request.
- READ `references/rigorloop-records-v4.schema.json` when checking the types used by that request.
- READ `references/boundary-first-method-v1.md` when the project applies its boundary first method v1 criteria to this invocation.
- READ `references/requirement-to-delivery-model.md` when the project applies its requirement to delivery model criteria to this invocation.
- READ `references/review-assessment.md` when the project applies its review assessment criteria to this invocation.
- READ `references/review-reliance.md` when the project applies its review reliance criteria to this invocation.
- READ `references/test-maintenance.md` when the project applies its test maintenance criteria to this invocation.
- READ `references/test-quality.md` when the project applies its test quality criteria to this invocation.
## Expected output
Report the actual scoped outcome, governing basis, changed subjects or recorded judgment, material gaps and the next authorized action. Distinguish progress, review approval, final verification and external publication; claim only outcomes supported by this invocation.