---
id: "14.2"
title: "How we work with Claude"
dept: people-and-ways-of-working
status: draft
owner: Param
branded: false
last_verified: 2026-10-26
sources:
  - "brew origin/main a559de6: CLAUDE.md (top, 'Every brand, every platform', 'Release rhythm'), deploy.sh:7-16"
  - "handbook/AGENTS.md 'How to use it, as a Claude session', 'Rules that never bend'"
  - "/Users/param/Documents/ChatGPT/.claude/settings.json Stop hook; .claude/skills/handbook-update/SKILL.md"
  - "memory MEMORY.md, feed-for-all-brands, fix-as-product, brew-qv-process, brew-parallel-sessions-deploy, always-deploy-to-test, no-spend-while-building, prod-clean-only, brew-one-version (index line), never-disconnect-arata-meta, brew-external-data-skill (index line), brew-prod-backend, brew-handbook"
  - "handbook content/engineering/parallel-sessions.md"
---

# How we work with Claude

## Answer

Most of Brew is built by Claude sessions that Param directs, several at once, and this page sets out how a session starts, what it must read, the rules every session follows, how sessions share one repo safely and how what they learn is kept.

## Today

### Where a session gets its context

| Context | What it holds | Source |
|---|---|---|
| Memory folder `~/.claude/projects/-Users-param-Documents-ChatGPT/memory/` | One note per project, rule or lesson, dated; `MEMORY.md` is the index loaded into every session | [src: memory MEMORY.md] |
| `brew/CLAUDE.md` | Scope, dummies, the outside-data rule, every brand and platform, release rhythm | [src: brew/CLAUDE.md] |
| `handbook/AGENTS.md` | Start here for any planning or document work | [src: handbook/AGENTS.md] |
| Skills | `brew-external-data` before any outside-data change; `handbook-update` after any change the handbook describes | [src: memory brew-external-data-skill] [src: .claude/skills/handbook-update/SKILL.md] |
| Plans | Approved plans saved under `~/.claude/plans/` and named in the memory note | [src: memory brew-prod-backend] [src: memory brew-handbook] |

### Rules every session follows

| Rule | Said by | Source |
|---|---|---|
| Every fix works for every brand, card, widget and view; heal saved data; never break the feed | Param, 14 and 23 Oct | [src: memory feed-for-all-brands] [src: brew/CLAUDE.md] |
| Every audit bug is fixed in code with a test or guard and a heal, never a one-off data patch | Param, 24 Oct | [src: memory fix-as-product] |
| After every phase, an exhaustive QV round with fresh reviewers before the next; 3 more full rounds before closing | Param, 25 Oct | [src: memory brew-qv-process] |
| One version, then Redo it; never three options | Param | [src: memory brew-one-version] |
| Deploy to staging after every tested change without asking; still ask before spending money or touching real ads or stores | Param, 12 Oct | [src: memory always-deploy-to-test] |
| No paid generations while only building; ask before a paid probe | Param, 27 Sep | [src: memory no-spend-while-building] |
| Nothing dummy or test reaches production | Param, 25 Oct | [src: memory prod-clean-only] |
| Never disconnect, reconnect or re-select Arata's Meta or Shopify | Param, 22 Oct | [src: memory never-disconnect-arata-meta] |
| Truth first; read code at origin/main; read only in v1 | handbook rules | [src: handbook/AGENTS.md] |

### Sharing one repo

- Several sessions edit `brew/` at the same time. Each stages only its own lines, pushes to origin/main, and deploys from a clean detached worktree of origin/main. [src: memory brew-parallel-sessions-deploy]
- `deploy.sh` refuses a dirty tree and retries a failed suite once, because two suites side by side can trip each other. [src: brew/deploy.sh:7-16]
- Never stash, reset or edit another session's uncommitted work. [src: memory brew-parallel-sessions-deploy]
- Long runs, a production plan for example, work on a branch in their own worktree, such as `brew/.wt-prod`. [src: memory brew-prod-backend]

Full runbook: [Parallel sessions](/engineering/parallel-sessions).

### Keeping what a session learns

- A session writes or updates a memory note when it learns a rule, a lesson or a decision, with the date and why. [src: memory MEMORY.md]
- A Stop hook asks a session that changed brew, brand-directions or memory to run `handbook-update` before it ends. [src: .claude/settings.json] [src: memory brew-handbook]
- Reviews in QV rounds use fresh, independent reviewers, not anchored on the building session's view. [src: memory brew-qv-process]

## Tomorrow

| Item | Version | Tag |
|---|---|---|
| Memory notes, CLAUDE.md, AGENTS.md and skills as the shared context | v1 | Stays |
| The handbook as the planning home; memory notes keep working truth and point here | v1 | Changes |
| Sai and Arvind running their own Claude sessions on the same rules | v1 | New, see Open |
| Old memory notes folded into handbook pages and archived | v2 | Changes |

## How we do it

1. Start: read `MEMORY.md`, then the notes and handbook pages your task touches. For brew, read `brew/CLAUDE.md`, `SCOPE.md` and `DUMMY.md`.
2. Before planning, check the decisions log and the Open part of the pages you touch. Never re-decide a decided thing.
3. For phased work: write the plan, get Param's yes, and run a QV round after each phase.
4. Commit only your lines; push; deploy from a worktree:

```bash
git -C /Users/param/Documents/ChatGPT/brew worktree add --detach "$TMPDIR/brew-deploy" origin/main
```

5. Before finishing: update or add a memory note, then run `handbook-update`.
6. When unsure, ask Param or leave a question with a proposal in the page's Open part. Do not guess.

## Numbers

| Metric | Definition | Where measured |
|---|---|---|
| Sessions that ended without `handbook-update` after a relevant change | Stop hook prompts ignored | Proposed: Stop hook log |
| Deploys that dropped another session's work | Incidents of this kind | [Incidents](/ops-and-infrastructure/incidents), Proposed |

## Open

1. **Do Sai and Arvind run Claude sessions on brew?** No source says. Proposal: yes, each in their own worktree on a branch, merging through Param until they have done one QV round with him.
2. **Which memory notes move into the handbook?** Proposal: rules and runbooks move into handbook pages over the next two weeks; memory notes then keep a one-line pointer.