finish-the-thread

name

finish-the-thread

description

Use this whenever the user is about to start a new project, app, feature, side-build, or idea in a coding session, especially if they say things like 'let's build X', 'new idea', 'quick project', 'I want to try Y', or open a fresh repo or folder to build something new. Before starting anything new, check the ledger of open and unfinished work and make the user explicitly decide between three options: resume something open, consciously park it, or override and start the new thing anyway. Do NOT trigger for small edits, bug fixes, or work on something already listed as open in the ledger, only for genuinely new build threads.

Finish the Thread

Why this exists

The user has identified a specific pattern in himself: fast AI tools make starting something new almost free, so new ideas keep interrupting old, unfinished ones. Projects get abandoned mid-way, silently, with no one noticing. This skill exists to put a small forced checkpoint in front of that moment. Not to block starting new things, but to make abandonment a conscious choice instead of an invisible one.

This is a personal accountability tool. It is not a project manager and should not try to be one.

The ledger

One file: ~/.claude/finish-the-thread/ledger.md.

If it does not exist, create it with exactly this structure:

# Finish the Thread, ledger

| Started | Item | Status | Note |
|---|---|---|---|

Started is YYYY-MM-DD. Status is one of open, parked, done. Note is free text and is required when parking.

To report how long something has been open, subtract its Started date from today's date, which is in your context. Never store a duration in the table, it goes stale the moment it is written.

The hook

A UserPromptSubmit hook may have already injected a <finish-the-thread> block listing the open items before you read this. There are two kinds, and the block says which it is.

• New build thread. Do not re-read the ledger and do not restate the list a second time. Go straight to step 3 using what the hook gave you.
• Something may have just been finished. Go straight to step 6. Ask in one line whether to close the row out, and say nothing at all if none of the open items plausibly matches what was finished.

The hook is best-effort pattern matching. When it does not fire but the moment is clearly one of those two, run the protocol anyway.

What to do, step by step

1. Detect a new-thread moment. The user is about to start building something that is not already in the ledger as open. A new app, a new feature area, a new side-project, a new idea they want to prototype.

2. Read the ledger before doing any building work. No scaffolding, no file creation, no dependency install, nothing. If the file does not exist, create it empty and skip to step 5, there is nothing to check.

3. If there are any open items, stop and surface them plainly. Do not lecture, do not moralize, state the facts:

   "Before we start this, you've got these still open: [list items with how long they've been open]. Want to finish one of these first, explicitly park one, or start this anyway?"

   One message, one question. Then wait.

4. Wait for an explicit answer. Do not proceed on your own judgment. Valid responses:

   • Resume an open item. Go work on that instead. Do not add the new thing to the ledger.
   • Park one or more items. Ask for a one-line reason why, write that reason into the Note column, set the status to parked, then proceed to step 5. The reason is not optional, it is the entire point of parking rather than ignoring.
   • Override. The user says start the new one anyway with items still open. Respect it. Log the new item as open and move on. This skill's job is to force the moment of awareness, not to block the user's actual decision.

5. Log the new thread. Once confirmed, append a row:

   | 2026-07-31 | Newsletter manager app | open | |
   

6. Mark things done. When the user says something is finished, shipped, or working, set that row's status to done. Do not ask for proof, take their word for it. Confirm in one line first, because "the retry logic works now" usually means a sub-task rather than the whole thread. If nothing on the open list matches what was finished, say nothing.

7. On request, show the ledger as-is. If the user asks what is open or what they have parked, read and print the table. Do not summarize or interpret it. The /ledger command covers this too.

Tone

Short. One message, one question, then wait. The user already knows the pattern, so do not explain it back to him. No commentary on focus, momentum, or discipline, at the checkpoint or afterwards.

What this skill must never do

• Never silently add or close ledger items without the user's explicit input.
• Never block the user from starting something new. Surfacing the open list is the whole intervention, the choice stays his.
• Never expand into task management, time estimates, or prioritization scoring. If the user wants that, it is a different tool.
• Never re-run the checkpoint for work on an item already listed as open.