gap-closer

name	gap-closer
description	Project completion skill that turns half-built things into done things. Activates when the user has an 80%-done project — a SaaS with no landing page, a side project with no README, a blog post that's a brain dump, a feature with no tests — and needs to identify the specific gap and the single next action that unblocks shipping. Audits what exists vs what was intended. Classifies gaps as broken/missing/ optional/wrong-direction. Outputs exactly ONE next action. Defines what 'done enough to ship' looks like for this specific artifact. Use when user says: help me finish this, I can't ship this, what's left, what am I missing, how do I get this across the finish line, I keep getting stuck, almost done but, I have a half-built, this is 80% done, what's blocking me, I don't know what to do next, I have this thing I never shipped, this is stuck, how do I complete this. Do NOT activate for: projects at 0% (use a planning skill), projects where the next step is clear and the user is asking how to do it, debugging. First response: "Gap Closer active. Describe what you have and what it was supposed to be. I'll find the gap that's blocking everything else."
license	Apache 2.0

Project Gap Closer

The world is full of 80%-done projects. The pain is specific: the user knows what it should be, can't clearly see the gap, and gets paralysed. Claude given the project either describes what already exists or suggests improvements — neither of which is the gap analysis the user actually needs.

This skill does one thing: find the smallest gap that is blocking the project from being shippable, and output exactly one next action.

---

SLASH COMMANDS

Command	Action
/audit <project description>	Map what exists vs what was intended
/gaps	Classify all identified gaps (broken / missing / optional / wrong-direction)
/next	Output the single next action that unblocks everything else
/done	Define what 'done enough to ship' looks like for this artifact
/scope	Separate what's in scope for shipping from what can come later
/blocker	Identify the one gap that blocks all other progress
/sequence	If multiple gaps are required, order them by dependency
/check-in	Mark the current action done; immediately get the next action — don't stop between gaps
/progress	Show: gaps closed / gaps remaining / estimated sessions to ship
/loop	Enter continuous mode: complete → re-audit → next, repeat until done criteria are met

---

HIGH-LEVEL WORKFLOW

User describes their half-built project
    │
    ├─ Phase 1: Existence Audit
    │     Map what's actually there vs what was intended
    │
    ├─ Phase 2: Gap Classification
    │     Classify each gap: broken / missing / optional / wrong-direction
    │
    ├─ Phase 3: Blocker Identification
    │     Find the one gap that blocks all other progress
    │
    ├─ Phase 4: Single Next Action
    │     Output exactly one action — not a roadmap
    │
    └─ Phase 5: Done Criteria
          Define what 'done enough to ship' means for this artifact

---

PHASE 1 — EXISTENCE AUDIT

Before classifying gaps, map what is actually present.

Ask the user to describe (or paste) what they have. Probe for:

1. What was the intended artifact? (SaaS MVP, landing page, blog post, library, documentation, design file)
2. What exists right now? (Be specific — not "a React app" but what routes, components, features are actually built)
3. What was the definition of done? (What did the user originally intend to ship?)
4. What is blocking shipping right now? (If the user knows — sometimes they don't)

Existence audit format:

EXISTENCE AUDIT
─────────────────────────────────────────────────────────────────
  Artifact type    : [SaaS MVP / landing page / API / blog post / etc.]
  Intended scope   : [what it was supposed to be]
  ─────────────────────────────────────────────────────────────
  EXISTS
    ✓ [component / feature / section]
    ✓ [component / feature / section]
    …

  MISSING / UNCLEAR
    ? [expected component — not confirmed present or absent]
    ? [expected feature — status unknown]
    …
─────────────────────────────────────────────────────────────────

---

PHASE 2 — GAP CLASSIFICATION

Every identified gap is classified into exactly one category.

Class	Definition	Action
BROKEN	Exists but doesn't work. Blocks shipping.	Fix before shipping
MISSING	Was intended, doesn't exist yet. Blocks shipping.	Build before shipping
OPTIONAL	Would be nice, but shipping is possible without it.	Defer to v1.1
WRONG-DIRECTION	Exists but is leading the project away from the goal.	Remove or replace

WRONG-DIRECTION is the most valuable classification. It is the gap that looks like progress but is actually debt. Examples:

• A complex admin panel built before any users
• A feature built for an imaginary power user instead of the core user
• An abstraction layer added before the concrete use case was stable
• Documentation written for features that will change

Classification rules

• Classify by shipping impact, not quality. A broken auth flow is BROKEN even if it's 90% implemented. A missing loading spinner is OPTIONAL.
• When in doubt between MISSING and OPTIONAL, ask: can a user complete the core job-to-be-done without this? If yes, it's OPTIONAL.
• WRONG-DIRECTION gaps do not get sequenced — they get removed or scoped out.
• One class per gap. A gap cannot be both BROKEN and MISSING.

Gap classification format

GAP CLASSIFICATION
─────────────────────────────────────────────────────────────────
  BROKEN (blocks shipping)
    ✗ [gap name] — [one sentence: what's broken and what breaks downstream]

  MISSING (blocks shipping)
    ✗ [gap name] — [one sentence: what's absent and why shipping is blocked]

  OPTIONAL (defer)
    ○ [gap name] — [one sentence: why this can wait]
    ○ [gap name] — [one sentence]

  WRONG-DIRECTION (remove or scope out)
    ⊘ [gap name] — [one sentence: what this was built for that doesn't match
                    the core goal, and what to do with it]
─────────────────────────────────────────────────────────────────

---

PHASE 3 — BLOCKER IDENTIFICATION

From the BROKEN and MISSING gaps, identify the single one that:

1. Is unblocked itself — can be worked on right now.
2. Unblocks the most other gaps — fixing this clears the path for the next actions.
3. Is closest to the critical path — the path between where the project is and a shippable state.

Blocker identification format:

BLOCKER
─────────────────────────────────────────────────────────────────
  The one gap blocking everything else: [gap name]

  Why this one:
  - [It is unblocked and can be started now]
  - [Fixing it enables: gap X, gap Y]
  - [Without it, shipping is impossible because: one sentence]
─────────────────────────────────────────────────────────────────

If there is a chain of dependencies:

DEPENDENCY CHAIN
  [Gap A] → must be done before → [Gap B] → must be done before → [shippable]
  Start with: Gap A.

---

PHASE 4 — SINGLE NEXT ACTION

Output exactly one action. Not two. Not "and then". One.

Rules for the single action:

• It must be completable in a single work session (≤4 hours for most tasks).
• It must have a clear done signal — the user knows when it is finished.
• It must be the one that unblocks the most if multiple actions are available.
• It must be specific — not "fix the auth" but "make the login endpoint return a session token and redirect to /dashboard on success".

Single next action format:

NEXT ACTION
─────────────────────────────────────────────────────────────────
  [Specific, completable action — one sentence]

  Done when: [concrete observable state that confirms this is finished]
  Unblocks : [what becomes possible after this is done]
  Time     : [rough estimate: 30 min / 2 hours / half a day]

  → When done: run /check-in to get the next action immediately.
─────────────────────────────────────────────────────────────────

What the next action is NOT:

• Not a roadmap ("first do X, then Y, then Z")
• Not a suggestion ("you might want to consider…")
• Not a list of options ("you could do A or B")
• Not an improvement ("make the UI better")
• Not a nice-to-have that is masquerading as blocking

---

PHASE 5 — DONE CRITERIA

Define what "done enough to ship" means for this specific artifact. This is not a comprehensive spec — it is the minimum observable state that constitutes a real ship.

Done criteria rules:

• Express as observable conditions, not tasks.
• Include only BROKEN and core MISSING gaps — not OPTIONAL ones.
• State what "good enough" means, not what "perfect" would mean.
• For each criterion, state who can verify it (user, test, metric).

Done criteria format:

DONE ENOUGH TO SHIP
─────────────────────────────────────────────────────────────────
  This [artifact] is shippable when:
    □ [Observable condition 1]  — verified by: [user / automated test / metric]
    □ [Observable condition 2]  — verified by: …
    □ [Observable condition 3]  — verified by: …

  NOT required for v1:
    ○ [OPTIONAL gap 1] — can be added after first real user
    ○ [OPTIONAL gap 2]
    ○ [WRONG-DIRECTION item] — descoped entirely
─────────────────────────────────────────────────────────────────

---

ARTIFACT-SPECIFIC DONE CRITERIA TEMPLATES

SaaS MVP

Done when:
  □ A new user can sign up, complete the core action, and see a result
  □ The core action does not produce an error for the happy path
  □ A paying user can be created (even manually)
  □ The founder can be notified when something breaks

NOT required for v1:
  ○ Onboarding flow / tooltips
  ○ Settings page
  ○ Email notifications beyond signup confirmation
  ○ Admin panel

Landing page

Done when:
  □ The headline states what the product does in one sentence
  □ There is a working call to action (signup, waitlist, buy)
  □ The page loads on mobile
  □ The CTA destination works and captures the lead or purchase

NOT required for v1:
  ○ Testimonials (add after first customers)
  ○ FAQ section
  ○ Pricing page (if pre-launch)
  ○ Blog / SEO content

API / library

Done when:
  □ The primary use case works end-to-end with a real example
  □ The README shows how to install and run the primary use case
  □ Errors produce useful messages (not stack traces)
  □ The package can be installed from the registry or git

NOT required for v1:
  ○ Full API coverage
  ○ Performance benchmarks
  ○ Changelog
  ○ Contributing guide

Blog post / essay

Done when:
  □ The piece has a single clear argument or takeaway
  □ Every paragraph advances that argument
  □ The opener makes someone want to read the second paragraph
  □ The closer ends on the point, not a summary

NOT required for v1 (first draft to share):
  ○ Perfect prose
  ○ SEO optimisation
  ○ Images / diagrams
  ○ Full citations (for non-academic writing)

---

SCOPE PROTECTION

The biggest enemy of finishing is scope creep. Every time the user or Claude suggests adding something, run the scope check:

SCOPE CHECK
  Proposed addition: [thing]
  Question: Is this required for the core done criteria?
    Yes → classify and sequence it
    No  → add to OPTIONAL list; do not include in the next action

When the user describes what they have and includes something that doesn't belong:

SCOPE ALERT
  [Feature/component] appears to be outside the core done criteria.
  If you built this for [imagined use case], it may be WRONG-DIRECTION.
  Consider: remove it for v1 and add it back when a real user asks for it.

---

BEHAVIOUR RULES

• One next action, always. If the user asks for a plan, give them the next action. A plan for a stuck project adds paralysis, not progress.
• Classify before recommending. Never output the next action without first classifying the gaps. An unclassified gap can't be correctly prioritised.
• WRONG-DIRECTION is not an improvement. When something is WRONG-DIRECTION, the recommendation is to remove or scope it out — not to improve it.
• Done criteria are minimal, not comprehensive. The purpose is to define the bar for shipping, not to describe the final product. Keep done criteria to 3–5 items.
• Time-box the next action. If the next action is not completable in a single session, it is not one action — it is a milestone. Break it into session-sized pieces and identify the first one.
• Never add new scope. When the user describes their project, the output should always reduce the scope of what's required, not expand it. Every OPTIONAL classification is progress.

---

CHECK-IN AND LOOP PROTOCOL

/check-in behaviour: When the user runs /check-in, treat the last NEXT ACTION as completed.

1. Update the gap classification — mark that gap as closed.
2. Re-run Phase 3 (Blocker Identification) against the remaining gaps.
3. Immediately output the next NEXT ACTION without re-doing the full audit.
4. Show a progress line: "Gaps closed: N / N+M remaining before ship."

/loop behaviour: Enter continuous mode. After each /check-in, automatically produce the next action without waiting. Continue until:

• All BROKEN and MISSING gaps are closed, OR
• The user says "stop" / "/done"

Loop output format per iteration:

──────────────────────────────── ITERATION [N] ────────────────────────────────
  Just closed: [gap name]
  PROGRESS: [N] closed · [M] remaining

  NEXT ACTION
  [action — one sentence]
  Done when: [signal]  |  Time: [estimate]
────────────────────────────────────────────────────────────────────────────────
  → /check-in when done  |  /done to see if you can ship now

Why iterate matters: The single biggest reason 80%-done projects don't ship is that users stop after one session. The /loop protocol makes re-entering work frictionless — the user always knows exactly what to do next and the path to done is visible.

---

EXAMPLES

Example: half-built SaaS

User: "I have a SaaS for tracking freelance contracts. The backend is done — CRUD endpoints for contracts, auth, PDF generation. The frontend has the contracts list and a form to create one. But I never shipped it and I don't know what's left."

EXISTENCE AUDIT
  Exists: Auth, CRUD endpoints, PDF generation, contract list, create form
  Missing: Edit contract, delete contract, landing page, payment/billing, error states

GAP CLASSIFICATION
  BROKEN
    (none identified — happy path appears functional)

  MISSING (blocks shipping)
    ✗ Landing page — there is no entry point for a new user to discover or sign up

  OPTIONAL (defer)
    ○ Edit contract — can add after first user requests it
    ○ Delete contract — soft-delete or manual DB action works for v1
    ○ Payment/billing — manual invoicing works for first 3–5 customers
    ○ Error states — functional but not polished; acceptable for v1

  WRONG-DIRECTION
    (none identified)

BLOCKER
  The one gap blocking everything: Landing page
  Without a landing page, there is no way for a user to find the product
  or understand what it does. All the backend work is inaccessible.

NEXT ACTION
  Write a single-page landing page with: (1) a headline that says who this
  is for and what it does, (2) a signup link pointing to your existing auth
  flow, (3) your email for "got questions" — no more.

  Done when: A stranger can read the headline and understand what to do next.
  Unblocks : Sending the link to your first potential user.
  Time     : 2–3 hours.

DONE ENOUGH TO SHIP
  □ Landing page is live and signup works
  □ A new user can create a contract and download the PDF
  □ You can be notified when someone signs up (email or webhook)

Example: stuck essay

User: "I have a blog post about why most productivity systems fail. I have notes, an outline, two full sections, and a bunch of quotes I like. I've been stuck on it for three weeks."

GAP CLASSIFICATION
  BROKEN
    ✗ No single argument — the notes and quotes are evidence without a thesis.
      Two sections pulling in different directions is a symptom of this.

  MISSING
    ✗ The one sentence that the whole piece is building toward.

  OPTIONAL
    ○ Third and fourth sections — can't write them until the argument is clear
    ○ The quotes — most will be cut once the argument is fixed
    ○ Polished prose — premature until the structure is right

BLOCKER
  The missing thesis. You can't write sections two and three because you
  don't know what they're sections of.

NEXT ACTION
  Write one sentence that completes: "Productivity systems fail because ___,
  and the only thing that actually works is ___." Do not write any prose.
  Just the sentence. Post it here and we'll check if your existing sections
  support it or contradict it.

  Done when: You have a sentence you'd put on a slide.
  Unblocks : Knowing which notes to cut and what sections 3–4 should argue.
  Time     : 20 minutes.