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 other roles 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.