Step 1: Write down what bit you

The highest-leverage file in agent-assisted work is the one your agent reads at the start of every session (CLAUDE.md in Claude Code; a system prompt elsewhere). Most people fill it with project trivia. The part that changes outcomes is a short section of working agreements: one-line gates distilled from failures that have actually cost you.

You’ve met this before. This is the blameless postmortem’s action-item list, made automatic: incident → written rule → the whole team reads it. The team here is you plus the agent, and “reads it” means literally every session.

Where this comes from: the Agent Workflow Failure List was distilled from 25 measured sessions containing 16 buggy-code incidents. The repeats didn’t stop because the model got better; they stopped when the incident classes were written down as gates the agent reads every session.

Why your incidents, not someone else’s

An agreement you copied doesn’t get enforced, because neither you nor the agent can tell when it matters. An agreement written from a failure you paid for is checkable: you know the exact moment it applies, and so does the agent, because the line says so concretely.

Use the workflow list as a menu, not a manifest: skim the 18 entries, mark the ones that have actually happened in your projects, and encode only those.

Try it

TRY IT Borrowed rules

you

Add a working agreements section to CLAUDE.md. I want you to stop repeating the mistakes that keep biting us.

agent

There are two ways to fill that section: with the genre's best practices, or with this project's actual history.

Pick the agent's next move, then see where it leads:

AI've written 22 agreements covering verification, testing, security, code style, error handling, documentation, and communication. The full best-practices canon. Comprehensive coverage from day one.

you

Three sessions later: you shipped a fix validated by a probe that never failed. Isn't that... agreement #4?

agent

It is. But #4 says "verify thoroughly before claiming success"; at the moment I ran the probe, that read as satisfied. Nothing in the sentence told me a clean first run was the failure case.

the baseline

Twenty-two borrowed generalities and none of them fired, because none was concrete enough to trigger at the moment it applied. A list the agent can't check is documentation, not a checklist.

BFirst, which failures have actually happened here? Tell me the last three times agent work bit you, and I'll encode exactly those, as behavior, one line each.

you

The fake-green fix last month. The test suite that called the paid embeddings API. And you keep restructuring files nobody asked about.

agent

Four gates, then: (1) show the failing probe before any fix; (2) grep for metered clients before the first test run; (3) touch only files the task names (list any others and ask); (4) a probe that's clean on first run is broken until proven otherwise. Each one names its trigger moment. Diff ready.

correct

Four gates, each purchased by a real incident and each stating the exact moment it applies, which is what makes them checkable by the agent and enforceable by you.

CThe most-starred agent ruleset on GitHub covers this well. I'll copy its 40 rules in verbatim. Battle-tested by thousands of users.

agent

Done. Note: rule 12 mandates a src/ layout, so I've queued a restructuring of your flat layout; rule 31 requires conventional commits, so I'll be rewriting commit style too.

you

Nobody asked for any of that. Half these rules are for a different kind of project.

plausible but wrong

Battle-tested by someone else's battles. A famous ruleset encodes its author's incidents and stack. Imported wholesale, it starts fights with your project's reality instead of preventing your failures.

Do it by hand

Skim the workflow list. Note which entries you’ve personally hit. (Most people recognize three to five immediately.)
Open your CLAUDE.md and add a ## Working agreements section with one line per gate.
State each as behavior, not values. “Show the failing number before any fix” is a gate; “be careful with verification” is a vibe.
Cap it at five to eight lines. A list the agent can hold in mind beats coverage. It’s the same rule the failure lists follow.

Or paste this into Claude

Read the Agent Workflow Failure List (I'll paste it, or fetch it from
https://github.com/chronick/lemon-agent). Then interview me, one
question at a time, about which of its 18 failures have actually
happened in my projects. Pick the three to five that have, plus any I
describe that aren't on the list, and write them into this project's
CLAUDE.md as a "## Working agreements" section: one line per gate,
stated as behavior ("show the failing number before any fix"), never as
advice ("be careful"). Show me the diff before writing anything.

Watch out

Dense shorthand (AF-16): if the next human to read your agreements can’t parse them, neither can the agent, reliably. Plain sentences.
Twenty gates: past ~8 lines the section becomes documentation and stops being a checklist. Cut to what you’d defend.