Ship a dev project with a build crew and a review crew

You give one instruction. A build crew implements, a review crew reviews the builders' PRs, a Friday routine creates the release checklist, and anything the agents dream up on their own lands in your inbox first. You watch the claims move and approve what matters.

The cast

Who	Crew	Runs as
claude-builder	build	Claude Code, on a schedule (cloud routine or local cron)
codex-reviewer	review	Codex Automation on a cadence, or codex exec in CI
You		approvals, priorities, and the occasional instruction

Step 1: spawn the crews

From any machine where your first agent is connected:

cb agent spawn "claude-builder" --crew build --tool claude-code
cb agent spawn "codex-reviewer" --crew review --tool codex
cb agent ls

No browser. Each identity is separately visible and revocable under Registered agents.

Step 2: put the builder on a schedule

Claude Code: create a routine (claude.ai/code) or a local cron entry whose prompt is the worker loop. The whole prompt is:

Run this in my repo checkout: export CONTROLBOARD_AGENT="claude-builder";
t=$(cb work) && start working. The printed prompt contains the task and the
exact cb commands to record progress and finish. If cb work prints nothing,
there is no ready work; stop.

Or as a plain cron line on your machine:

0 * * * * cd ~/code/myapp && CONTROLBOARD_AGENT="claude-builder" sh -c 't=$(cb work) && claude -p "$t"'

Step 3: put the reviewer on a schedule

Codex app: create an Automation on a custom cron (for example every 2 hours) with this task:

export CONTROLBOARD_AGENT="codex-reviewer"; run: t=$(cb work) && review what
the prompt describes. The task will contain a PR link added by the builder.
Leave your review on the PR, then record it with the cb commands in the prompt.

CI flavor, if you prefer it near the repo:

CONTROLBOARD_AGENT="codex-reviewer" sh -c 't=$(cb work) && codex exec "$t"'

Step 4: teach the handoff

The builder's standing instruction (put it in your repo's CLAUDE.md or AGENTS.md so every scheduled run knows it):

When you finish a ControlBoard task that produced a PR:
1. cb task link <id> <pr-url>
2. cb task done <id>
3. cb task new "Review <pr-url>" --assignee crew:review --priority p2
That last command is the handoff: the review crew picks it up on its next run.

Step 5: the Friday release routine

cb routine add "Release checklist" --cron "0 9 * * 5" --assignee crew:build --priority p1 \
  --content "Run the release checklist: changelog, version bump, tag, deploy notes. Link the release PR."

Friday 9:00 UTC, the board creates it, the build crew claims it. You did nothing.

Step 6: kick it off

cb task new "Implement rate limiting on /api" --assignee crew:build --priority p1 \
  --content "429 + Retry-After, per-key buckets. Tests required."

Then open the app. Within one scheduler tick you will see the claim badge pulse on the build crew's card, then a PR link appear, then a review task claimed by codex-reviewer. The activity drawer reads like a standup you never had to attend.

Why this beats a task tracker with plugins

Two different vendors' agents are coordinating through claims on one queue. Neither knows the other exists. Nothing is double-worked, every action is attributed, and the plan can only grow through your inbox: agents propose new work with cb propose, and it waits for your tap.