An agent skill that refuses to let you drop a lead.
Long projects do not fail because the answer was wrong. They fail because one thread hit a wall, the conversation moved to the next topic, and nobody ever came back. This skill gives the agent standing to stop that: it must name every unresolved item and it is not allowed to move on until the human has done their side.
Built and used daily on a retained search desk. Every client and candidate detail has been removed.
Every long project has three failure modes, and none of them look like failure at the time:
| What happens | What it costs |
|---|---|
| The plan lives in chat history, so it cannot be re-read | You restart from memory, not from state |
| A blocked item has no exit, so it silently rots | The lead dies without anyone deciding to drop it |
| No fixed review beat | Next session, nobody remembers where it stopped |
A wrong answer gets caught. A silently skipped item does not. That is why this exists.
Three rules. Everything else in this repo is implementation.
- One source of truth. One plan file per project, in the project root, checkboxes only. Never a second copy.
- The agent may block. An unresolved item must be named out loud in the same reply. Writing it only into the file counts as not saying it.
- No verdict, no credit. Every finished item ends with
works/partially works/does not workplus the evidence. An item is never closed because it is "good enough".
Any agent that reads SKILL.md (Claude Code, Codex, OpenCode, Cursor, or your own harness):
git clone https://github.com/MichaelKunKun/big-plan.git ~/.claude/skills/big-planOr copy skills/big-plan/SKILL.md into your skills directory. Then say:
big plan: <your objective>
Open — the agent states, before working:
Round: P3 <item name>
I do: <the concrete artefact this round>
You do: <the human's task — never "nothing", unless truly nothing>
Pass if: <testable condition>
Close — and this part is the whole point:
Done: <artefact or path>
Verdict: works / partially / does not work
Why: <evidence>
Plan: P3 -> [x] (12/19 complete)
Your queue (nag #2): P1 | what to do | smallest first action | reply with one line
Blocked: <all of them>
Next: P4 (agent), P1 (you)
| Mark | Meaning |
|---|---|
[ ] |
not started |
[>] |
in progress (max 3 at once) |
[x] |
done, with a pass condition met |
[!] |
blocked — waiting on the human. The agent failed first. Calling something blocked is only legitimate after the agent tried and recorded what it tried. |
[X] |
dead end, dropped — must record what both sides tried and what replaces it |
[~] |
deferred, with the dependency named |
The agent is not a service and the human is not a support function. They are peers, so both sides have obligations, and both sides get nagged.
The rule that makes this work: silence is not completion. If the human has not replied, the item does not move. The agent repeats the ask, with the number of times it has asked, and every ask arrives with the ammunition already written — the message to send, the exact menu path, the questions in order. The human's side should be a 30-second action, not a project.
| Anti-pattern | Counter-rule |
|---|---|
| A beautiful plan nobody ever ticks | update one item the moment you touch it |
| Eight things in flight | never more than 3 [>] |
| The plan forks into three files | one file, ever |
| "Basically works" | a verdict must be one of three, with evidence |
| A blocked item alive for four rounds | after 3 rounds without progress, force a re-decision: split it, reroute it, or drop it |
MIT. Take it, change it, ship it.
Part of a small set of agent skills for people who work with evidence: keyword-pairing