complete-everything

Solid

Close an approved plan with zero plan-related deferrals: implement every unfinished item, absorb every connected out-of-scope/follow-up/nice-to-have item parked by prior runs, fix newly exposed gaps, and run the full applicable verification ladder. Use when a plan was marked done with work deferred, or the user says "complete everything", "don't defer", "fix out of scope too", "finish the whole plan", "close every TODO", or invokes /complete-everything. Distinct from burndown-full, which proves mechanical pattern coverage; this skill closes intent, behavior, and verification gaps.

AI & Automation 6 stars 0 forks Updated 3 days ago MIT

Install

View on GitHub

Quality Score: 78/100

Stars 20%
28
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Complete Everything ## Mission (verbatim) > fix and test thoroughly on all the plan - do not defer anything. make sure proper full test is done after enhancement - also fix all out of scope. ## Completion contract Drive the approved outcome through implementation, repair, and verification in one continuous run. Do not stop at phase boundaries or ask whether to continue. Do not claim success from memory, compilation alone, or the original plan's checkboxes. The **closure set** contains: - every unfinished or partially finished plan item; - every `out of scope`, follow-up, optional, nice-to-have, or future-work item parked by the plan or prior completion report that is materially connected to the approved goal; - every defect, missing test, contract mismatch, or regression discovered in the affected blast radius; - every failure introduced by the work or blocking proof of the outcome. This is not permission for unrelated repository-wide cleanup. Do not silently reopen explicit user non-goals, rejected features, or unrelated pre-existing debt. Record those as baseline context, not closure items. If relevance is unclear, decide from the approved user outcome; ask only when the answer would materially change product behavior. Only these may block execution: - missing credentials, access, or a real endpoint/contract; - destructive production-data operations or irreversible external actions; - auth behavior, RLS semantics, secrets, payments, destructive data mutatio...

Details

Author
kensaurus
Repository
kensaurus/cursor-kenji
Created
5 months ago
Last Updated
3 days ago
Language
JavaScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category