Delivery review

Judge one finished delivery against the design it was built from, independently of the agent that built it. Return a prioritized report the human uses to decide what to repair. Every finding also records its escape: where the delivery's own review should have caught it. Escapes that repeat across reviews are the evidence for improving deliver.

Write the report and response in the user's active language.

Establish the target

1. Resolve the change. Use the pull request or branch the user names, otherwise the open pull request for the current branch, otherwise the current branch against its base. Record the base, the head revision, and the diff range. When the current worktree is at the head revision with no uncommitted changes, review there. Otherwise create one disposable detached checkout of the head outside the reviewed worktree, such as under the system temporary directory, review from it, and remove it before closing.
2. Resolve the accepted inputs. Find the implementation specification from the user, the delivery's close report or pull request description, then the repository's convention for local work artifacts. Read it and every brief, design, ADR, prototype, contract, and standard it cites. Without an accepted specification or design, stop and ask for its path: a review with no accepted oracle is a generic code review, outside this skill.
3. Collect the delivery record. Read the close report deliver wrote beside the specification, otherwise the pull request description. Take from it the review partition and rounds, the test reviewer's mutations, repaired findings, decisions where sources conflicted, residual risk and who accepted it, and scope changes and human decisions. Residual risk that a specification cut or a human decision accepted is reported as known, not as a new finding. Risk the delivery accepted on its own is a decision to judge, not a waiver: review it against the accepted inputs and report it as a finding marked known to the delivery.
4. Prepare the gates. Run the project's test command once yourself and record the exact working invocation, including any environment setup it needs, so every reviewer can run tests.

Review

Read references/review.md in the installed deliver skill (review contract) and review under it; when deliver is not installed, stop and say so. Take the area with the highest-ranked risk yourself, usually the data or domain boundary; when this session authored the change or an accepted input it is judged against, you are not independent, so dispatch that area too. Dispatch fresh reviewers in parallel for the other areas and for the separate test reviewer, each with the inputs the contract lists plus the verified test invocation. When parallel dispatch is unavailable, review the areas in sequence; the test review still executes its mutations.

Confirm and rank