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 week, someone assembles a status update by hand and sends it to the people who have to act on it.
What I'm building: a small status site that replaces the weekly update email
Who it's for: the three people who pick what needs a push this week
The decision or task it helps with: deciding which two items need a push
Source material: last week's update, the tracker export, owner notes
What done looks like: a reader opens one URL, sees this week vs last week, and can name the two push items within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the status update, 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. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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, an on-call engineer assembles an incident follow-up email by hand and sends it to the team.
What I'm building: a small follow-up board that replaces the Monday incident email
Who it's for: the three on-call engineers who pick this week's follow-ups
The decision or task it helps with: deciding which two follow-ups ship this week
Source material: the postmortem, the timeline, the ticket export
What done looks like: the team opens one URL, filters by service, and can name the two follow-ups within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the incident follow-up, and swap in your own repeated work — an incident postmortem, a triage note, a follow-up list, a service map.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 campaign lead assembles a ship-list email by hand and sends it to channel owners.
What I'm building: a small ship-list site that replaces the Monday campaign email
Who it's for: the three channel owners who lock this week's assets
The decision or task it helps with: deciding which two assets slip
Source material: the brief, the asset list, channel owners
What done looks like: a lead opens one URL, filters by channel, and can name the two slipping assets within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the campaign ship-list, and swap in your own repeated work — a campaign brief, a ship list, a channel calendar, a lock email.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 Tuesday, a designer assembles a brand-review deck by hand and sends it to the reviewers who sign off.
What I'm building: a small kit-review site that replaces the Tuesday deck
Who it's for: the two reviewers who sign off this week's assets
The decision or task it helps with: deciding which two pieces get redone
Source material: the deck, the design kit, the export folder
What done looks like: a reviewer opens one URL, filters by asset, and can name the two redo pieces within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the brand-review deck, and swap in your own repeated work — a brand-review deck, a kit list, an export folder, a redo note.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 support lead assembles a queue report by hand and sends it to the floor leads.
What I'm building: a small queue board that replaces the weekly volume email
Who it's for: the three floor leads who staff the Monday queues
The decision or task it helps with: deciding in the Monday huddle which queue needs the extra agent
Source material: the last eight weekly queue reports, plus the ticket export they pull from
What done looks like: a lead opens one URL, sees this week vs last week for each queue, and can name the extra-agent queue within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the queue report, and swap in your own repeated work — a queue report, a reply macro, an escalation note, a wait-time board.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 Thursday, an editor assembles a claims-clearance note by hand and sends it to the writers who ship Friday.
What I'm building: a small claim-check site that replaces the Thursday clearance note
Who it's for: the two editors who clear copy before it ships
The decision or task it helps with: deciding which claims stay
Source material: the spreadsheet, the source docs, last week's struck list
What done looks like: an editor opens one URL, filters by claim, and can name the lines that stay within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the claims-clearance note, and swap in your own repeated work — a claims sheet, a voice brief, a clearance note, a launch page.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 Wednesday, an analyst assembles a research readout by hand and sends it to the person who has to pick a finding.
What I'm building: a small findings site that replaces the Wednesday readout
Who it's for: the one decision-maker who has to pick a finding to act on
The decision or task it helps with: deciding which finding to act on
Source material: the readout, the cleaned export, the method note
What done looks like: a reader opens one URL, filters by cut, and can name the finding to act on within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the research readout, and swap in your own repeated work — a research readout, a cut list, a method note, a caveat board.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 quarter, a PM assembles a Q3 roadmap deck by hand and walks directors through it.
What I'm building: a small roadmap board that replaces the Q3 deck
Who it's for: the directors deciding Q3 scope
The decision or task it helps with: deciding which two initiatives need scope cuts
Source material: roadmap slides, launch dates, owner notes, the risk register
What done looks like: a director opens one URL, filters by team, and can name the two scope cuts within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the Q3 roadmap, and swap in your own repeated work — a roadmap deck, a risk register, a status roll-up, a QBR report.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 Friday, a recruiter assembles an interview debrief packet by hand and sends it to the hiring panel.
What I'm building: a small panel board that replaces the Friday debrief packet
Who it's for: the three panelists who decide who advances
The decision or task it helps with: deciding which candidate advances
Source material: debrief notes, the score sheet, the job brief
What done looks like: the panel opens one URL, filters by candidate, and can name who advances within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the interview debrief, and swap in your own repeated work — a debrief packet, an onboarding plan, a job post, a screen list.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 night, an on-call lead assembles a handoff note by hand and sends it to the next shift.
What I'm building: a small handoff board that replaces the night-shift note
Who it's for: the on-call lead running tonight's process
The decision or task it helps with: deciding which handoff is blocked
Source material: the SOP, last night's notes, the approval list
What done looks like: a lead opens one URL, filters by step, and can name the blocked handoff within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the handoff note, and swap in your own repeated work — a handoff board, an onboarding checklist, a runbook, an exception queue.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
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 Friday, an associate assembles a privilege-review memo by hand and sends it to the partners on the matter.
What I'm building: a small privilege board that replaces the Friday memo
Who it's for: the two partners who decide what can leave the firm
The decision or task it helps with: deciding which passages stay privileged
Source material: the memo, the source contract, the cite list
What done looks like: a partner opens one URL, filters by matter, and can name the passages that stay privileged within a minute
Why does this work? The audience is specific — named readers, not "the company." It serves a single decision. And the done-state is checkable: open the URL, find the answer in a minute, or it is not done.
You can copy this structure verbatim. Keep the five fields, throw away this example — the privilege-review memo, and swap in your own repeated work — a privilege memo, a redline, a cite list, a hold report.
That is the first builder move.
Next, write one brief for one repeated task from your real work. Type it in the notes field below, or in your notes app / AI tool — there was no box on this page until now. Keep it. The rest of this chapter builds on it. You can continue without signing in.
no box on this page until now. type below, in your notes app, or paste into your AI tool. park a thought is the same local scratchpad. continue works either way — no sign-in.