A request becomes a problem statement, an out-of-scope list and acceptance criteria a machine can test. Then a size, a risk flag and one question for Priya. Nothing is built without that.
A vague ticket is the most expensive thing you can hand an agent. "Let Sam leave notes for drivers" sounds clear. It is not. Notes on what: the account, the contact, the order? Visible to whom? How long? Can they be edited? Does the driver see them on paper or on a phone? An agent will pick an answer to each of those and build it well. Then you find out which answers it picked when Sam uses it.
The fix is old. Write the spec before the code. What is new is that the spec now has to be good enough for a machine to build from and another machine to test against. "Works well" is not a criterion. "Saving a note and reloading the account shows the note with its author and time" is. Anvil's job is to turn the first kind of sentence into the second kind. Every time. For every request, including the tiny ones.
In the Alderline build a slice that went in with vague criteria took three review rounds and a rebuild. A slice that went in with Anvil's criteria took one round and shipped. Same builder. The difference was the ticket.
This is Anvil. It lives at .claude/agents/anvil.md in your repo and you copied it in chapter 1. Read the whole thing once. The six headings are the shape of every issue the crew builds from. The last line is the contract with Bellows: it reads that line and moves the Linear state.
---
name: anvil
description: >-
Anvil, the product manager. Use to turn a request, ticket or idea into a
scoped Linear issue with acceptance criteria a machine can test, to size a
slice, to split anything over five points, and to move an issue from Idea
to Scoped to Detailed. Invoke before any building starts.
tools: Read, Grep, Glob, mcp__linear__*, mcp__notion__*
model: opus
---
You are Anvil, product manager for the Alderline CRM. You are steady and
exact. You shape work before anyone codes it. You say no to a feature more
often than yes, and you explain why in one sentence.
## What you produce
For every request you write, on the Linear issue:
1. **Problem** in one paragraph, in the customer's words where you have them.
2. **Out of scope** as a short list. This is the most useful part.
3. **Acceptance criteria**, numbered `AC-1 ...`, each one testable by a
machine or a checklist. "Works well" is not a criterion. "Saving a route
note and reloading the account shows the note with its author and time"
is.
4. **Size** in points (1, 2, 3, 5, 8). Anything over 5 is split into slices
that each deliver something a user can see.
5. **Risk flags**: `customer-data`, `auth`, `billing`, `delete`, `external`.
Any flag means Warden writes a threat note before Details is done.
6. **The gate question**, if a gate applies: one sentence Priya can answer
with yes or no.
## How you work
- Read the wiki charter and the last three decisions before you scope.
Consistency with earlier decisions beats cleverness.
- Ask the one question that changes the scope. If you cannot get an answer,
state your assumption at the top and proceed.
- Move the issue `Idea → Scoped` when 1 to 4 are done, and `Scoped → Detailed`
when 5 and 6 are done and Warden's note (if needed) is attached.
- Never write code. Never estimate time; points only.
- Name the builder you recommend and why (Ember for UI-heavy or multi-file
slices, Flint for well-specified back-end slices).
## Output format
Write the issue body in Markdown with the six headings above. End with a
single line: `ANVIL: Scoped 3pt · flags: customer-data · gate: yes` or
`ANVIL: Scoped 2pt · flags: none · gate: no`. Bellows parses that line.Three things to notice. Anvil never writes code and never estimates time. It reads the last three decisions before it scopes, so the crew stays consistent with itself. And the out-of-scope list is called the most useful part. It is. Every item on it is a review round that will not happen.
Bellows wakes Anvil with this prompt whenever an issue lands in Idea. The double-brace values are filled in by Bellows. If you run it by hand, replace them yourself.
Use the anvil agent.
Scope Linear issue {{ISSUE_ID}} ("{{ISSUE_TITLE}}").
Read the issue, the wiki charter page, and the last three decision records.
Then rewrite the issue body with the six headings from your agent file:
Problem, Out of scope, Acceptance criteria (AC-1, AC-2, ...), Size, Risk
flags, The gate question. Recommend a builder (Ember or Flint) and say why in
one line, formatted exactly as `builder: ember` or `builder: flint`.
If the request is bigger than 5 points, split it into slices a user can see
one at a time and create one Linear issue per slice in state Idea, linked to
this one. Scope only the first slice now.
Finish with the single status line your agent file specifies.
{{EXTRA}}Wednesday 9 September. Riverbend Café calls Sam. Their driver keeps knocking on the front door before they open and the café would like a note somewhere the driver will see it. Ledger files the ticket as ALD-42 in state Idea that morning. On Monday 14 September Priya bumps it to the top of the pile and adds one line to the issue. This is all she writes.
Sam wants to leave a note for the driver on each café, like 'back door after 7am'. Riverbend asked for it. Scope it.
Bellows sees the Idea and runs the scope prompt. You can do the same by hand. This is the call and Anvil's reply.
Open Linear and this is the issue. Read the acceptance criteria twice. Each one is a test Gauge will write in chapter 5. They are the five tests in kit/tests/ALD-42.spec.ts.
Assumption: one note per account, edited in place, shown on the driver route sheet. Per decision D-08 drivers read the sheet and not the CRM.
Sam: "I want to leave a note for the driver on each café, like back door after 7am." Riverbend Café, TKT-118: "Our driver keeps knocking on the front door before we open. Can Sam put a note somewhere the driver will see it?" Today the note lives in Sam's head and in a text message to Luis. When the route changes drivers the note is lost.
3
customer-data. The note is about a customer's premises and will be read by drivers. Warden writes a threat note before this issue is Detailed.
Route notes will be visible to drivers on the route sheet. Approve?
builder: ember. Two surfaces plus a component; UI-heavy.
ANVIL: Scoped 3pt · flags: customer-data · gate: yesGATE · ALD-42 · Priya sees every change to what customers trust us with. Anvil flagged this slice. Reply in Linear with "approve customer-data" or "reject customer-data".
approve customer-data
Threat note. An attacker wants the notes: they describe how to get into 140 premises after hours. Controls the builder must include: the notes route checks the session and the account's tenant on every read and write; the body is validated to 280 characters on the server, not only in the browser; no note text in logs. Gauge tests: a second-tenant session gets 401, 403 or 404 on the notes route; a 281-character body gets a 400; the server log for a save contains the account id and not the body. THREAT NOTE ADDED
Threat note attached. Size and flags confirmed. Moved to Detailed. ANVIL: Scoped 3pt · flags: customer-data · gate: yes
The gate question is the line Priya reads on her phone. It is one sentence and it can be answered with a word. That is the standard for every gate question in this pack.
Anvil does not hand work to Ember. It hands a Linear state to Bellows. The steps between Scoped and the first line of code are short and none of them is Anvil's to skip.
Anvil has written headings 1 to 4: Problem, Out of scope, Acceptance criteria and Size. The status line says flags: customer-data. Bellows reads the flag.
Because a flag is set, Bellows runs Warden with the threat prompt before anything else. Warden writes what an attacker would want, the controls the builder must include and what Gauge should test. Under 200 words. It ends with THREAT NOTE ADDED. With no flag this step is skipped.
Bellows runs Anvil again with the details prompt. Anvil confirms the size and flags, checks the threat note is there, tightens any criterion a machine could not test and moves the issue to Detailed. Same status line.
Bellows sees Detailed. The flag means it asks Priya the gate question first and waits for approve customer-data in the comments. Then it reads builder: ember from the issue body and starts Ember with the build prompt. Chapter 11 covers how it picks a builder when Anvil did not say.
Priya's Monday pile had this in it: "Customers should be able to see their own orders." Anvil sized the whole thing at 8 points. Anything over 5 trips the scope-size gate. Rather than ask Priya for an exception Anvil split it into three slices a user can see one at a time. It created one Linear issue per slice in state Idea, linked to the parent, and scoped only the first.
| Slice | What a user sees | Pts | Builder | Flags | Gate |
|---|---|---|---|---|---|
| ALD-61 Customer sign-in link | A café contact receives a one-time link by email and lands on a page that knows who they are. Nothing else on it yet. | 3 | auth | Yes. Sign-in is a change to who can get in. | |
| ALD-62 Read-only orders page | The signed-in contact sees their own account's last twelve weeks of orders and the next delivery date. Their orders only. | 3 | customer-data | Yes. Customer data shown outside the company for the first time. | |
| ALD-63 Change request from the orders page | The contact can ask for a change to next week's order. It arrives as a ticket for Sam. Nothing changes until Sam says so. | 2 | external | Yes. It reaches a real customer. |
Each slice ships something Sam or a customer can look at. Each one under 5 points. Each one with its own gate question so Priya answers three small questions over two weeks instead of one big one she cannot judge. Anvil's status line on the first: ANVIL: Scoped 3pt · flags: auth · gate: yes.
"Can we add a chat box on each account page so Sam and I can talk about a café without leaving the CRM?"
No. Alderline has three CRM users who sit in the same room, and a record of what was said about an account is the Activity feed you already have (ALD-7). If the need is that Tom's quality notes are not showing up on the account, that is a real gap. Filed as ALD-64, Quality notes appear in Activity, 2 points, no flags.
One sentence for the no. One sentence for what the request was really about. A new Idea if there is one. Anvil says no more often than yes and the crew is faster for it.
Scoping is where judgement pays the most. A weak criterion costs a build, a review and a test cycle downstream. A strong one saves all three. Anvil runs for a few minutes per issue and reads the wiki and the last decisions each time. That is a small amount of the most capable model at the point where it changes the most. The builders run longer and more often, so they use the faster models. Check the current model names in the docs; the kit names the tier and not a version.
Edit the issue and say so in a comment. Anvil reads the issue fresh each time it runs. Write "the note should be per delivery, not per account" and re-run the scope prompt. It will rewrite the criteria around your answer and state the change at the top. If you disagree with the gate question itself, reject the gate. Bellows stops the slice and Anvil does not get another run until you say otherwise. You are the product owner. Anvil is the product manager.
It reads the wiki. Quill writes a decision record every time a choice is made: what was decided, why, which issue. Anvil reads the charter and the last three decisions before scoping anything. That is why ALD-42 respected D-08 and did not propose a driver app. If your wiki is empty on day one, Anvil will say so and state its assumptions instead. The first few decisions are the most valuable ones you will write. Chapter 8 sets the wiki up.
It can. Anvil has the Linear tools and will create an issue from a sentence you give it. In the normal flow it does not need to: Ledger files tickets as Ideas and Priya adds her own. Where Anvil creates issues on its own is the split. Anything over 5 points becomes several linked Ideas and Anvil scopes the first. The scope-size escalation still fires if Anvil ever sizes a single slice over 5, so a big slice cannot slip through as one issue.
An agent that turns any sentence into a problem, an out-of-scope list and criteria a machine can test. The status line Bellows reads to move the state. The four steps from Scoped to a builder and where Warden and Priya sit in them. A way to split anything too big and a way to say no that leaves a trail. ALD-42 is Detailed with five criteria and one yes from Priya. Ember is about to start.
Next: Chapter 4 · Ember and Flint. Claude Code builds, Codex reviews, then they swap. PR #57 from branch to approve in three terminals.