Sonith ManakkatThis is Part B of the playbook. Part A covers the board and the plan; this part covers the people and the safety: roles, meetings, ready and done, quality gates, release and rollback, and sharing context. It is written for a solo developer or a team of two to five.
Roles: who briefs, builds, verifies and ships
Humans own
- What to build, and what is out of scope
- Verifying correctness, safety and privacy
- Deciding to ship, and to roll back
The AI does
- Drafting code and tests from the brief
- Searching, explaining, and proposing alternatives
- Repetitive edits across many files
The hat checklist (for a solo developer)
- Briefer hatWrite the outcome, checks and limits. Do not code yet
- Builder hatLet the AI build one slice. Do not review while it builds
- Verifier hatSwitch roles: read the diff as if a stranger wrote it
- Shipper hatRelease to the small group, watch, and decide: keep or roll back
- Briefer to Builder (AI) Outcome, checks, out of scope and limits.
- Builder (AI) (to itself) The AI builds one small slice.
- Builder (AI) to Verifier The change goes to a person, who reads the diff and runs the checks.
- Verifier to Builder (AI) (reply) If a check fails, the slice goes back. Only a pass moves on.
- Verifier to Shipper All Done items are true, so the change may go out.
- Shipper to Briefer The Shipper releases to the small group, watches, and the result becomes the next brief and an instruction-file line.
Takeaway. The AI builds, but a person briefs, verifies and ships.
Expert viewWhy one hat at a time
People find their own mistakes badly, and judging a change straight after prompting for it invites accepting it. Changing hat (even taking a short break, or reviewing the next morning) is a cheap way to simulate a second pair of eyes. In a team, rotate the verifier role so the same person is not always the bottleneck, and avoid verifying your own large changes.
Meetings: three short ones
- Daily check (10 minutes)
What is in Verify? What is blocked? Is the cycle goal still realistic?
- Demo (end of cycle, 15 minutes)
Show what actually works to the person it is for, or a test user
- Retro (15 minutes)
One thing to keep, one to change, and one line written into the instruction file
Ready and done
Ready (a card may enter Briefed)
- A one-sentence outcome
- Three to five acceptance checks
- An out-of-scope line
- A risk level, and a verify plan
Done (a card may leave Verify)
- Tests pass, old and new
- A human read the diff
- Tried on a real device or environment
- Notes and instruction files updated
Backlog refinement: writing AI-ready briefs
Refinement is where the backlog becomes ready to build. In the Scrum Guide it is an ongoing activity that adds detail, order and size to items, not one of the five events.
- OutcomeWhat a user can do afterwards
- Acceptance checksTestable, specific
- Out of scopeWhat not to touch
- ExamplesOne normal case, one awkward case
- ContextLinks to the files, screens or decisions involved
- An instruction fileThe standing rules every session reads; see [CLAUDE.md and memory](/articles/claude-ai-claude-md-memory/)
- A skills libraryReusable playbooks loaded when needed; see [Skills explained](/articles/claude-ai-skills-explained/)
- Brief templatesSaved formats so each brief starts well
- A decisions logWhy choices were made, so the AI and people do not reopen them
BRIEF TEMPLATE
Outcome:
Acceptance checks (3 to 5):
Out of scope:
Constraints (privacy, data format, style):
Examples (one normal, one awkward):
Context links:
Risk: low / medium / high Expected review size: small / medium / large
First: read the relevant files, give me your plan and questions, and wait for my OK.Estimating
Keep it rough. Size slices by verification effort and risk (Part A), use a simple scale such as small, medium and large, and treat anything large or high risk as a signal to split. The Scrum Guide says the Developers who will do the work are responsible for the sizing and does not mandate a scale. Do not turn sizes into promised dates.
Quality gates
- 1Slice builtOne small slice, ready to check
- 2TestsFail: back to the builder. Read the tests, not only the result
- 3Human reviewFail: split or fix. Large diffs are split first
- 4Safety checkFail: stop. Secrets or data leaks are never shipped
- 5Staged releaseA small group first. The rollback rule applies
Takeaway. If a gate fails twice for the same reason, add a line to the instruction file.
- TestsNew behaviour has tests; old tests still pass; tests actually test behaviour
- ReviewA person reads the whole diff; large diffs are split first
- SafetyNo secrets, no surprising network calls, data handled as intended, dependencies sensible
- Staged releaseA small group first, then widen
Expert viewMaking the gates real
Write the gates into the Definition of Done so that skipping one is a visible decision. For safety checks, keep a short list tuned to your product (for example: no secrets in the code, no new data leaving the device, input validation on new fields). Be wary of an AI that makes failing tests pass by weakening them, and read the tests as well as the green result. When a gate fails twice for the same reason, add a line to the instruction file so it fails earlier next time.
Release and rollback
- Pick a small groupA few people who will tell you what they see
- Release to themNot to everyone
- WatchCrashes, complaints, odd behaviour
- Widen, or roll backDecide by the condition you wrote down beforehand
Feature switch
- Turn the new behaviour off without a new release
- Fast, when you planned for it
Roll back the version
- Go back to the previous version
- Slower, and users must update
- Ready to Small group The change goes to a few people who will say what they see.
- Small group to Watching Watch crashes, complaints and odd behaviour.
- Watching to Wider group The rollback signal you wrote down has not fired, so widen.
- Wider group to Everyone Release to everyone.
- Watching to Rolled back Switch the feature off or go back to the previous version.
- Rolled back to Ready Write down what happened and add the check that would have caught it to the Done list.
Takeaway. Decide the rollback signal before you ship, and the decision is easy.
Expert viewChoosing the rollback signal
Decide in advance what you will watch and what counts as bad. Typical signals for a small app are crashes or errors reported by the test group, a key action that stops working (for example saving a record), or reports of data looking wrong. Write the rule as a sentence ("if two testers report lost data, switch the feature off") so that the decision is not made under pressure. After any rollback, write down what happened and what check would have caught it, and add that check to the Done list.
Sharing context in a team
Commit the instruction file, the skills folder and the brief templates, review changes to them like code, and keep secrets out. The team-sharing article covers where each file lives and how to share them.
Small cycles are safe only when someone checks, someone can undo, and everyone learns.
Start this week
- Name the four hatsOn a team, assign them; solo, list them
- Write a Done listFive lines, kept visible
- Write one briefUsing the template above
- Add one safety checkPick the most important one for your product
- End the week with a retroAdd one line to the instruction file
Frequently asked questions
Do we need all four roles on a small team?
You need all four jobs done. People can combine them, as long as large changes are verified by someone other than the author when possible.
Why not let the AI review its own work?
It can help find problems, but the responsibility to decide that something is correct and safe stays with a person.
How often should we release?
As often as you can verify safely. Small and frequent usually beats large and rare.
Is this an official method?
No. It builds on official guides and labels my own adaptations clearly.