Tracking the work, and handing it to a builder
The goal here is that you, your builder, and I always agree on what’s planned, what was decided, and what’s rubbing in your domain — without a meeting to settle it.
Written in your agent’s voice: this is how it talks to you in your workspace.
Three written records do that, and you own all three.
The three records your domain carries
Your domain carries three records, kept next to its knowledge and skills — real files, one set per domain.
You own all three: anyone in the domain can read them, and you answer for what they say.
I keep them current as you work, so the state lives in the files instead of in anyone’s head.
Record 1 — ROADMAP.md
What is planned.
The queue of work your domain has decided to do — here is the live supply-chain roadmap.
Shipped work stays on it too, checked off, so one file holds both the plan and the record of what landed.
Say "add this to the roadmap" and I file it, dated, in your words.
Record 2 — DECISIONS.md
What was decided, and why.
A choice made without the why written down is a choice the next builder reinvents, usually differently — the supply-chain decision log is what prevents that.
Each entry is append-only: a later decision that reverses an earlier one links back to it, so the reasoning chain stays readable.
Say "log this in DECISIONS: we chose X because Y" and the reasoning is held.
Record 3 — FEEDBACK.md
What is rubbing.
Every correction, re-ask, and miss in your domain lands here — when an end user says "turn this into feedback," this is where it goes, and you are who it reaches.
An end user can flag the friction, but only you can act on it: that is the boundary between using the domain and owning it.
As owner you drain it at your cadence — read what came in, decide what each item asks for, then move it to the roadmap or close it.
That drain is how your domain’s knowledge stays current instead of quietly aging.
Handing work to a builder
As domain owner you change your domain’s knowledge and skills yourself, right then and there.
The deeper machinery — rules, hooks, commands, connectors, the wiring — belongs to a builder, and the handoff is a roadmap entry.
A complete entry carries three things:
- What — the outcome you want, in plain words.
- Why — what it’s costing you today, or what it unlocks.
- What good looks like — how you’ll both know it shipped right.
Here’s one, in real words: "Flag any client invoice that’s gone unpaid past sixty days — we keep finding them too late; good looks like a weekly exception list per client."
Say "put this on the roadmap for the builder" and I write the entry with you, all three parts.
If you can’t fill the three parts yet, leave it in FEEDBACK until you can.
The written entry is the source of truth, never the meeting — when a call and the roadmap disagree, you update the roadmap.
Status is a question
Ask me "what’s on the roadmap, and what shipped?" and I read the records live and answer — current the moment you ask.
No one compiles a status report, because the records already carry the state.
The decision log answers the same way: ask "why did we choose X?" and I quote the entry back, dated, with the reasoning.
This works for any domain you own, because the same three records sit alongside every domain’s knowledge and skills.
The one thing to remember
ROADMAP holds what’s planned, DECISIONS holds what was decided and why, FEEDBACK holds what’s rubbing — and a builder handoff is a roadmap entry with its what, its why, and what good looks like.
Keep the records honest; they do the coordinating for you.
Next: owner anti-patterns