Delivery completion review

Delivery Closure Review

Use this skill when reviewing a completed implementation or preparing a task for closure to confirm that the accepted goal is fully achieved, core quality invariants hold, and the work item closes cleanly without endless polishing loops.

Closure Principle

A task is done when its explicit acceptance criteria, end-to-end user workflow, and core correctness baselines (security, authorization, data integrity, error handling, and verification tests) are satisfied — not when every conceivable future enhancement or stylistic preference has been exhausted.

Workflow

1. Verify outcome completeness against the brief:
   • Check each acceptance criterion against the actual implementation and test results:
     • Does the primary user or API flow work end-to-end without manual intervention?
     • Are authorization, tenant boundaries, data integrity, and failure states handled properly?
     • Were any required steps silently stubbed out or left half-finished?
2. Check for unapproved scope drift or gold-plating:
   • Inspect the diff for unrequested features, speculative config layers, unused abstractions, or unrelated file churn that crept in during implementation.
   • If an unrequested addition introduces new maintenance burden, security surface, or untested paths, recommend removing or simplifying it before merge.
   • If an addition is benign and already tested, do not create busywork by demanding its removal solely on formality.
3. Separate blocking defects from optional future ideas:
   • Blocking (Must fix before closure): Broken acceptance criteria, regressions, missing permission/tenant checks, data loss/corruption risks, or failing tests.
   • Non-blocking (Defer or drop): Cosmetic nitpicks, alternative naming preferences, or future feature extensions. Record genuine future extensions briefly with their revisit trigger and approve closure.
4. Fast-pass when proportional and complete:
   • Never become a bureaucratic bottleneck. When the implementation meets the goal cleanly with proportional complexity, issue a concise approval immediately so the team can ship and move on.

Concise Closure Summary Format

When findings exist, report them in four lines:

Goal: [The accepted objective and acceptance criteria] Observation: [Any missing core requirement or disproportionate extra complexity in the diff] Proposal: [The minimal change needed to close cleanly] Trade-off: [Deferred follow-ups and the condition under which to revisit them]