General Practices

Appearance

THE METHOD — how Daniel and Claude ship together ​

What this is. How Daniel and Claude build together, written generically so any new project can start with it on day one. Every practice here is a countermeasure to a problem that any fast-moving project with an AI collaborator will hit. Nothing in it is specific to a product.

THIS FILE IS CANONICAL (since 30 Sep 2026). It merges the three generations that came before it. Each is now a pointer here or a copy that only ever flows FROM here (see §10):

  • RookWorlds, where it was written (25–26 Aug 2026): the doc, and its runbook follow-the-method
  • Task4ce, which added working as a pair (§8)
  • BrandMoves/BrandTactics (Sep 2026), which put it to work on a real codebase: the values, the shape of a task, the gates, system health

How to use it. Hand this file to the first session of a new project and say: read this, then set up stage 1. Claude proposes the smallest version that fits the project today, not all of it at once. §6 says what to build when. The operating half, meaning what to do right now and where things go, is the runbook skills/follow-the-method/SKILL.md.

The one-line version. Claude forgets everything between sessions and Daniel ships faster than he documents. So the project itself has to carry the memory, and the discipline has to be built into the tools:

  • a capped handoff for where we are
  • runbooks for how to operate what we built
  • a health reading for what exists and what is rotting
  • gates that make failure loud, or impossible, instead of relying on anyone to remember

0. The premise ​

Two facts drive everything:

  1. Every session starts blank. Claude has no memory of the last session. Whatever is not written down gets worked out again from scratch, and that is where wrong turns come from.
  2. Shipping is faster than documenting. With an AI collaborator, the time from need to shipped collapses to minutes. Ideas get juggled, several land in one session, and the ones that lose become dropped threads.

Together they produce two failure modes, and every rule below fights one of them:

  • Knowledge evaporates. The reasoning behind a decision lives only in a chat log nobody reads again. The next session works it out again, differently.
  • Work rots silently. A replaced system stays in the tree looking alive. A migration never gets applied. A doc keeps describing the old version. Nothing errors.

The answer is not more discipline. Systems beat effort. Put knowledge where the next session will trip over it, make rot loud, and where possible make the failure impossible rather than something to remember.

1. The foundation: why and how code is shaped ​

For code projects, the Method sits on top of THE FOUNDATION (D:\foundation, the template every code project is copied from). This file cites it and does not restate it:

  • Values (docs/VALUES.md):
    • Absurd standards: measure the best version first-hand, ship the considered version first, done means seen working.
    • Infrastructure first: ask what exists before building; one authority per fact; make a failure impossible rather than remembered.
    • Procedural approach: break it into steps; one whole idea per task; plan before code.
  • Architecture (docs/ARCHITECTURE.md): THE FOLDERS ARE THE SYSTEM. There are four layers, with dependencies pointing down: interfaces/ → features/ → domain/ → infrastructure/.
    • Features never import each other.
    • Business rules never live in screens, routes or queries.
    • Change a shared piece in place; never copy it.
    • Changing the stack is a recorded decision and the owner's yes.
  • The build runbooks (.claude/skills/): plan-a-build, prove-it, escape-hunt, ship-it.

How the code is kept from turning into spaghetti, meaning the ideas and the tools, is its own method: methods/FIGHTING-SPAGHETTI.md.

2. The five artifacts ​

2.1 THE HANDOFF: where we are, capped by a number ​

One file at the top of the project, read first by every session. It says where we are, what is next, what bites, and points to everything deeper. It is DISPOSABLE and always current: a launchpad, never a log.

The cap is a NUMBER, and a script enforces it. The handoff has fixed sections, each with a maximum line count and item count, plus a hard cap for the whole file. When a section is full, its oldest item is ROUTED to its permanent home and DELETED from the handoff.

  • The template is in D:\foundation\HANDOFF.md.
  • The check is scripts/check-handoff.ps1. PASS = CAP CHECK: PASS.
  • BrandMoves ported the check to Node, check-handoff.mjs, so it also runs on Linux.

The failure that bought it: under the rule "keep it to one screen", the file reached 2,962 lines. "One screen" is not a number, so it never bound.

The second half of that lesson matters more: a missing destination is the real failure mode. The sprawl happened because the roll-off rule said shipped work goes to the changelog, and one repo had no changelog. If something has nowhere to roll off to, CREATE THE HOME FIRST, then roll.

A trap that stays in WATCH OUT is a failure the system still allows. Make it impossible, then delete the line.

2.2 THE HOMES: every fact has exactly one address ​

Kind of knowledgeHome
Where we are, what is next, what bitesthe handoff (capped)
What shipped and whendocs/CHANGELOG.md, one line per arc
How a system actually worksdocs/concepts/<system>.md
Traps found by buildingNOTES.md, appended, never rewritten
This project's modules and architecture decisionsdocs/DECISIONS.md (ADRs)
What already exists in the code, to reusea search read from the code itself (§2.4), never a list typed by hand
How to OPERATE a systema runbook, .claude/skills/<job>/SKILL.md (§2.3)
Tasks, subtasks and hoursthe task tracker (Task4ce)
Why, decisions, preferences, correctionsClaude memory
Vision and creative truthwherever the human thinks best (Notion)
Data: content, catalogues, anything that changesthe database, never code or repo files

Route, then DELETE from the source. A fact that lives in two places will disagree with itself within a month. Cite the canon; never restate it. A paraphrase is a second copy that drifts.

The test before writing anything into the handoff: would a session six weeks from now be worse off if this line sat in a concept doc behind a pointer instead? If no, it goes in the concept doc.

2.3 RUNBOOKS: how to operate what you built ​

A runbook is a folder with a SKILL.md inside the repo (.claude/skills/<job>/SKILL.md). Every session automatically sees each runbook's name and description; when a task matches, the full runbook loads. It is the highest-leverage artifact here.

  • Why "runbook": Claude Code calls these files "skills". BrandMoves calls them runbooks because the word "skill" belongs to what a product serves its clients. Use whichever fits; the file is the same.
  • Docs vs runbooks: docs explain how a system works; runbooks answer how do I RUN it.

Every runbook opens with THE ONE TRUE SYSTEM and names its graveyard. The most expensive class of mistake is operating a dead generation of a system that still compiles. "Canon is X; if you are in Y, STOP, that is the old version" prevents a whole class of wasted session.

A system ships WITH its runbook, unprompted. If a session builds or materially reworks something operable, it writes or updates the runbook before wrapping up, the same way it updates the handoff. The human should never have to ask.

Anatomy:

  1. THE ONE TRUE SYSTEM, with the GRAVEYARD warning and real symbol names
  2. Entry points, verbatim (commands, menu strings, routes)
  3. The knobs someone actually tunes, each as file:line with a one-line meaning
  4. Verification: which artifact to read, and what PASS literally says
  5. Traps, each with its consequence
  6. OPEN QUESTIONS: what is unverified, so the next session inherits the leads and not only the certainties

The description is the only line every session sees, so it carries the TRIGGER PHRASES, not just the subject. Write it as "load when <situations>", not "about <topic>".

A runbook's text lives in exactly one place: the file. A tool may keep a reference to it as data (where it is, what it covers, whether it is stale, what links to it), but never a copy of the text. A copied runbook is a second runbook that drifts.

2.4 SYSTEM HEALTH: what exists and what is rotting, measured ​

The first generation (RookWorlds) was a health map: database tables for every system, the links between systems, and a ranked queue of findings. A scanner refreshed it, and an admin page drew it. Before building, a session asks it four questions:

  1. Does this already exist?
  2. Is what I am about to touch alive, or a graveyard?
  3. What is already known to be broken here?
  4. Does this cross a seam that two clients depend on?

The second generation (BrandMoves) kept the questions and made the reading part of the build loop:

  • One tool (health) measures whether the code is getting simpler or messier.
  • A baseline that only goes down.
  • Readings are taken before and after. The reading is taken before a plan can start; the close refuses anything worse.
  • The "does this exist?" question is answered from the code itself (find), so it is never stale.

Details, tools and the catalogue of checks: methods/FIGHTING-SPAGHETTI.md.

Why data, not a document: a markdown map is true the day it is written and drifts silently afterwards. A measurement can be re-run and queried.

2.5 MEMORY: the why, one fact per file ​

Claude memory holds what the repo cannot: decisions, preferences, laws, and the reasoning behind them. It is one fact per file, with an index line for each, linked to related facts.

  • What belongs: why we chose this, what the human vetoed and why, laws that outlive any file.
  • What does not: anything the code, git history or docs already record.

Memory is where a correction becomes a law. When the human pushes back, that feedback is worth more than the fix itself: write it down as a rule, with its why and its how-to-apply.

3. The shape of work ​

3.1 A task is a whole idea ​

A TASK IS A WHOLE IDEA. A SUBTASK IS AN ATOMIC PART OF THAT IDEA, NEVER A SESSION. One major task = one session = one branch = one PR = one merge. A session that finishes a subtask and stops has not finished anything; it takes the parent task and does all of it.

  • Writing work down: ask "is this a thing on its own, or a piece of a bigger thing?" A migration, the feature it enables and the check that proves it are ONE task in three parts. They live in the same files, and splitting them buys three gates and three reviews for one idea.
  • Something found mid-build hangs off the task it belongs to. A new top-level task is for a new idea, not for a loose end.
  • What it cost: five branches in one evening cost more in gates and merges than the work did (BrandMoves, 16 Sep 2026).

3.2 The loop: talk → plan → build → prove → close → ship ​

  1. Talk before building. Discuss the shape of a thing before creating or moving anything. Read-only exploration is always fine.

  2. Plan before code (runbook plan-a-build). The plan names:

    • what it is for
    • what already exists and will be reused (asked of the code, not of memory)
    • which layer it lives in
    • what proof will show it works

    In a mature project, a guard refuses code edits until a plan exists.

  3. Build on its own branch, in its own folder: one session at a time, never on main.

  4. Prove it on real things (runbook prove-it). Done means seen working: the page looked at, the artifact read, the number measured. A green checkmark alone never counts.

  5. Close with one gate that runs every check, cheapest first, and leaves a receipt the push trusts. Read each PASS line. An independent reader goes through the diff looking for workarounds the checks missed (runbook escape-hunt).

  6. Ship (runbook ship-it). Once the gates exist, shipping does not ask: the session that built the change merges it, migrates, deploys, looks at it live, and then says what landed. What still asks is anything that costs money or touches something outside the project.

3.3 Mechanisms: nudges for rituals, walls for laws ​

A behaviour is exactly what an amnesiac collaborator cannot be relied on to perform, so the rituals and laws become mechanisms (hooks, scripts, gates):

  • Rituals get nudges. A session-start hook injects the handoff and the measured git tips. A stop hook names any close step that was skipped. Silence is PASS. They are non-blocking by design, because a hook that nags on every turn gets disabled.
  • Laws that protect the code get walls: no edits on main, no code before a plan, no new code file outside the four layers, and the close refuses messier code. Every wall says exactly how to get through it properly.
  • Traps of mechanisms:
    • Silence from a nudge looks identical to a broken hook. If a lot has shipped and nothing was said, run it by hand once.
    • A mechanism that guarantees the text was loaded does not guarantee it was read.
  • A check that changes nothing gets cut. Every gate costs time on every run; it has to earn its place.

4. The laws ​

These are about behaviour, and each one was bought with a real failure (§9).

  • Loud fallbacks. Every fallback announces who degraded and why. The worst kind returns a plausible VALUE; the next worst names a plausible CHORE.
  • Verify from artifacts, not from a green checkmark. A command returning OK means it ran, not that the work succeeded. Read the log, check the timestamp, look at the output.
  • A control that cannot fail proves nothing. Before believing a "no difference" result, feed the method a known difference of known size and confirm it reports it.
  • Test the property, not the name. A guard that checks what something is called keeps passing after the name stops meaning it. When you find one bad predicate, grep for it everywhere.
  • Name the graveyard. When you replace a system, delete the old one or label it loudly in its own file. A stale doc describing the previous generation is the same defect.
  • Data lives in the database, not in code or repo files. Code is logic only.
  • One authority per fact. One place decides each number and everyone else reads it. With two humans or a shared backend, this covers live infrastructure too (§8).
  • Make it impossible, not remembered. A rule that depends on someone remembering it will be forgotten by a session that starts blank. Put it in the database's constraints, the types, or a gate.
  • If you cannot see it, build the way to see it.
  • Do not re-litigate a solved fix on one unverified symptom. When a fix is proven, mark it as law in the code.
  • Say what you did not do. Skipped, blocked, unverified: say so plainly. Silence about a gap is worse than the gap.
  • Label a guess as a guess. A labelled guess is useful; an unlabelled one costs a session.
  • Excellent over more. When in doubt, don't add it.

5. The rituals ​

Start.

  1. With a second human, git pull first (§8).
  2. Read the handoff end to end. It is capped, so this is cheap and there is no excuse for skipping it.
  3. Follow at most ONE pointer for the task at hand.
  4. Begin.

During. The moment something durable is learned, write it to its home immediately and put a POINTER in the handoff, never the content. "I will move it later" is how the 2,962-line file happened. There is no later.

Close. Every session that shipped something:

  1. Update the handoff STATE and RESUME HERE against the real git tip.
  2. Add shipped work as one-liners to the changelog, and roll the oldest handoff entry out.
  3. Confirm anything durable is in its home (a concept doc, the notes, memory), and NOT only in the handoff. No mechanism can check this step, and it is the one that loses the most when skipped.
  4. If the session built or reworked something operable, write or update its runbook.
  5. Run the cap check and make it pass.

6. Day one: what to build, and when ​

Do not build everything on day one. Each piece has a point where it starts paying.

Stage 1, the first hour.

  • CLAUDE.md: what this is, the conventions, the homes, the rituals.
  • HANDOFF.md, with its cap table and check, even if it says "nothing shipped yet". Caps are easy to adopt early and painful to retrofit.
  • For a code project, also: copy the foundation, which brings the values, the four layers and the build runbooks.

Stage 2, once there is a system somebody could operate wrongly. Write its runbook. Triggers: a build step whose order matters, a generator with knobs, a deploy ritual, any tool where the obvious way is the wrong way. One runbook is enough to start.

Stage 3, once there is code worth protecting. Take the first health reading and set the baseline, add the close gate, then the plan guard. BrandMoves' verdict (28 Sep 2026): fighting spaghetti code is not a nice-to-have; it is the bare minimum before any work. The folders and the reading are cheap early and very expensive to retrofit. The map with tables and a page waits until the project has more systems than a person can hold in their head (roughly fifteen, or a backend shared by two clients).

Stage 4, when the rituals keep being skipped. Turn them into hooks (§3.3).

Stage 5, when docs start sprawling. You will know you are here when two documents disagree. Write the routing table into CLAUDE.md and route.

Always on from day one: the laws (§4), the rituals (§5), the shape of a task (§3.1).

7. Starters ​

Copy these; do not retype them here.

  • CLAUDE.md and HANDOFF.md seeds: D:\foundation\CLAUDE.md and D:\foundation\HANDOFF.md
  • The cap check: D:\foundation\scripts\check-handoff.ps1
  • Runbook anatomy: §2.3 above; worked examples are in D:\foundation\.claude\skills\
  • A non-code project uses the same CLAUDE.md and HANDOFF.md and skips the four layers.

8. Two humans, one METHOD (added 26 Aug 2026, when Task4ce became a pair) ​

A second human changes three things and nothing else:

The handoff becomes shared state.

  • It lives on main and is only trustworthy after a pull, so the start ritual gains a step zero: git pull, THEN read.
  • Threads in RESUME HERE get an owner tag when claimed, because two sessions silently taking the same thread is the new failure mode.
  • The close ritual's handoff update travels inside the same PR as the work it describes.

Main becomes a merge target, not a workspace. Each human works on their own short-lived branches; main stays deployable; the gates run on every PR. Never force-push anything shared.

"One authority per fact" now covers live infrastructure. Git cannot merge a shared database or a shared deploy target, so changes to them are serialized by ritual:

  1. Check what is applied.
  2. Apply only from an up-to-date main.
  3. Make the change, update the mirror and announce it as one act.

The runbook for that system carries the exact steps.

Everything else is unchanged. It was already built for collaborators who cannot read each other's minds; a second human is just one more session that starts blank.

9. What to say (phrases that work) ​

  • "Verify it." Run it, read the artifact, show me the output. Not "it should work".
  • "Use the systems we built." The generated path first, never a hand-made one-off. If the generated result reads wrong, fix the generator rather than replacing it with a one-off.
  • "Does this already exist?" Ask the code before building.
  • "Name the graveyard." Tell me what the dead version is called so I do not bring it back.
  • "Write the runbook." This is operable now, so make it operable by the next session too.
  • "Is that measured or assumed?" The most useful question in the whole method. It turns a plausible story into either evidence or an admission.

The evidence: what each rule cost ​

  • The 2,962-line handoff. "Keep it to one screen" is not a number. Caps are integers now, and a script enforces them.
  • The 19 parkless days. A builder could not find a prefab and logged "run Build Park once". It read like a to-do, not a defect, so for 19 days it built towns with no park.
  • The name test. A guard asked is it called x_ instead of is it actually x, and quietly deformed what it was meant to protect: 5,495 of 7,613 vertices moved. The same bad predicate sat in a second file, pinning the wrong object.
  • The stale doc pointing at the corpse. Two docs and a code comment described a replaced generator as the real one, weeks after it was gone. Every runbook names its graveyard because of this.
  • The click that never fired. A UI bug was diagnosed by a ten-line test page that watched the events, instead of by reasoning. The test took two minutes and turned a hypothesis into a fact.
  • The four unapplied migrations. They were written and committed but never run. Nothing errored, because clients fell back to defaults. A scanner check found them and now runs every time.
  • The mirror check that read zero. The mesh was symmetric, so "no difference" looked exactly like a pass.
  • Four rounds on a stale build. Screenshots were judged of a build that had never recompiled.
  • Five branches in one evening. The gates and merges cost more than the work did. A task is a whole idea.

10. Where this came from, and the copies ​

CopyStatus
D:\general-practices\methods\THE-METHOD.mdCANON (this file)
D:\general-practices\skills\follow-the-method\SKILL.mdthe operating half; the doc wins when they disagree
D:\rook-worlds\rook-worlds-product\docs\THE-METHOD.md + its follow-the-method runbookfirst generation (25–26 Aug 2026), to become pointers here
D:\task-4ce\docs\METHOD.mdcopy of the first generation plus §8, to become a pointer here
Notion, "THE METHOD :: How Daniel and Claude ship together"shareable mirror, downstream only; refresh from here
BrandMoves (CLAUDE.md, docs/VALUES.md, its runbooks)where §1, §2.4, §3 and the newer laws were proven; points here

Merged 30 Sep 2026 from the RookWorlds doc and runbook, Task4ce's §8, and BrandMoves' working practice. Specifics (repos, products, schemas, vendors) are deliberately left out.

Linked from