Edison SinaniAI implementation architectBook a call

AI Team Playbook / Rule 6 of 12

One task, one worktree, one pull request

Every task is built in its own worktree, on its own branch, and lands as one pull request under 400 changed lines.

September 16, 2026 · About 2 minutes

Contents

The playbook

  1. Overview

Before code

  1. 1Write the constitution first
  2. 2One instruction file, under 200 lines
  3. 3Enforce the rules with settings and hooks
  4. 4Three gates before any code
  5. 5A walkable demo before any screen

Building

  1. 6One task, one worktree, one pull request
  2. 7Every contract has a file and two tests

Reviewing

  1. 8AI review first, and filtered
  2. 9Human review by risk tier
  3. 10Done means the evidence is in the pull request

Over time

  1. 11Measure five numbers, baseline first
  2. 12Protect the people who are still learning

Appendix

  1. AInstall checklist
  2. BOther tools, limits and sources
  3. CTightening the process
  4. DRun the agent with no entitlements

Get the kit

Who owns it
Every developer. The lead may allow an exception with the override label and a written reason.
In the kit
.github/workflows/pr-checks.ymldocs/specs/_template/tasks.mddocs/review-policy.md
Enforced by
The pr-size check in CI fails any pull request over 400 lines unless it carries the size/xl-override label. Branch protection requires the check.

Why

In 107,026 agent-written pull requests, the smallest tenth, with a median of two lines changed, conflicted on merge about 10 percent of the time. Pull requests of 46 to 185 changed lines conflicted 32 to 33 percent of the time [3]. Reviewers also go through 11.8 percent more review rounds on agent-written code than on human-written code [4]. Both get worse as pull requests grow, and a human has to handle both.

Why 400 lines: the conflict data does not point to one threshold. Conflicts keep falling as pull requests get smaller, and they already reach a third by 185 lines. So 400 is a ceiling. Most tasks should land well under it. It is the top of the range where reviewers still find defects well: in a study of 2,500 code reviews at Cisco, reviewers were most effective at 200 to 400 lines per review, and defect discovery fell off beyond that [24]. Zalando’s teams, after watching agent pull requests grow, agreed fixed size limits among themselves, without tooling to enforce them [11]. The kit enforces the limit in CI, because a size agreement between people does not apply to an agent. A team that wants a different number writes its reason into the review policy.

How

Start each task in a worktree. A worktree is a second working copy of the repository on the same machine, on its own branch. Two developers, or one developer with two tasks, never touch each other’s files.

# from the repository root, on the main branch, up to date
claude --worktree task-130-derive-titles

The worktree lands under .claude/worktrees/, which is ignored by git. Its branch is named after it, worktree-task-130-derive-titles. Rename it to the team convention before the first commit, with git branch -m task/130-derive-titles. Permissions granted in one worktree are saved to the main checkout, so the same command does not need approval again in every task. When the pull request merges, delete the worktree.

Size the task before starting it. The task list from rule 4 already sized it: one pull request, one person, under a day. If it will not fit, the task’s Touches line usually shows where to split. A migration plus its code plus its screen is three pull requests, merged in order.

Run parallel tasks only when their files do not overlap. Two tasks whose Touches lists share a file are never marked [P]. Anything that changes a contract runs first, alone, and merges before anything that depends on it starts. Rule 7 says why.

Count only real lines. The CI check counts only this branch’s own changes since it left main, and excludes generated files: lockfiles, test snapshots, contract manifests, and EF migration designer and model snapshot files. Over the limit, it fails with a message that says to split, or to add the size/xl-override label with a reason in the pull request body. Adding the label re-runs the check at once. The reviewer reads that reason.

Do not fix unrelated things on the way. Anything found while working on a task becomes a tracker entry for later. Unrelated fixes make a diff harder to review.

References

  1. 3Daniel Ogenrwot and John Businge, "AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub", arXiv 2604.03551, April 2026. 107,026 pull requests. arxiv.org/abs/2604.03551
  2. 4Suzhen Zhong, Shayan Noei, Ying Zou and Bram Adams, "Human-AI Synergy in Agentic Code Review", arXiv 2603.15911, March 2026. 278,790 review conversations across 300 open source projects. arxiv.org/abs/2603.15911
  3. 11Zalando Engineering, "Agentic Engineering at Zalando: a snapshot", August 2026. engineering.zalando.com/posts/2026/08/agentic-engineering-at-zalando-a-snapshot.html
  4. 24Jason Cohen, "Best Kept Secrets of Peer Code Review", SmartBear Software, 2006. Cisco MeetingPlace case study: 2,500 reviews of 3.2 million lines of code over 10 months; reviewers were most effective at 200 to 400 lines per review. www.stickyminds.com/article/largest-case-study-code-reviews-ever