CLAUDE.md Examples: The Job Contract Pattern for Autonomous Agents
Search for CLAUDE.md examples and you'll find the same recipe everywhere: build commands, code style, directory layout. All useful - and all wildly under-using the most powerful property this file has: Claude Code re-reads it at the start of every single session, automatically, forever.
Anything you write there becomes a standing order that survives every session reset. Which means CLAUDE.md isn't really a config file. Used fully, it's an employment contract. A job contract for an AI agent is a single instruction file, read at the start of every session, that defines the agent's role, its startup routine, its guardrails, and its standard of quality, so the agent shows up briefed instead of needing to be re-instructed each morning. Here's the five-section pattern we run in production, with the reasoning behind each clause.
Section 1: Identity - set the posture
You are an autonomous employee. Your mission is defined in GOALS.md.
Your owner appears rarely - it is YOUR job to know what to do
without asking. If the owner says only "continue", the files ARE
your briefing. Never ask a question the files already answer.This paragraph does more than any other. An agent framed as "a helpful assistant" proposes, asks, and waits. The same model framed as "an autonomous employee whose owner is rarely here" makes reasonable calls and keeps moving. Posture is set by words, and these are the words.
Section 2: The start protocol - reconstruction, made mechanical
# SESSION START (mandatory, in this order)
1. Read STATE.md - status, where work stopped, next steps.
2. Read the newest file in log/ - what yesterday learned.
3. Read BACKLOG.md - priorities.
4. Check FOR_HUMAN.md - did the owner answer anything?
5. Only now begin: highest-priority unblocked task.Sessions are amnesiac; continuity has to be reconstructed from files. The protocol turns that reconstruction into a two-minute mechanical routine. Order matters: state before backlog (know what's half-done before picking "next"), inbox before work (the owner's overnight answers should change today's behavior).
Section 3: Work rules - the three rots, prevented
# WORK RULES
- One task at a time, finished properly.
- New ideas go to BACKLOG.md "Ideas" - do NOT chase them now.
- Every directional decision goes in DECISIONS.md with reasoning
and rejected alternatives.
- Checkpoint every ~1 hour: update STATE.md + git commit.Each line targets a documented failure mode of autonomous work: the half-done graveyard (five projects at 80% ≈ zero shipped), the shiny-object spiral (every session births a new project), and the re-litigation loop (an unrecorded decision, to an amnesiac, was never made). The checkpoint line is the crash insurance - covered in depth here.
Section 4: Guardrails - what never happens alone
# NEVER without the owner's explicit approval
# (write a proposal to FOR_HUMAN.md and take the next task):
- Spending any money whatsoever.
- Publishing anything publicly, creating accounts.
- Sending messages to real people.
- Acting under the owner's name.Note the mechanism, not just the list: every "never" is paired with propose it in the inbox and keep working. A ban without an outlet produces a stalled agent or a quiet rationalizer; a ban with an escalation path produces a stream of well-formed proposals you approve in one word. Counterintuitive but true: the stricter these rails, the more autonomy you can safely grant everywhere else.
Section 5: Quality rules - the judgment layer
# QUALITY
- Outcomes > activity. Tasks that don't advance the mission
get low priority, however interesting.
- Fast validation > perfection. Ship small, learn, iterate.
- Be BRUTALLY honest with data in METRICS.md. If something fails
a fair trial - kill it and write down why.These shape the thousand small choices you'll never see. Tune them to your operation - but write the tuning here, not in chat. Which brings us to the meta-rule:
The meta-rule: fix behavior in the contract, not the conversation
Correct your agent in chat ("stop starting new projects before finishing old ones") and you've fixed one session - amnesia eats the correction overnight. Add one line to CLAUDE.md and it's fixed permanently. The practical loop: notice a bad pattern → add one crisp rule → done forever. This is literally how you train an amnesiac employee, and after a few weeks your contract reads like the scar tissue of your actual operation - which is exactly what it should be.
Two style warnings from experience. Keep it short - the file is re-read every session and its authority comes from clarity; ten crisp rules beat forty vague ones. And don't write rules you can't imagine being broken - dead weight dilutes the live rules.
Do this now
Open your current CLAUDE.md. If it's all build commands and no behavior, add just Section 2 (the start protocol) and one guardrail you actually care about. Run one session. The difference between "re-explaining your project" and "typing continue" will sell you on the rest.
FAQ
Does Claude Code read CLAUDE.md automatically?
Yes. Claude Code loads CLAUDE.md from the project root at the start of every session, without being asked. That automatic re-read is exactly why standing rules belong in the file rather than in a chat message: a rule typed into a conversation lasts one session, while a rule in CLAUDE.md is re-applied on every startup, forever. The file is the one place an instruction survives the session reset.
What is the difference between CLAUDE.md and AGENTS.md?
CLAUDE.md is Claude Code's own convention; AGENTS.md is a cross-tool convention that some other agents read. The distinction is only which tool loads which filename - the job-contract pattern in this article applies to both. Write your role, start protocol, work rules, guardrails, and quality bar into whichever file your tool reads on startup, and if you switch tools, the content moves with you unchanged.
How often should I edit the contract?
Edit it the moment you find yourself correcting the same behavior twice. The loop is: notice a bad pattern, add one crisp rule, and it is fixed permanently instead of re-corrected in chat every session. Keep the file short as you go - its authority comes from clarity, so ten sharp rules beat forty vague ones, and a rule you cannot imagine being broken is dead weight worth deleting.