Writing a spec Claude Code can actually execute

A paragraph of requirements is a paragraph an agent will interpret. A list of checkable lines is a list it can work down, and one you can audit afterwards in two minutes instead of reading a diff.

Write it as an outline of checkable lines rather than as prose, and the agent can work down it, tick what it finished, and leave the ones it could not do with a reason.

Set it up

What makes a line checkable

• It names one outcome, not a task. "The export refuses a format it cannot write, in words" rather than "improve the export".
• Somebody who did not write it can tell whether it is true.
• Its note carries the reason, so an agent that has to choose between two readings picks the one you meant.

A spec whose lines cannot be checked is a spec whose completion is a matter of opinion, and an agent will always have the more generous opinion.

What the agent does with it

It reads the branch, works down it, and ticks each line as that outcome becomes true. A ticked box is a claim you can go and test. When it hits a line it cannot finish, it leaves the line open and writes what stopped it in the note, rather than ticking it and explaining in a chat you will not read.

And when it needs you

Some lines turn out to need a decision only you can make. Those become their own bullet with the ask on the line and the reason in the note, in the same tree, waiting. The run does not stop; everything that does not depend on the answer carries on.

Deeper

• The project brief that fits in five bullets
• The Checklist Manifesto in an outline

Connect an agent, about two minutes · The twelve tools · Which note apps an agent can reach · Who runs this