The plan that wouldn't die

Most repos contain a document nobody agreed to keep. Not the README. The plan: a roadmap, a migration note, an architecture sketch that was true in March. Nothing on it says whether it’s a promise or a sketch, so people read it as a promise long after it stopped being one. Code gets merged and tasks get closed, but a plan just stays, because nothing in the process ever ends it.

The plan was always a little wrong. What changed is who reads it. A new hire skims a stale roadmap and asks someone. An agent ingests it along with the README, the decision notes, and the half-finished spec, and then builds against it. The stale plan used to be a filing problem. Now it’s a premise, and a false premise is the most expensive context you can hand the thing doing your work.

And where the plan actually lives usually isn’t the repo at all. Ask Claude Code to plan something difficult and the plan lands in the .claude workspace. Codex has its own plan mode (/plan, or a PLANS.md template for longer work) and its own session store. That’s fine until you switch agents mid-task, because your usage ran out or a provider had an outage, and the plan doesn’t come with you. The thinking stayed behind in the tool.

Plans aren’t special, though. Vocabulary, decisions, and task state fail the same ways: no one owns them, they’re trapped in whichever tool touched them last, and nothing says when they stopped being true. The plan is just the one you notice, because it’s the one people keep reading as a promise.

One owner per artifact

Better plans won’t fix this. What fixes it, for plans and everything else, is a shape I call one owner per artifact: each kind of knowledge a project carries gets exactly one home, and it only changes at the steps that own it. The things that change also get a way to end.

• Vocabulary (the words the project uses for its own ideas) lives in one glossary.
• Decisions that are expensive to reverse live as dated records of what was decided and why, so nobody re-litigates them six months later.
• The living design, the current plan for one initiative, lives in a single document.
• Execution state (what’s ready, blocked, or done) lives in the tracker, separate from the design.
• Rules for how the project works live in the agent’s own instructions.

The glossary and the decision records only get written at two moments: when grilling a plan settles a term or a decision, and when a finished design’s lessons are promoted. Nothing else touches them. The planner doesn’t edit the glossary on a whim, the design doc doesn’t collect task status, and the tracker doesn’t carry the rationale.

A way to end

That last part is where this differs from most setups, which never define an end. The design doc is the only artifact with a real lifespan. It starts as a draft, becomes active, and finishes in one of three states: shipped, abandoned, or superseded by a newer design. While it’s active, it’s the authority for the initiative and gets rewritten in place whenever the design changes. Once it reaches an end state, it freezes.

Closing a design doesn’t delete it. You record what was actually verified against the criteria you fixed at the start, promote what’s worth keeping (a decision becomes a decision record, a settled term goes into the glossary), and stamp the date it ended. The plan is finished after that, but what it taught the project stays.

The agent never moves its own definition of done

The other half of this is trust. The criteria a design gets judged against are written at the start, by you, and the agent isn’t allowed to edit them. If a criterion turns out to be wrong or impossible, the agent stops and asks instead of quietly loosening it to fit what it built.

Unattended work follows the same rule. When an agent iterates on a design on its own, the loop has hard stops: a retry cap, a no-progress cap, and a handoff contract that authorizes a branch and a draft pull request and nothing else. Merging, deploying, and publishing stay with a person.

Review works the same way. An agent can record findings, file follow-ups, and give a verdict, but it can’t close its own review; the record stays open until a person closes it. So the one thing an agent never gets to do is move its own definition of done.

The skills

Dotbrain ships the skills that enforce all this as a plugin. Each one owns a single step in a chain, so they work more like a pipeline than a folder of prompts.

A design starts with a skill that orients (find-unknowns) and one that grills the plan until the vocabulary and the open questions are settled (grill-decisions). Then a skill writes the design doc and opens the work item that tracks it (to-design). Another cuts it into vertical slices, thin paths through every layer, each with acceptance criteria and dependencies, ordered so the riskiest decisions get validated first (to-issues). Execution claims one ready slice at a time and closes it (operate-execution). Under an explicit handoff, iterate-design runs the bounded loop from the previous section instead. When the last slice under a design closes, the close-out skill freezes the doc and promotes what’s worth keeping (close-design).

The remaining skills cover wiring, context hygiene, public-issue triage, and code and readiness review, and they follow the same one-owner rule.

Steal the shape

You don’t need the tool to use the idea. Four habits carry most of it:

• Give each kind of knowledge one home and one owner. Rules usually have a home already. The ones most projects leak are vocabulary, decisions, plans, and task state.
• Give anything that changes an end state, so a plan doesn’t keep getting read as current after it stopped being true.
• Write the acceptance criteria before the work starts, and treat them as yours, not the agent’s.
• Never let an agent close its own review.

All of it works by hand: a glossary file, a folder of decision records, one design doc per initiative, and a tracker kept apart from the rest.

What it costs

The skills are opinionated. Vocabulary, decisions, designs, and task state each get a prescribed home and a prescribed way to change, and the skills stop working if you bend that shape. On a multi-step initiative the structure is the point. On a two-line fix it’s ceremony, and you should skip it. The gates also cost attention, which is the thing they’re supposed to save.

The plugin is an ordinary public repo and installs with a couple of commands. The fourteen skills aren’t the reason to look, though. The reason is that a plan can be made to end.