Your first builder brief
Before a tool exists, the job needs to be named clearly.
A vague prompt asks AI to guess. A builder brief gives the tool a job. This matters because everything you build later — rules, checks, versions — hangs off how clearly you named the job at the start.
Here is the template:
What I'm building:
Who it's for:
The decision or task it helps with:
Source material:
What done looks like:
Five fields. None of them technical. You are not trying to sound like a developer. You are making the work inspectable.
A blank template is hard to start from, so here is one filled in. The scenario: every Monday, a PM assembles a metrics email by hand and sends it to leadership.
What I'm building: a small metrics site that replaces the weekly metrics email
Who it's for: the three product directors who read the Monday email
The decision or task it helps with: deciding in the Monday sync which initiative needs attention this week
Source material: the last eight weekly metrics emails, plus the dashboard exports they pull from
What done looks like: a director opens one URL, sees this week vs last week for all five metrics, and can spot the off-track one within a minute
Why does this work? The audience is specific — three named readers, not "leadership." It serves a single decision: which initiative needs attention this week. And the done-state is checkable: open the URL, find the off-track metric in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away the metrics scenario, and swap in your own repeated work — a status deck, an onboarding doc, a runbook, a QBR report.
That is the first builder move.
Next, write one brief for one repeated task from your real work, and keep it — the rest of this chapter builds on it.