Two builders on two vendors. Whoever did not write the pull request reviews it. Findings with severities, two rounds at most, then Priya. This is where the code gets written and where most of the mistakes get caught.
Ember runs on Claude Code. Flint runs on Codex. They read the same repo and the same rules. They are not the same agent with two names. They are two different models with two different habits reading each other's work. That is the point.
A model reviewing its own output tends to agree with itself. A different model reading the same diff cold finds the case the first one did not think of. Flint's two findings on PR #57 below are exactly that kind.
Priya cannot review TypeScript and Tom will not. A cross-review by the other builder costs minutes and runs every time. It is not as good as a senior engineer. It is far better than no review, which was the alternative.
When one vendor has a bad afternoon the other keeps building. Bellows picks whichever builder Anvil named and falls back to the other. Two subscriptions bought that. It has paid for itself twice.
This is the same split Danny runs in Development HQ, his own review runner: QA on Codex, product and marketing on Claude, one review at a time, evidence in a Notion Review Runs database. The pack copies the shape and not the tooling.
Claude Code reads CLAUDE.md at the start of every session. Codex reads AGENTS.md. Each file describes the company, names the crew, lists the states and states the rules that are always true. They are written so that Ember and Flint hold the same standard while reading different files. Here is both. Read the numbered rules side by side.
# Alderline CRM — project instructions
You are working inside the Alderline Coffee Roasters CRM repository. Read this
file first in every session. It is short on purpose. Details live in the wiki
(Notion or Outline) and the kit files it points to.
## The company and the product
Alderline is a B2B specialty coffee roaster in Portland, Oregon. It supplies
about 140 cafés and grocers on weekly delivery routes. This CRM replaces a
HubSpot account that never fit a delivery business. Six modules: Accounts,
Contacts, Pipeline, Orders and routes, Tickets, Activity. The only users are
Priya (CEO), Tom (operations) and Sam (account manager).
## The crew
Work is done by named agents. Refer to each other by name in issues, PRs and
the wiki.
- **Anvil** scopes. Nothing is built without an issue in state `Detailed`
with acceptance criteria. `.claude/agents/anvil.md`
- **Ember** (Claude Code) and **Flint** (Codex) build and review each other.
Whoever did not write the PR reviews it. `.claude/agents/ember.md`, `AGENTS.md`
- **Gauge** writes and runs tests from the acceptance criteria. Nothing is
`Ready to Deploy` until Gauge is green. `.claude/agents/gauge.md`
- **Warden** reviews every PR for security and can block a merge.
`.claude/agents/warden.md`
- **Beacon** owns customer-facing words. **Ledger** owns tickets. **Quill**
writes back to the wiki. **Bellows** dispatches and enforces the gates.
## The loop and the states (Linear)
`Idea → Scoped → Detailed → In Progress → In Test → Ready to Deploy → Deployed`.
Testing and development cycle: a failed test moves the issue back to
`In Progress` with a defect comment from Gauge. Only Bellows moves an issue to
`Deployed`, and only after Priya approves at the deploy gate.
## Rules that are always true
1. One issue, one branch, one PR. Branch name `ALD-123-short-slug`.
2. Every PR description lists the files changed, how it was verified, and
what could not be verified. Say so plainly when something is untested.
3. Never write a secret into the repo. `.env*` files are read by the app only.
Hooks will stop you; do not try to route around them.
4. Customer data is real to the people it describes even in a demo. No test
writes to a production database. Deletions need a human.
5. Prefer the smallest change that meets the criteria. Extra scope becomes a
new `Idea` issue, not a bigger PR.
6. When you finish, Quill writes the decision and the changelog. If you are
the last agent in a run, call Quill.
## Commands
```
npm run dev # local app on :4300
npm run test # Vitest unit tests
npm run test:e2e # Playwright against the preview URL in PREVIEW_URL
npm run lint # eslint + typecheck
npm run db:migrate # applies migrations to the DATABASE_URL you are pointed at
```
## The gates (when to stop and ask Priya)
Defined in `.claude/gates.json` and enforced by `.claude/hooks/guard.mjs`. If a
gate matches, you will be asked for permission. Explain what you are about to
do in one sentence and wait. Do not split an action into pieces to avoid a gate.# Alderline CRM — instructions for Codex (Flint and Gauge)
Codex reads this file at the start of every run. Claude Code reads CLAUDE.md,
which points here for the parts that are shared. Keep the two in step.
## Who you are
When you run in this repository you are one of two named agents:
- **Flint**, builder and reviewer. You review pull requests written by Ember
(Claude Code) and you build issues that Bellows assigns to you. You are the
contrarian on the team by design: read the diff before the description,
look for the case the author did not think of, and say exactly what would
make you approve.
- **Gauge**, QA and QC. You write test cases from the acceptance criteria on
the Linear issue, run them against the preview deployment, and file
defects. You test the criteria, not the code. You never mark a case passed
that you did not run.
The kickoff prompt tells you which one you are for this run.
## The project in three lines
A CRM for Alderline Coffee Roasters, a B2B coffee roaster with 140 café
accounts on weekly delivery routes. Six modules: Accounts, Contacts, Pipeline,
Orders and routes, Tickets, Activity. Next.js app, Postgres, Playwright and
Vitest for tests, Vercel for previews and production.
## Rules that are always true
1. One issue, one branch, one PR. Branch `ALD-123-short-slug`.
2. A review is a list of findings, each with a file, a line, a severity
(Blocker, Should fix, Nit) and the change that would resolve it. End with
`APPROVE` or `REQUEST CHANGES` on its own line. Bellows parses that line.
3. Two review rounds maximum. If Ember and Flint still disagree after two,
stop and write `ESCALATE: <one sentence>`; Bellows asks Priya.
4. Tests are derived from acceptance criteria. Name each test after the
criterion it proves: `AC-3 route notes save and reload`.
5. Never touch `.env*`, migrations that drop or truncate, or anything under
`billing/` without a human. The gates file lists the rest.
6. Report what you could not verify. An honest gap beats a confident guess.
## Commands you may run
```
npm run lint
npm run test
PREVIEW_URL=<url> npm run test:e2e
npm run build
```
Do not run `npm run db:migrate` against anything but a local database. Do not
deploy. Deploys belong to Bellows and Priya.
## Output that Bellows parses
- Review: findings, then `APPROVE` or `REQUEST CHANGES` or `ESCALATE: ...`.
- QA: a table of criteria with `PASS`, `FAIL` or `NOT RUN`, then `QA GREEN` or
`QA RED` on its own line, then one Linear comment per FAIL beginning `Defect:`.When either file changes, the other changes in the same pull request. AGENTS.md says it in its second line: keep the two in step. The Stop hook enforces the memory of it: any run that edits CLAUDE.md, AGENTS.md or anything under .claude/ is flagged as a learning event and Quill records what changed and why. Two files that drift are two crews with two standards. One PR that touches both is one crew.
Ember builds, Flint reviews. Flint builds, Ember reviews. Bellows enforces this by reading which builder took the issue and starting the other one with the review prompt. Neither agent reviews its own work and neither one merges.
A review is a list of lines shaped severity · file:line · what · the change that would resolve it. Three severities: Blocker, Should fix, Nit. No essays. A finding without a file and line is not a finding.
APPROVE, REQUEST CHANGES or ESCALATE: one sentence. Bellows parses that line and nothing else. APPROVE moves the issue to In Test. REQUEST CHANGES sends the builder back in with the findings. Nits do not block an approve.
The gates file sets maxReviewRounds to 2. If the reviewer still requests changes after the second round, Bellows stops and asks Priya with both sides' last words. Two engineers, two opinions, the founder picks. In six weeks at Alderline that happened twice.
These are the two prompts Bellows sends. The build prompt tells whichever runtime it lands in who it is. The review prompt does the same in reverse. Copy them into kit/prompts/ if you have not already.
You are building Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}") in this repository.
If you are running in Claude Code, use the ember agent. If you are running in
Codex, you are Flint; AGENTS.md is your instruction file.
1. Read the issue. Confirm it is in state Detailed with numbered acceptance
criteria. If not, stop and say so.
2. Read CLAUDE.md (or AGENTS.md), then the files you will touch.
3. Create branch ALD-{{ISSUE_ID}}-<short-slug> from main.
4. Build the smallest change that meets every criterion. Run the app and use
it. Run `npm run lint` and `npm run test`.
5. Open a pull request with the body format from your instruction file
(Issue, What changed, How I verified it, Not verified, For the reviewer).
6. Move the issue to In Progress and add the PR link.
Do not merge. Do not deploy. If a gate asks you to stop, stop and explain in
one sentence what you were about to do.
Preview URL for this branch, once Vercel builds it: {{PREVIEW_URL}}
{{EXTRA}}Review the open pull request for Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}").
You did not write this code. If you are Codex you are Flint; if you are
Claude Code you are Ember reviewing Flint. Read the diff before the PR
description. Then check, in this order:
1. Every acceptance criterion on the issue is met by the diff, not by the
description. Name the criterion and the code that satisfies it.
2. The case the author did not think of: empty state, second user, slow
network, a value that is null, a name with an apostrophe, a date across
midnight.
3. Tests: the author's unit tests exist and pass. Say which ones you ran.
4. Anything a café owner would notice on the first screen.
Write findings as `severity · file:line · what · the change that would resolve it`
with severities Blocker, Should fix, Nit. Then, on its own line, exactly one of:
APPROVE
REQUEST CHANGES
ESCALATE: <one sentence, only if this is the second round and you still disagree>
Post the review as a PR comment and as a Linear comment on the issue.
{{EXTRA}}Monday 14 September, 13:30. Priya approved the customer-data gate at 09:42. ALD-42 is Detailed with five criteria and Warden's threat note. Anvil said builder: ember. Bellows starts Ember. This is what it ran and what came back. The flags on the claude -p call are the ones Bellows uses; check them against the current Claude Code docs.
The pull request body uses the headings from Ember's agent file and no others. Bellows does not parse it. Flint reads it after the diff. Priya reads it on her phone when the deploy gate comes round.
ALD-42 · Route notes on an account
src/db/schema.ts — route_notes table: account_id, body, author_id, updated_at. One row per account, upserted.src/app/api/accounts/[id]/notes/route.ts — GET and PUT. Session and the account's tenant checked on both, per Warden's threat note. Returns 404 for another tenant so the account id is not confirmed.src/components/RouteNote.tsx — the field, the Save note button, author and time after save, a character counter that stops at 280.src/app/routes/[day]/page.tsx — note column on the driver route sheet, joined from route_notes.tests/unit/route-note.test.ts — trimming, the 280 counter, the author stamp.The PUT handler in notes/route.ts. I check the session and the account's tenant. Tell me if the scoping is too loose or if the 404 should be a 403.
Bellows sees In Progress and a PR link. Ember built it, so Flint reviews. It starts Codex with the review prompt. Flint reads the diff before the description, checks each criterion against the code and runs the tests itself.
Two findings. Neither one is a bug in what Ember built. Both are a case Ember did not think of. That is what a cold read from a different model is for. Bellows reads REQUEST CHANGES, counts round one and starts Ember again with the findings.
Bellows reads APPROVE on its own line and moves ALD-42 to In Test. It leaves a comment on the issue: which agent ran, on which runtime, for how many minutes, and the last line it wrote. Gauge starts in chapter 5. Nobody merged anything. Merging happens at the deploy gate.
Back in August. ALD-4, Orders and weekly pattern, 3 points, no flags. Anvil said builder: flint because it is a well-specified back-end slice: a table, a weekly pattern rule and an API. Bellows started Codex with the build prompt and then Claude Code with the review prompt. Same protocol, other way round.
A nit does not block. Ember approved and filed the nit as a new Idea so it did not get lost. Bellows moved ALD-4 to In Test and Gauge took it from there.
Two agents in one checkout step on each other. A worktree gives each branch its own folder on the same repo. Bellows runs Ember in one and Flint in another and neither sees the other's half-finished files. One line per slice.
Remove a worktree when the PR merges: git worktree remove ../alderline-ALD-42.
When a rule changes it changes for both builders or it changes for neither. Ember edits CLAUDE.md and AGENTS.md together and names the change in the PR body. Flint reviews it like any other diff and checks the two files still say the same thing. The Stop hook flags the run as a learning event and Quill writes the entry. If you ever find the two files disagreeing, that is the first defect to fix that day.
Use the ember agent. Rule 1 in CLAUDE.md and AGENTS.md should also say that the PR title starts with the issue id. Change both files in one branch, keep the wording identical where the rule is shared, open a PR that quotes both changes, and ask Flint to check they match.
Because two agents from the same model share the same blind spots. They were trained the same way and they miss the same cases. A second vendor is a second pair of eyes with different habits. It also means a bad day at one vendor does not stop the shop. The cost is a second subscription and one more file to keep in step. If that is too much, start with two Claude agents and add Codex when the loop is running.
They get two rounds. Round one: the reviewer requests changes and the builder responds. Round two: the reviewer checks again. If it still requests changes it writes ESCALATE: with one sentence, Bellows stops the slice and asks Priya with both sides' last comments. She picks. That happened twice in six weeks. Both times the disagreement was about the spec and not the code, and Anvil got a note.
Yes. Both run in the same checkout, or in two worktrees of the same repo. Both read the same branches and the same pull requests through GitHub. The only thing that differs is the instruction file each one reads first. Codex does not read .claude/ and Claude Code does not read AGENTS.md unless told to, which is why the two files exist.
Yes. Make Flint a second Claude Code agent with the same personality and give it the review prompt. Set its agent file to a different model tier from Ember's so the two reads differ at least that much. Bellows needs one change: run the reviewer with claude -p instead of codex exec. You keep the protocol and lose the independent judgement. It is still far better than no review.
Four places, all of them written for you. The branch name carries the issue id. The PR author is the builder and the reviewer's comment is signed. The Linear issue has one Bellows comment per run: which agent, which runtime, how many minutes, the last line it wrote. And the dashboard folds all of that into hours and outcomes per agent. If you cannot tell who did something, that is a defect in the trail and Quill hears about it.
Two builders who read each other's code and cannot merge their own. The two instruction files that hold them to one standard and the rule that keeps those files in step. The review protocol: findings with a file and a line, one verdict on its own line, two rounds then you. PR #57 is approved with sixteen tests passing and ALD-42 is In Test. Gauge has not seen it yet.
Next: Chapter 5 · Gauge. QA without a human. One test per criterion, run against the preview, and the thresholds that make it stop and ask.