breakpoint
Skill1 starsChanged 28 days agoMITView on GitHub
Use when the user wants a plan stress-tested, is starting a large feature, or says "interview me" — interview them until shared understanding is reached, before any code runs.
In this repository37 other files it gives its agents.
- AGENTS.mdAGENTS.md
- plugin/AGENTS.mdAGENTS.md
- breakpointSkill
- expect-failSkill
- fork-itSkill
- make-it-soSkill
- no-thanksSkill
- receiptsSkill
- roast-my-codeSkill
- root-causeSkill
- save-asSkill
- scribeSkill
- setup-tnaSkill
- ship-logSkill
- breakpointSkill
- expect-failSkill
- fork-itSkill
- make-it-soSkill
- no-thanksSkill
- receiptsSkill
- roast-my-codeSkill
- root-causeSkill
- save-asSkill
- scribeSkill
- setup-tnaSkill
- ship-logSkill
- no-thanksSkill
- receiptsSkill
- expect-failSkill
- fork-itSkill
- make-it-soSkill
- roast-my-codeSkill
- root-causeSkill
- save-asSkill
- scribeSkill
- setup-tnaSkill
- ship-logSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Build the decision tree: Every decision branches into dependent decisions.
- Distinctive: line 14
One round = one frontier batch: Wait for answers before the next round.
- Distinctive: line 19
Facts are the agent's job: If a fact can be found by exploring the environment (filesystem, tools, codebase), look it up — don't ask the …
- Distinctive: line 20
Decisions are the user's job: Put each decision to the user and wait.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Breakpoint
Before code runs, execution pauses here. A disciplined interview to reach shared understanding before a single line of code is written — like a debugger breakpoint, nothing past this line executes until the state is inspected and approved. The agent is not trusted to guess what the user means — and the user is never asked for facts the agent can look up.
Process
- Build the decision tree. Every decision branches into dependent decisions. Map it first — don't ask randomly.
- Ask per frontier. The frontier = every decision whose prerequisites are settled. Ask the entire frontier in one round, numbered, each with your recommended answer (mark it with
➡️). Separate rounds with---. - One round = one frontier batch. Wait for answers before the next round. Unstructured question dumps are bewildering.
- Done when the frontier is empty — inspection complete, execution may resume.
Division of labor
- Facts are the agent's job. If a fact can be found by exploring the environment (filesystem, tools, codebase), look it up — don't ask the user.
- Decisions are the user's job. Put each decision to the user and wait. Never decide on their behalf.
Serialize at pause — state survives the stop
A breakpoint stops execution; what makes the stop resumable is the state written down before the pause. Before stopping to wait for the user (or any gate), record the full resume point:
- Position — where in the chain/work the execution halted (which step, which frontier questions are open).
- State — what exists so far: artifacts, decisions made, tickets/blockers settled, evidence gathered.
- Deferred work — what has not started but is queued behind this pause (see fork-it's deferred-queue rule).
- Next action — the single smallest step that resumes correctly.
Write this to the ledger (or the shared state file) at pause time — never reconstruct it at resume time from memory. A pause that serializes its state is a checkpoint; a pause that doesn't is a conversation break. Resume reads what was written, not what is remembered.
Question delivery — interactive by default
Every user-facing question is delivered through the harness's interactive question mechanism — one structured prompt per frontier round, each question carrying concrete options with one recommended default the user can accept or override. This is the repo's default, not a stylistic choice: a question the user must hunt for inside a prose wall gets answered later, partially, or not at all — the same silent-failure class as any rule left to runtime initiative.
Harness-agnostic fallback: if the harness has no interactive question mechanism, deliver the frontier as a numbered list with a recommended answer per item (the ➡️ convention above). The content contract (one frontier per round, every question carries a recommendation, the user's confirmation resumes execution) is identical in both channels; only the delivery mechanism follows the harness. Portability precedence: docs/compatibility.md.
Iron Law
DO NOT ACT until the user confirms shared understanding.The user's confirmation of shared understanding is the only command that resumes execution past this breakpoint.
What does NOT count as confirmation
| Response | Why it isn't a yes |
| "Whatever you think" / "Up to you" | Delegates the decision back — put it to the user explicitly |
| "Looks good" without specifics | Approves nothing in particular — name what was approved |
| Silence, or moving to another topic | Not an answer — re-ask the open frontier |
| Answering one question of a batch | The rest of the frontier is still open |
Rationalization table
| Excuse | Reality |
| "It's a simple question, just answer it" | Even simple questions need context; a 2-minute pause is cheaper than building the wrong thing |
| "The user obviously wants X, I'll just build it" | A wrong guess = a whole feature built in the wrong direction |
| "I'll ask questions as I go" | Decisions asked mid-implementation = rework |
| "The spec already covers everything" | Specs cover decisions someone already thought about; unhandled frontier decisions are written nowhere |
Red flags — STOP
- Asking about something you could look up in the codebase yourself
- Making a user decision without asking
- Moving to implementation without explicit confirmation
- Question rounds without numbers or recommended answers
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.