A two-phase workflow for driving a fleet of MRs/PRs to done in parallel with a manager that never touches a working tree. Platform-neutral: all VCS/CI mechanics delegate to /mr and /ci.
why-no-hook: skill workflow guidance; each step requires understanding the surrounding context (repo, task shape, prior state).
\n(review-time: see section note)(review-time: see section note)/build + /mr directly (review-time: see section note)The built-in /goal command keeps the session working across turns until the condition holds, then auto-clears. Set it once, in the MANAGER session - it is session-scoped and resets on resume, so a re-planned session re-sets it.
Template (fill the {knobs}):
\n\nEvery open MR/PR from
\n{plan}is CI-green, reviewed ({review_depth}applied via review-pr), rebased on{target_branch}, and passes every automated spec criterion at HEAD.{post_completion_action}
| Knob | \nDefault | \n
|---|---|
target_branch | \nmain | \n
review_depth | \nblockers + majors + one-line fixes | \n
post_completion_action | \nnone (repo-specific; e.g. \"Once all hold simultaneously, trigger the notify_reviewers job on each\") | \n
/grill-with-docs to pressure-test the approach against the existing domain model, sharpen terminology, and emit CONTEXT.md terms inline. (review-time: see section note).claude/state/plans/ that defines the lanes / MRs and proves they are file-isolated - no two lanes touch the same file. (review-time: see section note)The plan is the contract. Approving it and setting the /goal is your batched authorization for the fleet (see orchestration.md).
Phase 2 is started by you, the operator - the agent cannot open its own session or set its own goal:
\n(review-time: see section note)/goal <condition> (built into Claude Code). With auto mode on, /goal is what keeps the one manager session working turn after turn until the fleet meets the condition, then auto-clears. (review-time: see section note)(review-time: see section note)This stays a single, thin manager session the whole time - it never spawns nested sessions. Its context stays small because all editing / review / rebase / conflict work goes to subagents (each with its own context window) and worktrees; the harness compacts the manager's context as it grows. The main loop manages and nothing else - it never edits, reviews, rebases, or resolves conflicts.
\n\n\nIf this skill is invoked with no
\n/goalset, stop and ask the operator to set one (ideally in a fresh session) before running the loop.
Phase 1 (planning session) - describe the work; the agent grills and plans:
\n/drive-fleet\nAdd a feature-flag system end-to-end: the evaluation service in the api repo,\nthe React hook + toggle UI in the web repo, and the shared flag schema in the\nshared-types repo. Plan file-isolated lanes across the three repos.\nThe agent runs /grill-with-docs, proves the lanes share no files, writes the plan to .claude/state/plans/, and hands back the /goal line to use next.
Phase 2 (fresh session) - set the goal, turn on auto mode, start the loop:
\n/goal Every open MR/PR from the feature-flags plan is CI-green, reviewed\n(blockers + majors + one-line fixes via review-pr), and rebased on main.\n/drive-fleet\nExecute the plan at .claude/state/plans/2026-06-02-feature-flags.md\nThe manager builds the three lanes in parallel worktrees, opens the MRs, then drives CI-fix / review / rebase per repo until the goal clears. Your only input after that is any escalation.
\nManager orchestration loop, authorization model, guardrails, and the per-repo block: see orchestration.md.
\n/grill-with-docs, /mr, /ci, /pr-comments, /review-pr, /worktree; agent personas Frontend Staff Engineer, Backend Staff Engineer, and PR Reviewer (via Agent subagent_type).