Skip to main content

Buyer guide

Claude Code Workflow Playbook

How to brief Claude Code and check its work so a reviewer accepts the change on the first pass, with an annotated CLAUDE.md and a pre-merge checklist.

Reading time
3 min read
Sources
8 cited

The call

Put the acceptance check in the brief, keep CLAUDE.md under 200 lines, approve a plan before any edit, and merge only on the check's output.

The engineer who ran the session reviews the diff as a colleague's pull request and owns every line.

Teams that get Claude Code changes approved on the first review decide what done means before the session starts, and make the agent prove it with a check it can run. Anthropic's own guidance says the same. This playbook covers the task brief and the CLAUDE.md file that set up a session, then the checks to run before merge.

When you need this

  • Engineers accept agent changes that look right and then fail in review or after merge.
  • The same corrections repeat across sessions because nothing records them.
  • Long sessions drift off the task and end in diffs nobody wants to review.

Worked example: how Sanity, Expo and Spotify get a change through review

  1. Expect rework

    Sanity's staff engineer reports that the first attempt at a task is mostly wrong and the third is workable, so he budgets for several passes.

  2. Plan first

    Expo's web team found that plan mode consistently produced better results than going straight to code.

  3. Prove it

    Spotify gives its background agent a verify tool that runs formatters, linters and tests, then summarizes the logs for the agent.

  4. Review in three stages

    At Sanity the agent reviews its own diff first. The engineer then reviews architecture, business logic and integration points, and the team reviews as normal.

The playbook

  1. Before work: write the task brief

    What does done mean, and how will the agent know it got there?

    In practiceGive each brief one change. Name the area in scope, the check the agent must run (a test, build, type check, or screenshot), and what it must not touch. Spotify's background-agent team writes prompts that describe the end state, include a code example, and say when the agent should not act.

  2. Before work: keep CLAUDE.md short and specific

    What does the agent need that it cannot read from the code?

    In practiceWrite down the build and test commands it cannot guess, style rules that differ from defaults, branch and pull request conventions, required environment variables, and known gotchas. Run /init for a starter and check the file into git. Cut any line whose removal would not cause a mistake. Anthropic's cost guidance puts the target under 200 lines. Repositories set up for other agents can use AGENTS.md.

  3. Before work: explore and plan first

    Has the agent read the code and proposed an approach you agree with?

    In practicePlan mode (Shift+Tab, or claude --permission-mode plan) reads files without editing them. Edit or approve the plan before implementation starts.

  4. During work: keep each step reviewable

    Is each change small enough to review in minutes?

    In practicePress Escape as soon as the agent drifts, and use /rewind to restore a checkpoint. After two failed corrections, run /clear and restart with a better brief. Clear the context between unrelated tasks too, because Expo saw output quality fall as context accumulated.

  5. Before merge: verify the result

    What evidence shows the change works?

    In practiceAsk for test output, the command the agent ran and what it returned, or a screenshot. A Stop hook can run the check and block the turn from ending until it passes. For important changes, have a fresh session or a subagent review the diff, because a fresh context is not biased toward code it just wrote.

  6. Before merge: review it like a colleague's pull request

    Who owns this change once it merges?

    In practiceHave the agent review its own diff before you read it. Then check architecture, business logic, and integration points yourself, and send the change through the team's normal review. The engineer who ran the session owns every line.

Verification checklist

  1. Did the agent run the check named in the brief, and is its output in the session?
  2. Does the diff stay inside the area the brief scoped?
  3. Was any test, lint rule, or type check weakened or skipped to make the check pass?
  4. Would this change pass review if a colleague had written it?
  5. Did the session surface anything worth adding to CLAUDE.md or turning into a skill or hook?

Red flags

  • A CLAUDE.md so long that the agent ignores rules in it. Anthropic's guidance is to prune it like code.
  • Accepting "done" without evidence of a check that ran.
  • One session used for several unrelated tasks.
  • Correcting the same mistake again and again in one session when the fix is to clear it and rewrite the brief.

Products in this piece

Sources

Official documentation
5
Public source
3
  1. Claude Code docs: Best practicesOfficial documentationcode.claude.com
  2. Claude Code docs: CLAUDE.md and memoryOfficial documentationcode.claude.com
  3. Claude Code docs: Choose a permission modeOfficial documentationcode.claude.com
  4. Claude Code docs: HooksOfficial documentationcode.claude.com
  5. Claude Code docs: Manage costs effectivelyOfficial documentationcode.claude.com
  6. Spotify Engineering: Context Engineering for Background Coding Agents, Part 2 (Nov 24, 2025)Public sourceengineering.atspotify.com
  7. Expo: What our web team learned using Claude Code for a month (Juwan Wheatley, Feb 6, 2026)Public sourceexpo.dev
  8. Sanity: First attempt will be 95% garbage (Vincent Quigley, Sep 2, 2025)Public sourcesanity.io