CLAUDE.md Examples: The Job Contract Pattern for Autonomous Agents

Continue Press · July 2026 · Pillar: agent memory & continuity

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 — the difference between an agent you re-instruct every morning and one that shows up briefed. 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.