orchestrate
Skill14 starsChanged 48 days agoMITView on GitHub
Multi-agent implementation of a blueprint; parallel-safe tasks in waves, the rest in order, then verify. Use to execute an approved plan.
161 other projects use a version of this.
Adopted by
Most recently taken up by
- alexratmanpl/business-agent-skillstheir own version, first seen Nov 8, 2026
- gtonkov/claude-codetheir own version, first seen Nov 8, 2026
- edilsonvilarinho/usage-monitortheir own version, first seen Nov 8, 2026
- nathanonn/agent-skillstheir own version, first seen Nov 8, 2026
- peterpme/skillstheir own version, first seen Nov 8, 2026
- GDriem/agent-skillstheir own version, first seen Nov 8, 2026
Used with
Projects with it also use define-requirements, orchestrate-plan and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
sson0-erSkilldefine-requirements
Work with the user, one question at a time, to complete the requirements document (docs/claudex/<slug>/01-requirements.md). Run by the orchestrator (parent). Stays out of design and implementation.
Also in 3 projects that use this
EternallLightSkillorchestrate-plan
Use when executing a locked, reviewed PLAN.md by delegating the implementation to visible worker agents in Orca, herdr, or cmux ONE PHASE at a time — splitting the plan into context-window-sized phases, giving every phase a pristine worker context, and (when the plan touches INDEPENDENT repos) running one worker per repo IN PARALLEL. Triggers on "run the plan with a worker", "execute the plan in the other pane", "split the plan into phases and build it with workers", "build the backend and frontend in parallel panes". Not for edits you can finish inline; outside Orca, herdr, or cmux use tgc-skills:orchestrate.
Also in 3 projects that use this
sson0-erSkillrecord-evidence
How to record external facts (docs, command output, codebase findings) as evidence and design choices as decisions. Used by the researcher, designer and reviewer agents.
Also in 3 projects that use this
PinkneyJiangSkillimprove-architecture
扫描代码库中的架构摩擦点,识别浅模块并挖掘深模块演进机会。生成可视化交互式 HTML 诊断报告,并在用户确认后闭环实施深度重构。
Also in 4 projects that use this
kjnezSkillticket
Work on a JIRA/Linear ticket end-to-end: read ticket details, explore codebase, create a branch, implement with TDD, run quality checks, update ticket status, and create a PR. Use when the user provides a ticket ID to implement. Triggers on requests like "/ticket PROJ-123", "work on this ticket", "implement PROJ-123".
Also in 4 projects that use this
xfstudioSkillreverse-engineer
Expert reverse engineer specializing in binary analysis,
Also in 3 projects that use this
Other versions161 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 161
- Significant-Gravitas/AutoGPT★ 188ksame name
- rohitg00/pro-workflow★ 2.9ksame name
- apmantza/pi-lens★ 521same name
- boshu2/agentops★ 453same name
- quantumaikr/quant.cpp★ 403same name
- Noizefield/audio-plugin-coder★ 334same name
- kagenti/kagenti★ 303same name
- varun29ankuS/shodh-memory★ 294same name
- provencher/codex-skills★ 271same name
- first-fluke/fullstack-starter★ 226same name
151 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- accelerateSkill
- almanacSkill
- autopsySkill
- blueprintSkill
- certifySkill
- chronicleSkill
- confluenceSkill
- conjureSkill
- deploySkill
- divineSkill
- inscribeSkill
- jiraSkill
- knowledge-graphSkill
- magicSkill
- manifestSkill
- portalSkill
- scrutinizeSkill
- sealSkill
- sentinelSkill
- statuslineSkill
- transmuteSkill
- unravelSkill
- wardSkill
- weaveSkill
The file
We split this skill into the rules it gives an agent
2 rules. 0 are common, 1 is distinctive, and 1 is very specific to this project.
0
Common
Most of the 144 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 79
Keep moving: Run this loop task-to-task without pausing to ask the human "should I continue?" — advancing through reviewed-and-clean tasks …
- Very specific: line 83
After each wave: git status | grep -i conflict.
“Common” is measured: kept by at least 6 in 10 of the 144 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/orchestrate — Multi-Agent Implementation
Bundled command: if
kgis not found, run it as${CLAUDE_PLUGIN_ROOT}/tools/kgand give subagents that full path. If that is missing too (Claude chat ships no plugin tools), skip thekgsteps and search the code directly.
Execute an entire blueprint with parallel + sequential agent dispatch.
Pick the right engine first
- Inline with
/ward— first check: when the plan's Files lists name 3 files or fewer in total (about 300 changed lines or fewer), run its tasks in order in the main loop, one/wardcycle each, with noTaskcall (lore/fold-first.md). - This skill — the default above that size: you control waves explicitly from a blueprint, with conflict checks between them.
/weave— for adaptive multi-item delivery (N tickets/features, a migration, a batch sweep) where you compose the pipeline to the work: it builds ONE native Workflow with magician's guardrails (TDD per unit, kg grounding, certify, multi-lens review + adversarial verify, write gates). Prefer it over hand-rolling many agents.- Native dynamic workflows — for very large plans (hundreds of independent units), mention "workflow" so Claude builds a dynamic orchestration plan across many subagents. Works best in auto mode.
- Agent teams — when workers must talk to each other and share a task list, prefer an agent team over one-way subagents.
Choose by scale and whether workers must communicate; otherwise proceed with waves below. Whichever engine you pick, inline included, write .workspace/local/session-state.md (step 3) before the first task runs. The context contract (below) applies to every spawned agent — no worker inherits this conversation.
Effort & model
Effort: medium for implementation turns, high for certify/review/security turns (xhigh for very large plans; max only as an opt-in for frontier problems); on Bedrock/Vertex/gateways hold one level (an effort change drops the cache there). Dispatched implementers take the coding-optimal tier; suggest a session-model upgrade if it's older than the latest. See lore/models.md.
Cap the fan-out. The blueprint's parallelism map is the ceiling, not a floor. Above the inline threshold, a wave with two or more independent Parallel: YES tasks always fans out: one agent per task, dispatched together in one message, even when each task looks small. A one-task wave, or a sequential task you finish in a handful of tool calls, runs inline; that exception never applies to a parallel wave. Never spawn an agent purely to re-check work an agent just did — the per-task quality loop below is the check. See lore/fold-first.md and lore/model-behavior.md.
Process
- Read the blueprint — most recent in
.workspace/shared/plans/unless$ARGUMENTSnames one. If ambiguous, ask which plan via AskUserQuestion (one option per candidate plan file or folder, most-recent first); end your turn at the call and proceed with the chosen plan.- Plan folder (
plan.jsonnext toplan.md):plan.jsonis the source — read it with Read. Task N issteps[N-1]; a step withreview.statusofdeferredis excluded from the graph (they are listed under## Deferred — not executed this runinplan.md). Check the last line ofplan.md,<!-- magician.plan/1 v<n> … -->: ifv<n>differs fromplan.json.version, say the plan is stale and ask the user to re-runplan-render all <dir>/plan.json(or/blueprint review <dir>) before executing; do not run it from here. - Plan folder with
plan.workflow.js(plan-render workflowwrites it next toplan.json; deferred steps are already omitted): prefer running it as one native Workflow — read the file and pass its contents as theWorkflowscript, as/weavedoes. The Workflow tool is not pre-approved here, so Claude Code shows its approval prompt. Nothing is copied into.claude/workflows/. Confirm the file is the plan's own version first (itsmeta.descriptioncarriesv<n>; a mismatch withplan.json.versionmeans stale — re-render). Skip the workflow and fall back to waves (below) whenplan.workflow.jsis missing, when workflows are disabled (disableWorkflows, Pro without the/configtoggle), when the user asks for wave-by-wave control, or when the Workflow run reportsnothing to resumeafter an interruption. Each workflowagent()already carries the context contract and the returnschemabelow; the per-task quality loop still runs on its results. - Single
plan.md(legacy): parse it as before —### Task N,Parallel:, Files, the five TDD lines.
- Plan folder (
- Build the execution graph — from
plan.json, thewavesare explicit: each wave'sparallel: truesteps run together, itsparallel: falsesteps one at a time after them. From a legacyplan.md, group PARALLEL-annotated tasks into waves; SEQUENTIAL tasks are singletons that run in order. (Withplan.workflow.jsthe graph is the script'sphase()/parallel()structure — skip to step 5 when the run completes, after ticking the- [ ]boxes of every step its results report as done.) - Execute wave by wave. Before the first wave, write
.workspace/local/session-state.md(goal · plan path · wave graph · decisions · blockers): with Task tools (TaskCreate/TodoWrite) absent on current models unlessCLAUDE_CODE_ENABLE_TODO_TOOLS=1, the plan file's- [ ]boxes plus that file are the compaction-proof checklist; tick a box only after its quality loop passes. When a parallel wave's prompts share a prefix (conventions, plan, return contract first; per-task text last), dispatch the first task alone, then the rest in ONE message (multipleTaskcalls) so siblings reuse the first agent's cached prefix; with no shared prefix, send the whole wave in one message. Wait for the whole wave before the next. Run sequential tasks one at a time. As each task's implementer returns, run the Per-task quality loop (below) before you mark that task done — completion is confirmed from the VCS diff, not the agent's report. - After each wave — sanity check:
git status,git log --oneline -3. Rewrite.workspace/local/session-state.md(goal · completed/remaining tasks · decisions · blockers · artifact paths) so the next wave's agents start current and a mid-run compaction loses nothing (the spawn template tells every agent to read it first). - After all waves — run /certify. If it fails, fix and re-certify (bounded evaluator-optimizer loop) before reporting complete — never report done on a red certify.
- Report — completed tasks and any blockers.
Independent sessions aren't in the graph. When a wave lands something that invalidates what a sibling Claude Code session is building on, and cross-session messaging is available, send that session one self-contained sentence. Feature-detect and skip silently; a wave never waits on a peer. See lore/cross-session.md.
Autonomy — approve the plan, then run
The blueprint is the gate. Once it's approved (step 1), run the rest — Execute wave by wave, the per-wave sanity checks, and the session-state refresh — autonomously: don't stop to ask the owner before reading, searching, kg query/blast, or read-only git (the git status/git log --oneline checks in steps 4–5), and never re-gate between waves. Claude Code's built-in read-only commands don't prompt; this skill pre-approves kg query/blast and edits to .workspace/local/session-state.md; anything else the agents run goes through the normal permission prompt unless the user runs in auto mode or approves it. Re-gate only on real side effects: the writes/git add·commit·push/PR actions the dispatched agents perform, a merge conflict surfaced by Conflict detection, the batched worker questions, and the final /certify. See lore/autonomy.md.
Agent prompt — context contract (no context loss)
Spawned agents see NONE of this conversation. Every Task prompt — and every agent() prompt in plan.workflow.js — MUST be self-contained (see lore/subagent-context.md):
Goal: implement task <N> — <one-line deliverable>.
Scope: files/paths in play: <exact list>. Out of scope: <...>.
Inputs: full task text from the plan (paste it — the `### Task N` block from plan.md, which carries the step's red/green/verify from plan.json), the Global Constraints, and the spec at .workspace/shared/specs/<feature>.md. FIRST read .workspace/local/session-state.md if it exists (current goal, decisions, blockers, artifact paths). Locate code with `kg query`/`kg blast`, not broad greps.
Constraints: follow TDD via /ward; conventions/lore: <...>; do not touch <deny paths>; definition of done: <...>.
Available magician skills: /conjure /blueprint /ward /unravel /certify /orchestrate /scrutinize /portal /seal /manifest /almanac /chronicle /magic /sentinel /accelerate /deploy /inscribe /autopsy
Return (bounded — distilled, never raw logs): STATUS: DONE | BLOCKED | NEEDS_CONTEXT; summary ≤ 1200 chars of what was implemented and committed; files_changed: <list>; commit: <sha or none>; obstacles: none, or one block per obstacle (lore/obstacles.md fields: STATUS, OBSTACLE, BLOCKER, SEVERITY, WORKAROUND, RECURRENCE, SCOPE, NEXT). A question for the human goes in NEXT.In a Workflow, encode the same return as the agent() schema (maxLength strings, files_changed[], obstacles[]) — see /weave's template.
Handle results
- DONE — a claim, not proof: run the Per-task quality loop (below) and confirm the change from the VCS diff before recording it.
- NEEDS_CONTEXT — this is a context-completeness bug in the spawn prompt. Add the missing input and re-dispatch; don't guess for the agent.
- BLOCKED — assess the blocker, re-dispatch with more context, or escalate.
- A question for the human — a worker puts it in its Obstacles
NEXTfield and does not wait. Collect the questions of the whole wave, merge duplicates, and ask them in ONEAskUserQuestionafter the wave returns. Never ask once per worker (lore/obstacles.md).
Per-task quality loop — review before "done"
A subagent reporting STATUS: DONE is a claim, not evidence. Before you mark any task complete, confirm it from the VCS diff and put it through a two-stage review — see lore/verification.md.
- Confirm from the diff, not the report. Run
git show/git difffor the task's commit(s) and read the actual change. The diff is the evidence a task landed — a subagent's "success" is not. If the diff is empty, or doesn't match the deliverable, the task is not done: re-dispatch with the gap named. (These are read-only git reads, which Claude Code doesn't prompt for — see Autonomy above.) - Stage 1 — spec compliance. Against the task's full text and
.workspace/shared/specs/<feature>.md, does the change do exactly what the task specified — no more, no less? Flag missing requirements, scope creep, and silent deviations. - Stage 2 — code quality. Judge correctness, simplicity, and tests: does it hold on edge cases, is it the simplest thing that works, and are the tests real (proven RED→GREEN) and green? Prefer a fresh reviewer subagent (or
/scrutinize) so no author bias carries over. - Fix, then re-review. For any Critical or Important finding, dispatch a fresh fix-subagent — self-contained prompt, same context contract — to resolve it, then re-run this loop on the new diff. Minor findings can be recorded and batched. A task counts as DONE only once its diff is clean on both stages.
Keep moving. Run this loop task-to-task without pausing to ask the human "should I continue?" — advancing through reviewed-and-clean tasks is exactly the autonomy the approved blueprint bought. Stop only on an unresolvable BLOCKER, a merge conflict (see Conflict detection), or all tasks done.
Conflict detection
After each wave: git status | grep -i conflict. If conflicts are found, pause and resolve before continuing. (For parallel tasks that edit overlapping files, prefer worktree isolation per task.)
Obstacles
As a consumer — every dispatched worker returns an Obstacles block on a non-clean run. Roll them up into one report kept apart from the deliverables (a blocked unit never reads as done), detect a pattern by a normalized BLOCKER + SCOPE signature, and memorize a confirmed pattern with ctx learn --add "<signature -> workaround / next-action>" in your own words — never verbatim worker text, secrets, or PII. Protocol: lore/obstacles.md.
As a producer — if this skill runs as a dispatched unit and hits something that blocks or degrades the work, do not wait for a human who is not there and do not silently ship a degraded result — return the Obstacles block from lore/obstacles.md (fields: STATUS, OBSTACLE, BLOCKER, SEVERITY, WORKAROUND, RECURRENCE, SCOPE, NEXT) to the caller alongside whatever you completed; interactively, say the same in prose.
Completion Signal
"Orchestrate complete. N tasks executed across M waves; cost ≈ $X (session delta). Run /scrutinize for review."
Cost clause: only with a reading at start and end, from ~/.claude/magician/status/${CLAUDE_SESSION_ID}.cost (status line) or the mods band's $.session.usage(). Report the difference. Omit the clause otherwise. Never estimate it.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

