Make the plan outlive the chat
Derived from: my project's document taxonomy and the master index that governs it — a seven-type classification, a register listing every active document, and one rule the whole set answers to.
The AI is only as good as what it knows about your system. If that knowledge lives in your head, or scattered across forty old chats, every session starts from zero and drifts.
So I maintain documentation as the AI's operating environment, not as an afterthought for humans. Procedures for how work gets done, specifications for what the system is, an index that says where everything lives — and the AI reads the index first, every session. Which means every session starts with the accumulated decisions of every session before it.
One rule governs the whole thing: single source of truth. Any fact lives in exactly one place. The moment the same fact lives in two documents they will disagree, and the AI will confidently build on whichever one it read last. There's no such thing as too much documentation — unless the documents compete with each other. Two files claiming the same fact isn't too much documentation, it's wrong documentation, and it's the only kind that actually hurts you.
Have the conversation
This is the one to use. Fill in the four lines at the top, paste it into whatever AI you use, and it will open by naming three things about your idea it needs to know. It names the structure to the AI so nothing gets skipped, and tells it that every question has to be about your idea — if a question could be asked of any project, it's the wrong question.
I'm building something with an AI assistant, and I want to set up the documents it reads at the start of every session — so it knows what I've decided without me re-explaining it, and so there's one place every fact lives. Here's what I know so far: My field: [YOUR FIELD] What I'm building: [WHAT YOU'RE BUILDING] Who it's for: [WHO IT'S FOR] Where I am now: [WHERE YOU ARE NOW] Don't ask me those again. Build on them. How I want to work together: - You're the expert in how to organize this. I'm the expert in my field. When something depends on knowing my field — a document that convention or regulation expects me to keep, say — ask me. Don't assume it. - Work through the document types a project needs: what the thing is and the rules it must never break; what it has to do; how it's built; how to do repeatable work; the current plan; setup and reference; and what isn't built yet. Then cut — I'd rather have five documents I maintain than twenty I don't. Use that structure so nothing gets skipped, but don't explain it to me and don't ask me to pick a method. - Every question has to be about THIS project. If a question could be asked of any project, it's the wrong question. - One question at a time. If my answer is vague, say so and ask again. If I contradict an earlier answer, point it out. - When you recommend something, explain why, and give me the trade-offs if there's a choice to make. - The one rule: every fact lives in exactly one document, and everything else links to it. When we're done, give me the index — the read-first order, one row per document, and which ones I need this week versus later — written so another AI could read it and pick up where we left off. Start by telling me the three things about this project you'd need to know before you could tell me what needs writing down. Then ask me the first one.
What mine looks like
This is my version, genericized: the actual working document behind this rule. It's here so you can see what you're aiming at. You don't need to copy it — the prompt above does the work — but it's a real file from a real build, and if you want the raw material, take it.
DOCUMENT TAXONOMY — every document is exactly one of these types.
| Type | Holds | Lives | Lifecycle |
|---------------|-----------------------------------------|------------|-----------|
| Design | How the system is built; interfaces | /docs | Living |
| Specification | What it must do; contracts; workflows | /docs | Living |
| Procedure | Repeatable how-to; checklists | /docs/sop | Living |
| Plan | A specific effort, with an end date | /docs/plans| Delete when done — extract value first |
| Guide | Setup, configuration, tuning, reference | /docs/guides| Living |
| Principles | The rules everything answers to | /docs | Living |
| Backlog | What isn't built yet | /docs | Living |
THE INDEX — one document registers all the others. It contains:
1. Read-first order for someone brand new (human or AI)
2. One row per document: name, location, purpose, when to read it
3. Role-based paths: "if you're doing X, read these three"
4. A common-questions table: question -> which document answers it
5. A deleted-document registry: what was removed, when, and where its
content went. Deleting is part of maintaining a single source of truth,
and the registry is how you delete without losing anything.
6. A version line, so a reader knows how stale it might be.
THE ONE RULE — single source of truth.
Any fact lives in exactly ONE document. Everything else links to it.
Hierarchy when sources disagree:
1. The code / the system itself
2. The dedicated document for that topic
3. Overview documents (which only summarize and link)
Cross-reference, don't copy:
- Bare link: "See [doc] for the run commands."
- Link + one line: "[One sentence]. See [doc] for detail."
- Short summary: 2-3 sentences maximum, then link.
If you're writing more than three sentences of summary, you're duplicating.
Link instead.
MAINTENANCE
- Updating affected documents is the last step of each piece of work,
not deferred cleanup.
- When a fact changes, change it in its one home. If you find yourself
editing it in two places, you've already got the bug.
- Before creating a document, check the index. If something covers the
topic, update that instead.
If you have nothing today, start with one page. Not the taxonomy — one page, called the rules of your product, that answers: what is this, who is it for, what must always be true, what must never happen, and what are we deliberately not doing. Load it into every AI session. That single page will do more for output quality than any prompt engineering, and the structure above is where it grows when one page stops being enough.
The hard part
The hard part is deciding which single document owns a fact. That's where the real arguments are, and it's the decision no tool will make for you — every duplicated fact in a project started as two reasonable people (or two sessions) each thinking their document was the right home for it.
It's easy to treat documentation as a tax paid after the work. Treating it as the AI's operating environment inverts the economics: the document you write today is read by every session after it, so the payback is immediate rather than hypothetical. The single-source rule is what keeps that compounding instead of rotting.