Your Claude Code rollout workbook.

A short working session for you and your team, about 30 minutes. Don't just read it, fill it in. By the end you'll have your first tasks scoped, the permissions and guardrails agreed, and a review and secrets policy written down. Type straight into the boxes and save as a PDF, or print it and write on it.

The loop, in brief. Claude Code is a coding agent: you brief it in plain language in your terminal, and it reads your repo, edits across files, runs commands and tests, and works step by step, asking your approval as your permission settings dictate. It multiplies your team on well-defined work; the judgement stays with you. Hand it bounded, checkable jobs, start small in a branch or sandbox with least-privilege access, and read every diff like a contributor's. The loop is scope, run, review, merge. Tighten the brief or the project instructions when something comes back off, and keep a human on every change.

1Where could a coding agent help?

Brain-dump the bounded, checkable work your team would happily hand off: small features inside a settled design, test gaps, tidy refactors, bugs with clear repro, codebase questions, glue code, small internal tools. Don't filter yet. Quantity first.

The task or job	Who owns it	Blast radius

2Your first two or three well-scoped tasks to trial

Pick the ones from above with a clear definition of done, low blast radius, and no production secrets in sight. A few real tasks beats a vague plan to "try the agent".

Task 1: Task 2: Task 3 (optional):

3A task scoping template

Write the brief for your first task here, then reuse the shape for the rest. If you can't scope it cleanly, break it down or keep it yourself. A CLAUDE.md in the repo, with how to build, test and lint, saves you repeating the context every time.

Goal (one clear outcome, like a ticket for a capable junior): Context and files (the area to work in, plus how to build, test and lint): Acceptance criteria (the test that passes, the behaviour you expect): Out of scope (what to leave alone):

4Permissions and guardrails checklist

Agree this before you set anything loose. Permissions are your dial: grant the least a task needs, no more, and keep a yes in front of the risky actions. Tick what's true, and write the specifics where it asks.

It starts small in a branch or sandbox, off our environment where we can. Permissions are set so it asks before risky reads, runs and edits, not auto-approved on day one. Main is protected: required status checks and a required human review before merge. Every change lands on a branch and in a reviewed PR, so it stays auditable. A CLAUDE.md instructions file is in the repo (build, test, lint, conventions, gotchas). What it may read, run and edit (repos, areas, commands, MCP servers): What it may not touch (production, infra, anything off-limits):

5Review and secrets policy

A little governance lets the team delegate with confidence instead of guessing. Green tests are a start, not a sign-off. Keep it to these lines.

Who reviews the diff or PR before merge: Secrets handling (where they live, the scoped tokens we use, what the agent never sees): CI gates that must pass before merge:

Your Claude Code rollout workbook.

Sent, thanks.