Alfred
Plan once. Build across every repo.
The architect drafts one approved plan across the repos you choose, files scoped tasks in each repo, and hands those tasks to senior-dev, test-engineer, fixer, reviewers, and your merge gate.
One request becomes one pull request per repo.
The diagram below shows the architect handoff boundary. Each repo gets its own task, senior-dev picks it up on the next run, and each pull request passes its own review, test, and merge gate.
A plan, then a task per repo, then the work.
The architect reads one parent-plan issue, drafts the rollout, and posts it to Slack or the local client for approval. After approval, the architect files scoped tasks in the right repos. Senior-dev and the rest of the fleet claim those tasks through the normal queue, with the same worktree, spend, review, and merge gates as any other run.
The plan the architect drafts
A task it files in one repo
One label per stage. No database.
The same GitHub labels as a single-repo run, plus one extra label that ties each task back to the plan it came from.
agent:large-feature You add this to a feature request. The architect picks it up, drafts a plan, and posts it to Slack for approval.
agent:bundle:<slug> Added to every task the architect files, so each one points back to the plan it belongs to.
agent:implement Each task starts with this label. Senior-dev can claim repo-sized tasks independently, each in its own worktree.
agent:done Added to a task when its pull request merges. You can use the completed tasks to close the parent feature request with a clear trail.
Test the architect before you spend anything.
The architect never files tasks without your approval. A dry run checks the local wiring without touching GitHub, Slack, an LLM, or your repos.