Why I Write a “Task Book” for Every Project

You might think that now AI can write code, the cost of starting has dropped and thinking it through beforehand matters less. My experience is the opposite: once writing code became easy, what matters most is saying exactly what you want.

So I have a rule now. Anything that will take more than half a day starts with a task book. Until it is written, no work begins.

What is in a task book

Four sections, usually a dozen or so lines — shorter than most people imagine:

• Goal: what usable thing will exist in the world once this is done. One sentence, and no endless verbs like “improve” or “polish.”
• Inputs: the material available, the existing decisions that must be honored, and which file holds the precedent to follow.
• Acceptance criteria: a checklist you can tick item by item. “Verified” must mean “command + output”; a vague criterion is no criterion at all.
• Out of scope: what this round explicitly will not touch, and where those things went instead.

The last section is the one most often skipped, and the most valuable.

The three things it prevents

First, it protects me from myself. If I cannot write clear acceptance criteria, it usually means I have not decided what I want. And that is precisely the moment I most want to just start and figure it out along the way. The task book forces that vagueness into the open: hesitating while drafting costs far less than hesitating while reworking.

Second, it prevents drift. The costly failure when working with AI is not that it writes the wrong code; it is that it enthusiastically does something beautifully that should not have been done at all. With boundaries written down, “could we just do this bit too while we’re here” has an answer that does not depend on my mood: no — into the task pool, scheduled next round.

Third, it prevents forgetting. My windows get replaced: the context fills up, the topic turns, so a window retires and a new one starts. What keeps the bench standing while the occupants change is the task book sitting in the repository. It is written for the next window, not for me today.

They eventually grew into tools

By the third time I wrote the same opening speech, I froze it into a tool. I now have a few skills I wrote myself: one for starting a project (project-init, part of murDrift), which stands up the architecture, milestones and verification scaffolding in one pass; one for research (murPick), which turns candidates into a checkable “menu” for me to pick from before any work begins; and one that pre-seeds a new workspace with my background and preferences (memory-seed, also part of murDrift), so I do not have to introduce myself again every time I change directories.

What they have in common is that judgment is frozen into process, and process is frozen into scripts. A rule with no script behind it is just art on the wall. Those scattered disciplines were all collected into murDrift — a set of engineering constraints that keeps long-running projects from quietly drifting off course.

One selfish reason

Writing task books has a side effect I have grown fond of: every small piece of work ends with a definite “done” — tick the boxes, close the card — which is very kind to an obsessive streak. What wears you down on a long project is usually not difficulty but the absence of edges — and a task book at least gives the edges back.

The article you are reading also began as a card.