Copy My Setup: 4 Templates I Use to Run 8 AI Coding Agents

Steal these. They’re the real files behind my company, with the private parts stripped out.

---

If you saw my numbers this morning, the obvious question is how I actually tell the agents what to do.

The answer is boring. I write things down in the same shape every time.

I’m a solo founder building Cities In My Pocket. Grok Bot is my Mission Control. Claude Code, Codex and Cursor run as coding lanes. Since October 6 those lanes have run 1,208 times. My repo has 1,176 merged pull requests, and 292 of them landed since last Sunday.

None of that comes from clever prompts. It comes from four templates. Mission Control fills them in, the agents read them, and nobody has to guess.

Below are generic versions of each one. I took my real files, cut out the paths, repo names and anything private, and kept the structure. Copy them and change the nouns.

---

1. The lane brief

Every piece of work starts as a brief in a lane’s queue file. I have 17 queue files and more than 1,250 briefs across them. Almost all of them are now marked done.

The brief is the most important template I have. A coding agent with a vague task invents scope. A coding agent with this brief knows where to start, where to stop, and how to prove it finished.

## [todo] TASK-ID: One-line title a human can read

Class:      SMALL | MED | LARGE
Model:      which agent and model runs this
Item:       What to build, in 2-4 sentences. Name the screen
            or service. Say what must NOT change.
Spec:       The doc or approved mockup this follows.
Migrations: none (or the one number reserved for this task)
Scope:      Branch from latest main. Files you may touch: ...
            Check open PRs first. If a file belongs to another
            open PR, don't edit it. Write the needed change
            in your PR body instead.
Acceptance:
  - each line is a check someone can verify
  - feature parity with today, nothing removed
  - tests green for the package you touched
END line:   END TASK-ID PR #<n> CLOSED | PARTIAL: <reason>
Guards:     never merge, never force-push, no secrets,
            flags default off, open the PR as a draft

Three fields do most of the work.

Scope stops collisions. When eight agents run at once, a common failure is two of them editing the same file. The “check open PRs first” line turns that into a clean stop instead of a merge conflict.

Acceptance is what the reviewer grades against later. If you can’t write a checkable line, the task isn’t ready.

END line is how Mission Control knows the run finished. A run that ends without printing it gets treated as failed, even if it looked fine. Early this morning one run ended its turn while a long test job was still going in the background and pushed nothing. The retry brief now says: run checks in the foreground, push before any long test run, and always print the END line.

2. The lane mission

The brief covers one task. The mission covers the whole lane. It’s the first thing the agent reads in every session, before it looks at the queue.

Mine are long. The part worth copying is short:

You are lane "<name>". You work in a fresh clone of the repo.
Branch prefix: lane-<name>/   PR title prefix: [lane-<name>]

MISSION: <the product area this lane owns, in one sentence>
Items this lane owns: <ID>, <ID>, <ID>

Operating mode:
1. Whole items, not slices. Close one item end to end:
   data, logic, API, wiring, tests. Then the next.
2. Other lanes own other items. Use their contracts.
   Never edit their files.
3. Money: no live charges. Test mode only.
4. Messages: no real sends. Drafts or sandbox recipients.
5. Anything that changes live behavior ships behind a
   flag that is off by default.
6. When you're done or stuck, write it in your report
   file and print the END line.

“Whole items, not slices” came from me telling Mission Control the work needed to go faster. Agents left alone love to ship a thin slice and call it progress. Ten half-finished pull requests are worse than three whole ones, because every half needs its own review and its own rebase.

The ownership line matters just as much. Each lane owns a list of items by ID. If a lane needs something another lane owns, it builds against the documented shape and waits. It doesn’t reach over.

3. The reviewer checklist

The agent that writes the code never reviews it. A second agent does, read-only. It can read files, grep and look at diffs. It can’t edit, push, comment or merge.

My real reviewer prompt has 11 rules. Here’s the generic version, cut to the ones every setup needs:

You are an independent reviewer. You did NOT write this PR.
Decide if PR #<n> may merge. Read-only. Never edit or push.

Each of these is a BLOCKER (cite file:line and the fix):
1. A real test or typecheck failure caused by this PR.
2. Real bugs, broken contracts, or tests weakened or
   skipped to go green.
3. The PR claims done but leaves real gaps unlisted.
4. It duplicates work already on main or in the queue,
   or conflicts in intent with an overlapping PR.
5. A database change that isn't additive and reversible,
   or any attempt to apply one from the PR.
6. A new behavior flag that defaults on.
7. Any path that charges a real card or messages a
   real person.
8. Secrets in any added line. New providers or packages
   without a clear reason.

Nits are not blockers. Be decisive.

Output exactly one JSON block:
{ "verdict": "no_blockers" | "blockers",
  "blockers": ["file:line - rule - exact fix"],
  "requires": [PRs that must merge first],
  "supersedes": [PRs this one replaces] }

Two details make this work.

The JSON output means a script can act on the verdict. A pass goes into a merge queue. Blockers go back to the lane that owns the branch, with the exact fix written out.

“Requires” and “supersedes” handle ordering. Agents often redo work that another branch already started. The reviewer names which PR wins, and the loser gets closed after the winner merges.

4. The design approval gate

This is the easiest one to skip, and skipping it can leave you with eight agents redesigning the app eight different ways.

No agent changes how a screen looks until I’ve approved a mockup. For my current chat redesign I approved 7 mockups first. Then Mission Control wrote a build plan that every chat task points to. The top of it looks like this:

BUILD PLAN: <feature name>
Spec: this file + the approved mockups (list them by name)

Hard rules for every task:
- Client only. No backend, API, prompt or database changes.
- Ships behind an existing flag, default off.
- Flag off = today's screen, exactly.
- Each app keeps its own theme. No new global fonts,
  logos or design system.
- Never cut a page or a feature.
- No new art without the owner's OK. If a state has no
  art yet, fall back to the closest existing one.

Missing pieces (and their fallback):
- <state with no art>  ->  use <existing state>

The fallback list is the part I’d copy first. Agents hit gaps. Without a written fallback they either stop or invent something. With one, they pick the listed option and keep going, and I review the real gap later.

“Flag off equals today’s screen” is what lets design work merge every night. The new look can sit in main for days before anyone sees it.

---

How to start

Don’t build all four on day one. Start with the lane brief. Write five of them by hand for real tasks in your repo. Run one agent against them. Read every pull request.

You’ll find the holes fast. Every hole becomes a new line in the template. That’s how mine grew.

Once the brief is stable, add the reviewer. Then the mission per lane. Add the design gate the first time two agents disagree about what a button looks like.

This morning I wrote about the rules that sit above all of this. These templates are where those rules actually reach the agents. If you copy one of them, tell me what you changed.