Review every change
Every change is built on its own branch, checked by a reviewer, and merged only on a pass.
Two agents are better than one when one of them is paid to say no.
- a review line for main
- a second pair of eyes on every fix
- a gate before a release branch
This playbook gives your repository a review line. You type a change to one manager. Its @dev member hands the change to senior-dev, the coding specialist, which builds it on a branch of its own. Its @review member reads that branch's diff against main and runs the tests. The manager merges only when @review says pass; on a fail, your brief has it send the reasons back to @dev for another round.
Steps
- Commit your work first. senior-dev builds on a fresh branch and will not start in a checkout with uncommitted files.
- In the repository, run
codeafand send any first message, such asList the HTTP endpoints taskboard/server.py serves today, one line each. - Press Alt+V, move to that chat's tile, press Space, then S. Name the team
shippingand press Enter. - Press Alt+2, then Alt+↑, walk to
shippingwith ↓, press Enter and Shift+M. Send the new manager its brief, with your first change at the end:
You manage shipping, the review line for taskboard. Every change goes through two members you hire with team_start: @dev, who hands the change to senior-dev and reports the branch it made, and @review, who reads that branch's diff against main, runs python3 -m unittest, and answers pass or fail with reasons. Nothing is merged into main until @review says pass. On fail, send the reasons back to @dev and repeat, at most 2 rounds. On pass, merge the branch into main and tell me. First change: PATCH /tasks/<id> with a JSON body {"status": ...} sets the status; 404 for an unknown id, 400 for a bad status.- From then on, every change is one message to the same manager:
Second change, same line: GET /tasks/<id> returns the task, 404 for an unknown id. @dev hands it to senior-dev, @review checks the branch, and you merge only on pass.What you see
Within seconds the manager hires its line: Asked for a new member @dev in "shipping", then @review, and the rail header reads ● shipping ◆ Manager @dev ⠿ working +2 idle. The team's Traffic tells the story of each change. For our second change it read, in order: @dev wants to start a [senior-dev] task; @dev reports GET /tasks/<id> is done and passed with its branch task/get-tasks-id-endpoint-4b5f86; @review answers PASS with the size of the diff, (+22/−1); and main gains 8c641f2 taskboard: add GET /tasks/<id>. The manager closes with Done, the branch merged into main, and 41 tests, OK.
In our run
The second change took 2 minutes and 45 seconds from the message to the merge on main. The team spent $0.87 across both changes, reviews included.
Make it yours
- Keep a merge commit. A passing branch is merged the simplest way, which can be a fast-forward. Add "merge with --no-ff" to the brief if you want every change to show as a merge on main.
- Tighten the review. Tell the manager what @review must check beyond the tests: a changelog line, no new dependencies, docs for every new endpoint.
- Route work to it from above. Put the review line under a global manager, as in Build a software company, and any team's change can go through shipping before it lands.
Go further
Hand a job to a specialist: Talk a change through in any chat, then say "give this to senior-dev" and the chat hands the job over with everything it found.
Coming soon: describe the org you want and CodeAF builds it: teams, managers, budgets, standing orders.