Delivery completion review
Determines whether delivery meets the accepted goal and distinguishes genuine completion blockers from optional future polish.
delivery-closure-review
Agents using this skill
When is it useful?
Use it before closing a task when implementation, evidence and remaining ideas need a clear final assessment.
What does it help you do?
- Matches acceptance criteria with implementation and executed checks.
- Finds incomplete flows, missing isolation and unrequested maintenance burden.
- Separates blocking defects from optional follow-up ideas.
Try asking this
Review whether the new invitation flow is ready to close. Check accepted, expired and already-used invitations against the requirements. State which checks actually ran and whether any unresolved defect prevents completion.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
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
- 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?
- Check each acceptance criterion against the actual implementation and test results:
- 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.
- 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.
- 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]
Included files 1
SKILL.md