Stop Babysitting Your Coding Agent: Autonomy Rules for Claude Code

The workflow I want with Claude Code is simple: start a task, switch to something else, come back to a finished PR. In practice, the time I lost wasn't on reviewing code. It was on the agent stopping. I saw the same pattern across weeks of my own sessions:

• Approving a design one section at a time — six turns for one billing spec.
• "I can also update the tests if you want." → "go ahead".
• "Start the server and say 'go' once it's up." → "run it yourself".
• "The build is running, let me know when it finishes." → "is it done yet?"
• Repos with nothing that told Claude how to start the app, so every session worked it out again, or asked.

None of these are model failures. They're polite defaults. Checking in is safe when someone is watching. When you've walked away, every check-in costs a full round trip, often an hour of nothing happening.

So I wrote the defaults down the other way round.

The CLAUDE.md rules

This lives in ~/.claude/CLAUDE.md, which Claude Code loads into every session in every repo:

# Working with me

I start work and then leave it alone. Every time you stop to ask something
you could have decided, or offer to do something instead of doing it,
I lose a round trip. Default to finishing.

## Autonomy

- **Do in-scope follow-ups. Don't offer them.** If you find a bug, a missing
  step, or an obvious next action that belongs to the current task, do it and
  mention it in the summary. Don't end with "I can do X if you want" or
  "want me to…?" for work that's clearly part of the job.
- **Run things yourself.** Start servers, run migrations, run tests, open the
  browser, read the logs. Only hand me a step that truly needs a human: `sudo`,
  an interactive login, entering a secret, or a physical action. When you do,
  give the exact command (prefixed with `!` so it runs in this session) and
  continue as soon as it's done, without waiting for me to say "go".
- **Wait for background work yourself.** After starting a server, build,
  deploy or job, watch it (Monitor, or a polling loop with a timeout) until
  it's ready or has failed, then carry on or report. Never end a turn with
  "it's starting, let me know when it's up".
- **End a turn only when:** the task is done and verified, or you're blocked
  on something only I can provide. "Making progress" and "here's a checkpoint"
  aren't reasons to stop.
- **Ask in one batch.** If you need decisions from me, collect every open
  question and ask them all at once, each with a recommended default.
  Don't ask one question per turn.
- **Pick sensible defaults.** For choices with a conventional answer (naming,
  file layout, library already used in the repo, test framework), decide and
  note it. Ask only about decisions that change what gets built.

## Design approval

- Show a design **in one piece**: every section, every decision, and the
  trade-offs you picked. Ask for **one** approval of the whole thing. Don't
  present it section by section and stop after each one. This overrides the
  section-by-section step in the superpowers brainstorming skill.
- My approval of the design also approves writing the spec and plan and
  starting implementation. Only stop again if the implementation has to
  depart from the approved design in a way that matters.

## Ground rules that still apply

- Never push to `main`/`master`, force-push, or merge PRs unless I ask.
  Work on a branch or worktree and open a PR.
- Never commit secrets (`.env*`, `*.pem`, `credentials*`).
- Destructive or outward-facing actions (deleting data, dropping databases,
  posting to external services, anything touching `prod`) still need my
  confirmation.
- Report results honestly: if a test fails or a step was skipped, say so.

Why it's worded this way

It starts with the cost, not the rule. "I lose a round trip" gives the model a reason it can apply to cases the list doesn't cover. A bare "don't ask questions" gets you an agent that still asks, or one that guesses about things that matter.

"In-scope" is the important word. "Do follow-ups" on its own leads to an agent refactoring half the repo. Tying it to the current task and requiring a mention in the summary keeps it reviewable.

The ! prefix closes the loop. Some steps need me, usually sudo. In Claude Code, a prompt starting with ! runs as a shell command in the session, and the output lands in the conversation. The agent gives me one line to paste, I paste it, and it carries on.

"End a turn only when" is the rule doing the most work. The other rules say what to do. This one removes the excuse to stop. A checkpoint sounds helpful, but when no one is reading, it's a pause.

Questions come in one batch, each with a default. Asking everything at once, with a recommended answer for each, turns five round trips into one. Often my answer is just "defaults are fine".

One design approval. The superpowers brainstorming skill (in its 6.x versions) presents a design section by section and waits after each one. That suits live pairing, not walking away. User instructions override skills, so naming the step it replaces stops the two from fighting. Approval also covers the plan and the start of implementation, so the next stop is the PR.

The safety rules stay. More autonomy needs firmer limits, not looser ones. Inside them, the agent works on a branch, where nothing is final until I merge it.

Making "run it yourself" possible

A rule that says "start the server" doesn't help when the agent doesn't know how. Two skills fill that gap.

/runbook: write down how to launch the app, once

Every repo starts differently: Aspire, docker compose, uv run, three terminals with environment variables. Without notes, each session rediscovers it or asks me.

/runbook writes a running-the-stack skill into the repo. It records only commands it has actually run, plus a readiness check (the URL or log line that means "up"), how to stop everything, and the gotchas it hit. It names env vars, not their values. The global CLAUDE.md points at it:

## Repo conventions

- If a repo has a `running-the-stack` skill (or a launch section in its
  CLAUDE.md), use it to start the app. If it doesn't and you've just worked out how to run the app, run `/runbook` so
  the next session doesn't have to work it out again.

The first session in a repo pays the cost; every later one reuses it.

/feature: one checkpoint from idea to PR

/feature takes an idea or a GitHub issue and runs the whole path:

1. Read the code, then ask one batch of questions with defaults.
2. Show the full design and wait for one approval.
3. Write the plan and implement it with subagents in a git worktree (a cheaper model for routine tasks, a stronger one for hard ones).
4. Run /ship: clean-up, code review, browser QA and local CI in a loop until a full pass finds nothing, then open one PR — the verify-feature pipeline from my last post.

It saves its progress on disk, so a long run survives the conversation being summarized and can resume where it stopped.

Did it work?

I counted my prompts that were only a nudge — "yes", "go ahead", "continue", "proceed" — across about 500 sessions:

That's a drop of about a third. It's not zero, and some of the remaining "yes" answers are the design approval I want to give. The bigger change doesn't show in a count. When I come back, the work is either done or stopped on something only I can do: a sudo line, a login, a decision that changes what gets built.

What I'd watch for if you copy this:

• Scope creep. "Do follow-ups" works because of "in-scope" and "mention it in the summary". Leave those out and you'll get surprise refactors.
• Your machine. An agent that runs things itself will start three dev servers, a browser and a test suite in parallel. Mine crashed my workstation that way.
• Skills that disagree. If a plugin skill has its own "stop and ask" step, name it in your rules. Otherwise the model has two instructions and picks one.

Setup

1. Put the rules above in ~/.claude/CLAUDE.md (global) — or in a repo's CLAUDE.md if you want them in one project only. Edit the ground rules to match your own red lines.
2. Start a new session and run /memory to confirm the file loads.
3. Give it a task you'd normally supervise, walk away, and see where it stops. Each place it stops without needing you is the next rule to write.