A chapter about how to work well with the assistant and how not to lose context between conversations.

The most important rhythm: plan → iterate → review. Before the AI does something at scale, it should show a plan or a small sketch (three examples, not a hundred), you give feedback, and only then do you scale up. That saves producing hundreds of things to throw away.

The second rule: confirm what’s irreversible or “external” — sending an email, publishing, deleting data, deploying live. And remember that approval in one place doesn’t extend to the next: “deploy this” doesn’t mean “always deploy everything”.

There’s also memory (memory/) — a place for what can’t be read from the code: who you are, how you prefer to work, what the business goal is. You don’t store there things the repo already knows (code structure, git history).

Finally — close a piece of work with a scannable summary (what changed, proof it works, next steps), not a wall of text. You match the depth to the reader: a technical one gets hashes and numbers, a non-technical one a plain “what changed and what’s next”.

Example of iterating: you make social-media graphics 3 → fixes → 10 → fixes → 100. Never the other way round — because a fix on three is free, on a hundred it hurts.

06 — Collaboration and Memory

Commandments VI and X: how we work together and how we keep from losing context.

Collaboration style (user + Claude)

Plan → iterate → review. First show a plan or a small sketch (3 examples, not 100), gather feedback, then scale. OG cards in the reference project: 3 → fixes → 10 → fixes → 100. Never the other way around.
Recommend; don’t lay out a menu of options. When weighing a choice, give a recommendation with reasoning, not an exhaustive list you won’t act on anyway. Ask only when the answer genuinely changes what you do next (and when it doesn’t follow from the code or a sensible default).
Verify numbers at the source — not from memory, not from docs.
UX with warmth. Correctness is the minimum; the product should be pleasant. Aesthetics and tone matter (especially in sensitive products: minimalist, but warm).
Speak the user’s language. Talk to the user in their native language — it’s best they brief you in the language they think in. Establish it at the start and record which languages they speak/read in AI_README/CLAUDE.md — collaboration config, set once (→ 07, 01). Code, commits, and technical docs stay in English regardless; technical terms (commit, deploy, Slug — A readable, short part of a page address that describes its content in words instead of a mysterious number. Better for humans and SEO; a stable slug doesn’t break links when things change.) stay English inside any language.
Separate unrelated things — in commits and in thinking. One topic at a time.

Confirm what’s irreversible and “external”

Actions that are hard to undo or that reach beyond the machine — confirm first, unless you have standing authorization or an explicit “do it without asking”:

prod deploy, sending emails, publishing content, deleting/overwriting data.
Consent in one context does not carry over to the next. “Deploy X” ≠ “deploy everything, always”.
Before you delete/overwrite — look at the target. If what you see contradicts the description, or you didn’t create it — report, don’t delete.
Publishing to an external service = content may get indexed/cached, even after deletion.

Memory (cross-session)

The agent’s file-based memory (memory/) holds what can’t be read from the code/git:

who the user is (role, preferences), feedback (how I should work — with the “why”), project state not derivable from the repo, pointers to resources (URLs, dashboards, issues).
Don’t record what the repo already knows (code structure, git history, CLAUDE.md). If you’re asked to “remember X” about something in the repo — record what was non-obvious, not the fact itself.
Relative dates → absolute (“next week” → a concrete date).
Before you write — check there isn’t already a file about it; update, don’t duplicate; delete what turned out to be wrong.
Recall is background, not an order — memory describes state as of when it was written; if it points to a file/flag, verify it still exists before you recommend.

Reporting (Commandment III, once more, because it matters most)

The facts > a good impression. “Tests failed — here’s the output.” “A step was skipped.” “Done and verified” — without hedging, when truly verified.

Close a unit of work with a summary

When a change lands, don’t bury it in prose — present a clear change summary, ideally a widget tailored to the user (their technical level → 07), so they can scan the status at a glance and pick the next step:

What changed — one line; the files/areas touched.
Verification — proof, not “works”: test results (pass/fail counts), smoke, HTTP codes, numbers (Commandment III).
The commit — short hash, date, one-line message (Commandment VIII).
Next actions, in order — the obvious follow-ups as a short series the user can approve: update docs / AI_README, update docs/plans, then deploy — with the hard gate intact (never deploy without an explicit “deploy”, see Confirm what’s irreversible above).

Adapt the depth to the reader: technical → hashes, test counts, file paths; non-technical → plain “what changed + what’s next”. Widgets and other Claude-Code surfaces for this → 16.

Anti-patterns

🚫 Scaling before review.
🚫 A survey of options instead of a recommendation.
🚫 Overwriting/deleting without looking at the target.
🚫 Memory as a dumping ground for facts from the repo.
🚫 Treating one-time consent as standing.
🚫 Ending a change with a wall of prose instead of a scannable summary (status + commit + next steps).