Menu
Coordinate a sweeping mechanical change across independent work units and pull requests.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Fork one isolated Codex worktree thread per Beads issue and start each with a dependency-aware completion contract. Use when the user asks to start, fork, split, parallelize, or create separate chats for beads, tickets, issues, or a backlog with the goal of fixing them all.
This skill should be used when the user asks to "bump a package", "update an upstream revision", "refresh a Nix source hash", "rebase local patches", "carry fork changes as patches", "hack on upstream software in this repo", or fix a package whose patches no longer apply.
Jujutsu version control through jut, a human and agentic framework around jj. Use for: check status, view changes, commit work, create branches, push, pull, create PRs, squash commits, reword messages, absorb changes, undo operations, view history. Complements jj — use jut for opinionated workflows, drop into raw jj for everything else.
Create, manage, and verify healthchecks.io monitors via the REST API. Use when adding monitoring to a new cron job or service, auditing existing checks, wiring ping URLs into configs, or verifying a check fired correctly.
Control live Herdr workspaces, tabs, panes, agents, worktrees, layouts, plugins, and waits. Use when running inside Herdr (`HERDR_ENV=1`) to inspect sibling agents, delegate work—including dedicated Pi workspaces—run services, debug agent detection, or coordinate terminal state.
Structural code search, refactoring, and repository lint-rule setup with ast-grep. Use when searching by syntax shape, writing or testing ast-grep rules, configuring sgconfig.yml, enforcing coding standards, selecting rule severity, or adding ast-grep to project checks and CI.
| name | batch |
| description | Coordinate a sweeping mechanical change across independent work units and pull requests. |
You are orchestrating a large, parallelizable change across this codebase.
(The user's instruction goes here — passed as the skill argument.)
Call the EnterPlanMode tool now to enter plan mode, then:
Understand the scope. Launch one or more Explore agents (in the foreground — you need their results) to deeply research what this instruction touches. Find all the files, patterns, and call sites that need to change. Understand the existing conventions so the migration is consistent.
Decompose into independent units. Break the work into 5–30 self-contained units. Each unit must:
Scale the count to the actual work: few files → closer to 5; hundreds of files → closer to 30. Prefer per-directory or per-module slicing over arbitrary file lists.
Determine the e2e test recipe. Figure out how a worker can verify its change actually works end-to-end — not just that unit tests pass. Look for:
claude-in-chrome skill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result)tmux or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)If you cannot find a concrete e2e path, use the AskUserQuestion tool to ask the user how to verify this change end-to-end. Offer 2–3 specific options based on what you found (e.g., "Screenshot via chrome extension", "Run bun run dev and curl the endpoint", "No e2e — unit tests are sufficient"). Do not skip this — the workers cannot ask the user themselves.
Write the recipe as a short, concrete set of steps that a worker can execute autonomously. Include any setup (start a dev server, build first) and the exact command/interaction to verify.
Write the plan. In your plan file, include:
Call ExitPlanMode to present the plan for approval.
Once the plan is approved, spawn one background agent per work unit using the Agent tool. All agents must use isolation: "worktree" and run_in_background: true. Launch them all in a single message block so they run in parallel.
For each agent, the prompt must be fully self-contained. Include:
After you finish implementing the change:
1. **Simplify** — Invoke the `Skill` tool with `skill: "simplify"` to review and clean up your changes.
2. **Run unit tests** — Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like `npm test`, `bun test`, `pytest`, `go test`). If tests fail, fix them.
3. **Test end-to-end** — Follow the e2e test recipe from the coordinator's prompt (below). If the recipe says to skip e2e for this unit, skip it.
4. **Commit and push** — Commit all changes with a clear message, push the branch, and create a PR with `gh pr create`. Use a descriptive title. If `gh` is not available or the push fails, note it in your final message.
5. **Report** — End with a single line: `PR: <url>` so the coordinator can track it. If no PR was created, end with `PR: none — <reason>`.
Use subagent_type: "general-purpose" unless a more specific agent type fits.
After launching all workers, render an initial status table:
| # | Unit | Status | PR |
|---|---|---|---|
| 1 | running | — | |
| 2 | running | — |
As background-agent completion notifications arrive, parse the PR: <url> line from each agent's result and re-render the table with updated status (done / failed) and PR links. Keep a brief failure note for any agent that did not produce a PR.
When all agents have reported, render the final table and a one-line summary (e.g., "22/24 units landed as PRs").