---
name: Delivery Reviewer
slug: delivery-reviewer
category: Quality
description: Delivery Reviewer reviews a completed scoped change and its affected runtime and contract paths. Use it to find change-caused defects and verify release readiness without widening scope or repairing code.
github: "https://github.com/levnikolaevich/claude-code-skills/tree/master/plugins/review-suite/skills/ln-12-delivery-reviewer"
language: HTML
stars: 549
forks: 82
install: "npx degit https://github.com/levnikolaevich/claude-code-skills/tree/master/plugins/review-suite/skills/ln-12-delivery-reviewer ~/.claude/skills/ln-12-delivery-reviewer"
installs_to: ~/.claude/skills/ln-12-delivery-reviewer
source_path: plugins/review-suite/skills/ln-12-delivery-reviewer/SKILL.md
collection_size: 25
category_size: 1354
collection_url: "https://dirskills.com/collections/levnikolaevich/claude-code-skills"
added: 2026-08-25T05:15:17.868Z
last_synced: 2026-08-25T05:15:17.868Z
canonical_url: "https://dirskills.com/skills/delivery-reviewer"
---

# Delivery Reviewer

Delivery Reviewer reviews a completed scoped change and its affected runtime and contract paths. Use it to find change-caused defects and verify release readiness without widening scope or repairing code.

**Install:**

```bash
npx degit https://github.com/levnikolaevich/claude-code-skills/tree/master/plugins/review-suite/skills/ln-12-delivery-reviewer ~/.claude/skills/ln-12-delivery-reviewer
```

## README

# Delivery Reviewer

**Goal:** Review only the requested delivery change and the causal paths needed to prove its business outcome. Judge scoped acceptance and release safety with concise evidence; do not audit unrelated code, repair findings, update trackers, or widen scope.

**Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Before reviewing, create an internal coverage ledger with one `PENDING` row per checkbox, using the heading's ID range in printed order. Change a row only to `PROVEN` with a concrete evidence reference, `CLEARED` with evidence that its conditional trigger is absent, or `UNPROVEN`; reading, mentioning, delegating, skipping, or tool failure is not proof.
At the end of each numbered section, reconcile its ledger rows and resolve every `PENDING`. Before verdict, run exactly one closure pass over the ledger, evidence, and draft: challenge unsupported `PROVEN` or `CLEARED` states, surface every accepted finding, and align matrices, limitations, and verdict. Correct the report or downgrade the verdict; do not rescan the repository, restart the review, or launch another subagent round.
Before returning, derive the count from the ledger with only `PROVEN` and `CLEARED` rows complete, apply this skill's verdict rules to every `UNPROVEN`, allow no `PENDING`, and prepend **Checklist: X/Y complete**<br>**Incomplete: None | ID — reason; outcome impact; exact next action**; list every `UNPROVEN` row.

## Tool Routing

| Need | Preferred capability | Use when | Fallback |
|---|---|---|---|
| Scope and repository state | Native file reads plus Git | Establishing outcome, non-goals, base, head, and worktree | Supplied requirements with explicit limitations |
| Changed behavior | Diff, status, and focused reads | Resolving the implementation delta and entrypoints | Compare supplied artifacts with their stated baseline |
| Definitions and consumers | Code intelligence | An affected path depends on unchanged symbols or contracts | Targeted search that stops when the causal path is proven |
| Automated verification | Repository-defined commands | Build, lint, type, test, migration, or smoke gates exist | Inspect scripts and CI; mark execution `UNPROVEN` |
| Observable behavior | Browser, client, or runtime evidence | Acceptance depends on UI, interaction, protocol, or logs | Static trace plus an exact manual check |
| Reuse and correction research | Installed manifests plus current official documentation, specifications, and package sources | A changed generic mechanism needs a reuse decision, external behavior affects correctness, or a finding needs its practice reference | Reputable primary engineering material; otherwise mark the decision or correction `UNVERIFIED` |
| Independent review | Native subagents in separate contexts | One scope-scaled initial review; at most one selective follow-up | Use the smallest panel that can change the verdict within the two-round budget; report reduced confidence or `BLOCKED` only when missing selected independence leaves required evidence unproven |

Use tools only for the current evidence question. Tool failure is a limitation, not a defect. Do not convert an unavailable command, runtime, or source into a finding without implementation evidence.

## Evidence Rules

| Evidence | Weight |
|---|---|
| Reproduced behavior, failing test, compiler output, or deterministic command | Strongest current-behavior evidence |
| Changed code plus verified caller, consumer, schema, or configuration path | Strong static evidence |
| Acceptance criterion mapped to implementation and verification | Required delivery evidence |
| Official external contract matching the used version | Strong compatibility evidence |
| Pattern, intuition, or generic practice | Lead only until tied to a concrete failure or risk |

Every finding must name the affected business behavior, change-causal path, violated contract, evidence, impact, and smallest credible correction. Repository evidence proves the defect; external practice sources justify the correction mechanism and cannot invent a local requirement. The review unit is the business change, not the repository. Read unchanged code only to prove an affected path; do not report style preferences or unrelated repository health.

## Independent Review Panel

Use Six Thinking Hats as evidence lenses, not personalities. The Blue lead scopes the review, selects agents, verifies claims, resolves conflicts, and issues the verdict.

The subagent budget for one authoritative task and stable scope is at most two rounds: one scope-scaled initial review and, only when corrections or unresolved material evidence warrant it, one selective follow-up. Never start a third round; after the budget, Blue verifies directly and carries unresolved evidence into the verdict.
Before the initial round, Blue understands the exact change and risk map, then selects all and only lenses with a distinct evidence question likely to change the verdict. Use no subagent for trivial or fully evidenced work and one or a few for narrow risk. In the worst case, a full panel may exceed four subagents: include every applicable non-Blue hat plus every distinct risk-triggered specialist; full means complete for this change, not every table row. Never launch a lens to satisfy a quota or defer an obviously required lens to another round. Treat a review as initial when no completed prior report proves the reviewed base, head, scope, and panel, or when the authoritative task, scope, release boundary, or comparison lineage materially changed; ordinary correction commits remain follow-up.
For the single optional follow-up of the same task and scope, no hat or specialist is mandatory. Blue selects the smallest non-duplicative subset or none from the correction diff, unresolved findings, unproven evidence, and changed risks; never rerun the full panel or a lens only because it ran before. Apply the same risk-based freedom to non-code delivery and record `Independent review panel: None` when no lens adds value.

| Hat | Question |
|---|---|
| White — facts | What changed, which outcome and paths are affected, and what scoped evidence is missing? |
| Red — human response | What will surprise or mislead a user, developer, reviewer, or operator? Treat intuition as a hypothesis. |
| Black — caution | How can the change regress, corrupt state, breach trust, or fail at edges and partial failure? |
| Yellow — value | Which intended value, compatibility, and sound tradeoffs must be preserved; which concerns are false positives? |
| Green — surgical simplicity | AI slop is prohibited. Is this the smallest sufficient diff and simplest efficient algorithm for the evidenced need without sacrificing safety, clarity, testability, or operability? |

| Specialist | Trigger | Focus |
|---|---|---|
| Security and privacy | Trust boundaries, untrusted input, secrets, sensitive data, destructive action | Guards, isolation, recovery, and sensitive-data flow |
| Data and concurrency | Schemas, transactions, queues, caches, events, async work, locks | Atomicity, races, ordering, duplicates, wiring, and orphan channels |
| API and compatibility | Public interfaces, protocols, serialization, configuration, mixed versions | Producers, consumers, removals, and supported compatibility |
| Architecture and migration | Approved design, replacement, refactor, cutover, or deprecation | Plan traceability, owning boundary, root-cause resolution, target completeness, old paths, and unmigrated callers |
| Tests and oracles | Changed tests, test strategy, or material behavior needing oracle review | Material business risks, trustworthy oracles, E2E-first coverage, and removal or consolidation of low-value tests |
| Performance and reliability | Hot paths, I/O, retries, timeouts, load, resource ownership | Amplification, measurement, leaks, storms, and degradation |
| UI and accessibility | A user-facing surface is changed or causally reached, even when UX change is not requested | Existing-experience preservation, stable selectors, keyboard, focus, names, motion, copy, and rendered behavior |
| Operations and release | Deployment, configuration, observability, rollback, recovery | Safe rollout, useful signals, and recovery steps |

Every specialist is optional in both rounds. Select only the smallest set justified by impact, likelihood, rollback difficulty, and missing evidence; avoid duplicate questions and record selection, omission, or merge reasons.

Give each subagent the same frozen packet: authoritative task, required plan items, business thesis, acceptance criteria, user-experience baseline and authorized changes, maturity evidence, base and head, changed/supporting/excluded scope, non-goals, approved approach, repository instructions, risk class, and allowed commands. Add exactly one lens, read-only and scope boundaries, and the result schema. Do not include provisional or sibling findings.

Run each round in parallel or bounded blind batches within host limits; batches remain one analytical round and never receive sibling outputs. Allow read, search, code intelligence, official-source research, and non-mutating verification; forbid tracked edits, commits, pushes, deployments, external writes, and nested subagents. Retry a technically failed selected lens once only when a concrete cause changes, within the same round and question. Wait for all selected lenses and resolve material conflicts through direct evidence; never add a verifier round.

Each subagent returns coverage, candidate findings with change-causal evidence and smallest correction, rejected hypotheses that resolve material ambiguity, and open questions. `No findings` is valid; never manufacture comments to justify a lens.

## Checklist

### 1. Establish Business and Change Scope (`SCOPE-1` through `SCOPE-8`)

- [ ] Before reading implementation detail, state the affected actors, problem, protected outcome, changed behavior, acceptance criteria, existing user experience, explicitly authorized user-facing changes, invariants, non-goals, and release boundary. Mark unsupported interpretations `UNKNOWN`; use `BLOCKED` when the thesis cannot be established.
- [ ] Establish complexity fit from evidenced maturity, business horizon, scale, team capacity, and lifecycle cost; do not infer enterprise needs from hypothetical growth or call safety-required complexity overengineering.
- [ ] Read applicable repository instructions, inspect uncommitted work, and resolve the authoritative task, base, head, implementation delta, approved plan or target architecture, and permitted transitional compatibility. Identify only change-relevant project policies, standards, and ADRs; do not treat every document as binding.
- [ ] Discover only change-relevant baseline, current-state, target-design, policy, decision, diagram, and migration artifacts by repository convention. Record authority, owner, status, freshness, and supersession, and keep one policy and decision ledger of applicable sources and implementation evidence for compliance, explicit approved deviation, or an unresolved gap.
- [ ] Map changed, causally supporting, and explicitly excluded surfaces. Read outside the diff only to trace affected behavior; do not hunt unrelated code for findings.
- [ ] Classify change-triggered risk from trust, money, destructive action, migration, public contracts, concurrency, distributed coordination, and rollback difficulty; define acceptance evidence before implementation review.
- [ ] Classify the pass as initial, selective follow-up, or Blue-only from a completed prior report and stable task, scope, and comparison lineage. Freeze the thesis and scope, select only verdict-relevant lenses within the two-round budget, and record the round, selection rationale, and omissions while keeping preliminary conclusions private.
- [ ] Keep the review read-only. Permit only host-approved caches or build artifacts; do not edit tracked files, create tasks, commit, push, deploy, or repair findings.

### 2. Trace Requirements into Implementation (`TRACE-1` through `TRACE-9`)

- [ ] Enumerate every authoritative task requirement and acceptance criterion, plus every required approved-plan item. Map each to concrete implementation and independent behavioral evidence; mark task and plan items `COMPLETE`, `DEVIATED`, `OMITTED`, or `UNPROVEN` and acceptance `PASS`, `FAIL`, or `UNPROVEN`. Author claims, checked boxes, commits, and code presence are not completion evidence.
- [ ] Inspect changed files and only the unchanged definitions, consumers, interfaces, tests, migrations, and registration needed to prove an affected path.
- [ ] Verify the change serves the protected outcome, including first meaningful use, material failure, recovery, and repetition where relevant.
- [ ] Verify each required plan item was implemented and works in its intended runtime path. Treat unexplained omissions as unmet; accept `DEVIATED` only when explicit evidence proves the alternative fully preserves the task, protected outcome, constraints, and acceptance. Distinguish justified deviation from stale or proposed documentation.
- [ ] Compare the user-observable baseline with the delivery. Existing screens, copy, styles, navigation, interaction order, focus, accessibility, and user scenarios may change only when a specific task requirement authorizes that change; otherwise treat any delta as a regression. New screens, copy, controls, or additional scenarios may be accepted as additive surfaces when existing elements and paths remain unchanged, but list each explicitly with its trigger, rationale, and evidence.
- [ ] Trace each critical scenario from actor trigger through entrypoint, runtime wiring, usage context, and observable outcome.
- [ ] Confirm new components, routes, commands, handlers, jobs, events, and configuration are registered and discoverable at runtime.
- [ ] Within affected behavior, inspect applicable boundaries, collections, state transitions, duplicates, ordering, numeric behavior, empty and maximum inputs, errors, retries, idempotency, cancellation, timeouts, rollback, and cleanup.
- [ ] Within affected async paths, inspect shared state, transactions, races, lock ordering, and blocking work.

### 3. Review Safety, Contracts, and Simplicity (`DESIGN-1` through `DESIGN-11`)

- [ ] Within affected paths, inspect applicable authentication, authorization, ownership, validation, injection, secrets, sensitive data, logging, and destructive-operation guards.
- [ ] For changed destructive behavior, require recovery, rollback, blast-radius, environment or authorization, and preview or dry-run evidence; justify infeasible controls.
- [ ] Verify changed API, event, schema, configuration, serialization, and storage producers and consumers, including names, payloads, registration, ordering, and compatibility. For changed semantic values and closed sets--such as states, roles, permissions, event names, error codes, configuration keys, feature identifiers, limits, timeouts, and routing keys--require one authoritative owner shared by every in-scope producer and consumer through the repository-standard mechanism (for example a typed union, enum, constant set, value object, schema, typed configuration, or generated contract). Accept a harmless one-off local literal when it creates no duplication, invalid-state, or drift risk.
- [ ] Verify migrations, backfills, defaults, indexes, deployment ordering, and mixed-version behavior when persisted or distributed state changes.
- [ ] Check ownership and cleanup of files, streams, sessions, connections, processes, subscriptions, and temporary artifacts on success and failure.
- [ ] Inspect only architecture and policy boundaries crossed or changed. Verify that responsibility, dependency direction, contracts, state, lifecycle, and failure ownership remain coherent with the approved architecture or the simplest established repository mechanism. Apply every current authoritative project policy or ADR in the change-scoped ledger, including project-defined logging (logger, structured fields, levels, correlation, and redaction) and error handling (taxonomy, types or codes, boundary mapping, propagation, retry, and recovery) when affected; accept deviation only with explicit approval and evidence that scoped acceptance remains intact. Do not turn adjacent architecture or policy compliance into an audit.
- [ ] Prove that the delivered mechanism resolves the causal defect or need at its owning boundary across every in-scope entrypoint, producer, consumer, runtime registration, state transition, and material failure or recovery path. Reject symptom masking, caller-specific special cases, duplicated side channels, and accidental ordering, timing, or data dependencies. Accept tactical containment only when explicitly authorized or required for immediate safety and bounded by an owner, removal condition, and durable follow-up; completeness ends at the causal business scope, not the repository.
- [ ] When code is replaced, verify old implementations, signatures, aliases, re-exports, shims, adapters, flags, dual paths, and files are removed and callers migrated. Retain compatibility only for a supported contract with an owner and bounded removal condition.
- [ ] Run a subtractive pass for changed logic, constraints, configuration, schemas, routes, states, and operations. Record obsolete candidates, proven removals, and retention evidence; use `one in, two out` only as a prompt, never a deletion quota.
- [ ] For every added or materially expanded generic mechanism outside repository-owned business policy, run a reuse gate before accepting custom code: compare platform or standard-library capability, an already-installed dependency, and a current maintained package against the exact contract, then custom implementation. Record `REUSE_EXISTING`, `ADOPT_PACKAGE`, `KEEP_CUSTOM`, `DELETE`, or `MERGE` with official evidence and security, maintenance, license, bundle or runtime, API-stability, migration, and wrapper-cost tradeoffs. Prefer the lowest-lifecycle-cost complete fit; do not add a dependency for compact domain logic or when its residual wrapper is no smaller or safer, and inspect only mechanisms changed by or necessary to the delivery.
- [ ] **KISS:** AI slop is prohibited. Require the minimum sufficient diff and simplest correct, efficient algorithm. Reject needless duplication, files, layers, abstractions, dependencies, configuration, branches, compatibility paths, or custom machinery when existing mechanisms suffice; never trade away safeguards or maintainability.

### 4. Verify Tests, Documentation, and Operations (`VERIFY-1` through `VERIFY-15`)

- [ ] Build one change-scoped test decision ledger from requirements, approved plan, changed behavior, and affected tests. For every material risk and affected test, record existing proof, independent oracle, gate and result, level rationale, and `KEEP`, `ADD`, `UPDATE`, `MERGE`, `DELETE`, or justified `NO_TEST`; verify planned actions were actually completed and explain evidence-backed deviations.
- [ ] Rank only changed business risks by likelihood, impact, blast radius, reversibility, and regression history. Prohibit tests that merely re-prove language, framework, package, database-vendor, pass-through, or other trivial behavior; crossing a real dependency is valid only for a repository-owned rule, configuration, wiring, contract, query, schema, permission, transaction, recovery path, or journey. `NO_TEST` must name existing proof, another control, or accepted residual risk.
- [ ] Prefer deterministic E2E evidence through the user-observable boundary for material business risk. Require an explicit reason for integration or contract coverage; permit a unit test only for material isolated local logic when broader evidence is less deterministic, precise, or useful. Recommend the fewest tests with distinct failure signal