How I Work with Claude Code

One person ships what Groupthink ships because the rules are written down in files the agents read. The full set is on one page: How I work with Claude Code. It covers the configuration layer, the path from issue to production, the checks that run against production, and the file shapes and prompts to build the same thing. Each rule there carries the date it was written and the incident that produced it.

The eight mechanisms below do most of the work. That page is also served as plain markdown, so you can hand the address to your own agent and ask what your setup is missing.

1. A file per repository, read every turn

Claude Code reads CLAUDE.md at the root of a repository at the start of every session, and a global one above it. This is not documentation for humans who might read it. It is read every time, by everything, which is why an agent working at three in the morning makes roughly the decision I would have made.

2. Rules carry a dated why

Format: the instruction, then a Why line with the date and the incident. Two reasons. An undated rule cannot be retired, because nobody can establish whether the condition that produced it still holds. And the reasoning is only recoverable at the moment it is written. When I correct the same class of mistake twice, the correction becomes a rule instead of a third correction.

3. Behaviour loads always, procedure loads on demand

My global file reached 9,540 words on August 26, growing about 200 a day, because every new rule was appended to it. Behavioural rules were outnumbered thirteen to one by procedure. Nothing was deleted. Procedure moved into separate documents, indexed by a table mapping each to the task that triggers reading it. The test when adding a rule: does this apply every turn, or only to one kind of task.

4. One session, one checkout, enforced by a hook

Two sessions sharing a working directory will land commits on each other's branches. Each session gets its own git worktree, and a pre-tool hook blocks branch-mutating git commands in a shared primary checkout. Detection is structural: a worktree has .git as a file, a primary checkout has it as a directory.

The part worth copying is the second half. That hook has been found switched off three times, and in each case the documentation, the repository, and the settings all read as protection while nothing was enforced. Install by symlink, never by copy. A script now runs the installed hook daily and asserts it denies what it should. A guard nobody verifies on a schedule should be assumed off.

5. The review is an artifact on the pull request

The session that wrote the change requests the review, and the review is posted as a comment. A session reading its own diff is not a review. Green CI is not one either, since CI demonstrates only that existing tests still pass. The reviewer runs on the strongest available model, on the principle that a reviewer should not be weaker than the sessions writing the code, and gets a read-only shell so it can check findings against source rather than inferring from a diff. Findings are claims: in one August release, three would have broken the feature if applied as written.

6. Green is a thing you read, on the head commit

An agent reporting merge-ready is not evidence. The merging session reads the checks on the head commit, again after every push. A path-gated job reporting success in seconds means nothing was tested. No check run at all is not a passing run. Required status checks on the protected branch move the enforcement off the session and onto the platform.

7. A numbered battery against production, every morning

About thirty checks: signups, transactional email volume, deploy failures, queue errors, the error tracker, cancellations, support mail. The rule that took longest to learn is that an absence has at least two causes. Zero emails sent can mean broken, or it can mean nothing was due. Every absence-shaped check specifies a second query that separates the two, and it runs before escalation. The corollary is that flattering readings get less scrutiny than alarming ones.

8. Four terminal states, and a reminder is a defect

Every request ends in exactly one of: done and verified; done with judgment calls documented; escalated as a single packet with options and a recommendation; or parked with a durable carrier created before the session ends, meaning an issue, a calendar event, or a scheduled trigger. There is no fifth state. I send a request and drop it, so my memory is never the persistence layer. If I have to remind the system of something, the task gets handled and then the class of failure gets a rule, a routine step, or a hook.

Where to start

Not with the whole system. Open a session in one repository and paste this:

Create a CLAUDE.md at the root of this repository, under 500 words.
Include only what must be considered on every turn: how to work with me,
the branch and pull request rules, and what to do before opening a pull
request. Move anything longer into a file under docs/ and add a row to a
"Load on demand" table in CLAUDE.md stating when to read it. Give every
rule a Why line with today's date and the reason. When you finish, list
the three rules you are least confident I actually want.

Then argue with what it wrote. Mine only looks the way it does because every rule in it replaced something that went wrong once.

The reference page has the rest: the file shapes for memory files, the decision log, the production checks, and nine more prompts. The parts about running this from a phone are in the Italy post and the Travel Mode post.