agentleFS
alexratmanplalexratmanpl/business-agent-skills/skills/engineering/orchestrate/SKILL.md

orchestrate

Skill1 starsChanged 2 months agoMITView on GitHub

Run a project as a LEAD session that spawns short, budget-capped Claude Code cloud worker sessions (research, plan, build, review), merges their branches, answers their questions and respawns successors on budget exhaustion. Use when asked to "orchestrate", "run project <name>", or to work a BRIEF.md unattended on a subscription.

161 other projects use a version of this.

Adopted by

Most recently taken up by

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-erSkill

    define-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

  • EternallLightSkill

    orchestrate-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-erSkill

    record-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

  • PinkneyJiangSkill

    improve-architecture

    扫描代码库中的架构摩擦点,识别浅模块并挖掘深模块演进机会。生成可视化交互式 HTML 诊断报告,并在用户确认后闭环实施深度重构。

    Also in 4 projects that use this

  • kjnezSkill

    ticket

    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

  • xfstudioSkill

    reverse-engineer

    Expert reverse engineer specializing in binary analysis,

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 144 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the repo's CLAUDE.md/AGENTS.md once.

    line 22
  2. Very specific:

    Only at CLOSE, on ESCALATE, or when asked: what shipped, DECISION lines since the last report, open ESCALATE items, sessions spawned and …

    line 77

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

orchestrate: LEAD instructions

You are the LEAD: you talk to the human, workers talk only to you. A worker is one cloud session (mcp__claude-code-remote__create_session) per task on its own branch. State lives in git under projects/<project>/ (paths below are relative to it unless they start with .claude/ or .orch/) so any lead can take over. Read references/ and assets/ (fixed formats, never reshaped) at the step that needs them.

0. Start / resume

  1. BRIEF.md must match assets/BRIEF.md; missing → write it with the human from their free text.
  2. board/BOARD.md exists → resuming: read BOARD, the last 40 LOG lines, and board/LEAD-HANDOVER.md if present; else create BOARD and LOG from the templates. Then, before anything else, put your session id (get_session, no id) in the BOARD header: stale headers get live leads archived.
  3. Read the repo's CLAUDE.md/AGENTS.md once; its rules and skill names go into every card's RULES and SKILLS fields.
  4. Target repo setup per spawn.md "Target repo setup"; missing → add, commit, push on the lead branch before the first spawn: workers get only what is committed.
  5. Set your own ceiling: mkdir -p .orch && echo 350000 > .orch/ceiling.
  6. Preflight per spawn.md "Preflight" before any spawn. Host denied → LOG ESCALATE now with the allowlist steps; ask the human whether to run search-only with facts flagged (unverified). Skill missing → LOG ESCALATE; human declines → the review is "formally incomplete" (it needs every skill in BRIEF/CLAUDE.md): say so in LOG and the CLOSE report.
  7. Risk: score BRIEF by the rubric in assets/BRIEF.md (one point per signal, ≥3 = high), LOG RISK <n> <signals>. It picks the worker tier column in spawn.md; §2 may raise it, nothing lowers it; you stay on the mid tier. High: after PLAN, send a ≤10-line summary + the PLAN path as ESCALATE; wait for the human before BUILD; DECISIONs that alter the plan or waive a review FAIL go through the advisor first.

1. Loop

RESEARCH → PLAN → BUILD → REVIEW → (FIX → RE-REVIEW)×≤2 → CLOSE. Skip RESEARCH when BRIEF Unspecified is empty. One planner; builders in parallel, ≤4 concurrent. Review is formally incomplete without the skills named in BRIEF/CLAUDE.md. First review and any review after NO-SHIP: full checklist; re-review after a fix: FIX-LIST items and the test command only.

Each bookkeeping event is one Bash call: BOARD, LOG line stamped date -u +%H:%M, commit, push. Spawn per spawn.md "Spawn sequence" (LOG SPAWN; one check-in per wave, deleted on report). Before the first builder spawn LOG BUILD-BASE <sha> (the reviewers' DIFF_BASE).

Archive only sessions in this project's BOARD, each after a fresh get_session shows it not running, never from memory; BRIEF Keep sessions: yes turns archiving off.

CLOSE: spawn.md "Cost accounting" (LOG COST); sweep remaining sessions, LOG ARCHIVE <n>; run retro (roles.md) as a high-tier Agent subagent; commit board/RETRO.md.

2. On worker message (first line is the token)

tokendo
DONE <t>fetch+merge agents/<p>/<t> into the lead branch; conflict → fixer owning the conflicting files; BOARD done + cost (spawn.md "Cost accounting"); LOG DONE; archive_session(<t>). A reviewer's line 2 is the verdict: SHIP / FIX-LIST / NO-SHIP
HANDOVER <t>merge, push; read board/<t>/HANDOVER.md; spawn <t>b (then c, d) per spawn.md "Successor", CARD CONTINUE_FROM, open questions answered in the card; book cost, archive <t>; LOG RESPAWN. Successor cap hit → BOARD partial merged, handle as BLOCKED, name it in the CLOSE report
QUESTION <t>trivial → answer; else advisor (roles.md) as a fresh-context Agent subagent, tier per spawn.md, with the question + BRIEF; send_message(worker, "ANSWER: …"); LOG DECISION
BLOCKED <t>supply the missing input or split the task; reviewer blocked on the test command → spawn.md "Reviewer blocked"; else LOG ESCALATE and tell the human
nothing by check-ininspect per spawn.md "Silent worker", then act as above

Raise RISK when the advisor cannot decide, a task hits its 2nd HANDOVER, or a review says NO-SHIP. Review FAILs: re-verify each yourself before spawning a fixer; waive false alarms with LOG DECISION (high risk: advisor first). One fixer per owning task per round; cross-task items and merge conflicts → one fixer owning the named files (spawn.md fixer row).

3. Budgets and models

Ceiling = context tokens; the hook warns at it and every 20k after. Ceilings, model ids, wave timeouts, card budgeting: spawn.md, read at every spawn.

4. Lead succession

Past ceiling (hook warning): finish the step in hand, hand over per spawn.md "Lead succession", LOG LEAD-SUCCESSION <new id>, tell the human the new session id, stop.

5. Report to the human

Only at CLOSE, on ESCALATE, or when asked: what shipped, DECISION lines since the last report, open ESCALATE items, sessions spawned and archived, the COST line, RETRO's top three. Never forward worker transcripts.

Hard rules

Merge only branches whose task reported DONE or HANDOVER (the latter only seeds the successor). Never edit a worker's files or hand-resolve its conflicts; spawn. Never skip review. Never commit to main: the lead branch is the integration branch, merged by the human. Every DECISION and ESCALATE is a LOG line before anything else happens.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.