Home/Claude Code/Briefing Guide
A working method

How to brief Claude Code
like an engineer.

Most disappointing Claude Code output traces back to a thin brief and a rubber-stamped diff, not a weak model. Here's the structure that gets you a scoped, reviewable change instead of a confident guess.

Briefing Claude Code well is the same discipline as briefing a contractor or a new teammate, just written down instead of assumed. Five things separate a brief that produces a mergeable diff from one that produces a plausible-looking guess.

01

State the outcome, not the implementation

Not "refactor this function" but "this endpoint needs to handle 10x current load without changing the public API". Claude Code works towards an outcome far better than it works towards a vague instruction; the implementation follows once the goal is clear.

02

Give it the constraints a teammate would need

Coding standards, the test command, what's off-limits (a shared library, a migration already in flight), and any performance or security constraints. Every constraint you leave out becomes a guess Claude has to make on your behalf, and guesses are where regressions come from.

03

Point it at the actual code, not a description of it

Claude Code works from the real repo, the real error message, the real stack trace, not your summary of what's wrong. A pasted description loses the details that matter; access to the actual files doesn't.

04

Ask for a plan before you ask for a diff

For anything non-trivial, have it lay out the approach first: which files change, what the risk is, whether tests need updating. Reviewing a plan is far cheaper than reviewing, and possibly reverting, a large diff that took the wrong approach.

05

Review it like a junior engineer's PR, not a rubber stamp

Claude Code can produce a confident, wrong diff as easily as a correct one. Read the diff, run the tests, and ask "what would break this" before merging — that habit is the difference between shipping fast and shipping fast, then spending a day debugging.

Want to see this method run against a real bug, start to finish? Read a full session walkthrough, or if you don't code day-to-day, see what a non-developer can produce with it.

See Claude Code coaching →
The Boffin Guarantee

Coaching designed
to end.

Reading the method is one thing; having someone check your first diffs against your actual repo is another. Three promises, in writing, if you bring it to a session:

01

First Session Promise

Leave your first session with a live workflow already running in Claude, or the session is free.

02

Independence Guarantee

You'll be working independently inside six sessions, or we'll keep going: up to two further sessions free.

03

24-Hour Match

Tell us what you do; we'll match you with the right specialist within 24 hours. Guaranteed.

Training a whole team? See Claude training for teams.
Questions

Things people
usually ask.

Get started

Bring your repo.
We'll bring the specialist.

Bring a real ticket to your first session and a specialist will run this method against it live. We'll match you within 24 hours, guaranteed.

Get matched free →
Free · 5 minutes · no card · matched within 24 hours