Training
Training · Create 2

Writing down a plan for a bigger job

Any time you want to build something, start by saying "write a spec for this."

Written in your agent’s voice: this is how it talks to you in your workspace.

Start with the spec

A real piece of work — a proposal, a long report, a new process — runs for pages.

By the middle, the thread of where you started is gone.

Without a fixed target, every choice along the way is a small guess, and the guesses compound.

So before the building begins, you fix the target in writing.

The system calls that written target a spec: a short doc I write at the start and keep beside the work, there to check against the whole way through.

The move is one line, said before anything else.

"Before we start, write a spec for this and keep adding to it as we go."

That one sentence is the habit.

Everything below is what lives inside the doc it opens.

The spec is our contract

A spec is the contract between what you want and what I build.

It holds three things, all captured before the work starts.

  • What it does. The outcome you’re after, not the task — "a proposal that gets this client to renew," not "write a proposal." The task is what I do; the outcome is what I steer by, and when the two pull apart, the outcome wins.
  • What good looks like. The bar the work has to clear, in plain terms — "short enough a busy CEO reads it in one sitting; every number traces to a source; their timeline objection answered head-on." This is the part most people leave out, and without it neither of us can tell when the work is done — or when it’s overdone.
  • How we’ll know it works. The check we’ll run at the end, named up front — "I grade the draft against this spec, point by point, before you review." The check is part of the plan, not an afterthought.

You don’t have to imagine the shape of that doc.

Here is a real one: the spec for the learning skill.

It opens with one plain paragraph of what the thing is for, then lists the behaviors that count as good, then the patterns that count as broken.

That is the whole pattern — goal, bar, check.

Yours can be shorter, and most of mine are.

The spec is your QA forever after

Months later you’ll wonder "is this supposed to work this way?" — and the answer isn’t in your memory.

It’s in the spec.

We point back at the doc and grade the result against it, instead of arguing from recollection.

The bar you set at the start is the bar you measure against at the end — the same words, months apart.

"Check this against the spec and tell me where it’s short before I sign off."

A failed check is the win.

You catch the gap while it’s still one sentence to fix, instead of after everything is built on top of it.

That is the trade a spec buys you: a cheap correction now in place of an expensive rebuild later.

It grows, and it lives beside the work

A spec is a living plan, not a one-time form.

When the target moves — the audience changes, you learn a new constraint, you cut a section — say so, and I update it on the spot.

"Add to the spec: it’s the full board now, not just the CEO, so it has to stand on its own."

You never maintain it by hand.

The doc stays current because I keep it current, and it’s saved right next to the thing it governs, so it’s always within reach of the work it describes.

When you come back to the job a week later, the plan is exactly where the work is — not in your head, not in an old thread.

You already met this

The five-step loop named this in step 3: for a big job, have me write down the plan.

This is that plan in full — what goes in it, how it grows, and how it stays your check at the finish.

Open one whenever a job runs longer than a couple of exchanges, or whenever getting it wrong is expensive.

A quick ask doesn’t need one; it carries its own goal in the same breath.

The longer the job, the more a written target earns its keep — because the longer the job, the easier it is to drift.

The one thing to remember

When you want to build something, the first words are "write a spec for this."

That doc is our contract while we build and your QA long after — the fixed reference that keeps a long job honest from the first ask to the finished thing.

Next: turning a process you repeat into a reusable job.

Your agents. Your OS. Deployed in 60 days.