agentleFS
boshu2boshu2/agentops/skills/orchestrate/SKILL.md

orchestrate

Skill453 starsChanged 4 months agoApache-2.0View on GitHub

Coordinate several workers: what idle agents do next, which finished work gets checked first, how to recover a dead one. Use when: managing multiple agents.

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

  • ranchengSkill

    codex-imagegen

    Generate or edit images by invoking OpenAI's gpt-image-2 ("image 2") through headless `codex exec`. Trigger when the user asks to create, generate, draw, design, or edit an image, logo, icon, illustration, banner, sprite sheet, placeholder art, or any visual asset — and they have not specified a different generator (Stable Diffusion, Midjourney, DALL·E API directly, etc.). Also use when the user wants to transform or extend a reference image they have provided locally.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 144 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read acceptance, examples, scope, settled choices and open questions from their owner and the existing native handoff, without repeating …

    line 56
  2. Distinctive:

    When several workers apply one set of decisions, such as a batch of review findings or one rewrite that must read the same in many files, …

    line 101
  3. Distinctive:

    When maintained context could change the next action, use Memory find/recall.

    line 161
  4. Distinctive:

    When the caller asks for coordination status, return this shape.

    line 172

“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

Coordinate caller-authorized work through its existing tracker and runtime; a clear task needs zero mandatory skills. The tracker owns assignments and dependencies, the runtime owns running contexts and bounds, and repository policy owns integration and delivery. Orchestrate decides what each worker does next. Agent Native launches and observes workers; Navigate picks the wave on a bead graph toward frozen acceptance and records verdicts.

Before any dispatch

  • Finished is not done. Exit 0, a pushed branch, a closed tracker item or a worker saying "done" makes a candidate. It still owes its checks, integration and, when one is owed, a fresh judgment.
  • Drain before starting. While candidates wait on checks, repair, integration or an owed judgment, free capacity goes there first: candidates that unblock held dependents, then the oldest. A free slot alone is not a dispatch reason; start new implementation with what is left.
  • Judges did not author. Review or validation of a candidate goes to a context that did not write it.
  • Readiness is content. A prerequisite counts only when its bytes are in the intended checkout. A closed item whose change is missing, stale or unavailable there is not ready: hold its dependents, keep its native status, and report the gap.
  • Reconcile before resuming. Match tracker assignments against observed runtime state, validators included, before dispatching. Never duplicate an assignment because this conversation lacks it.
  • Decisions are not build work. A decision item goes to the resolver it names (Navigate), never to an implementer; with BD, pull build work with bd ready --exclude-type decision.

Recover the actual work

Read acceptance, examples, scope, settled choices and open questions from their owner and the existing native handoff, without repeating settled interviews or requiring the full transcript; a missing or contradictory pointer needs source investigation, not a guess. For each task, check who holds it, its workspace and starting content, the write scope it occupies, pending checks and review, the current candidate, who integrates it, and whether each prerequisite's content is present. An empty ready list does not prove completion (Navigate).

Choose the next useful dispatch

Concurrency follows the observed bottleneck. Reserve capacity for integration, review and repair, and reduce new starts while candidates accumulate. Record only the concrete constraint and next action in the existing native handoff, then reassess when evidence changes. Do not add a capacity ledger or queue.

Agent Native owns runtime mechanics, disjoint write scopes and isolation; one-shot headless runs go through Codex Exec, Claude Exec or AGY Native. Serialize shared paths, generated companions included. A worktree separates Git edits; it does not enforce restricted-source or model-egress limits (model dispatch).

Dispatch a genuinely fresh implementer for one coherent accepted task, without the coordinator's transcript or unrelated research: use the runtime's task-only dispatch, since a short prompt in a forked session still carries the history (RPI). A new goal, role label, cleared summary or resumed author context is not fresh. Pass the accepted examples, applicable constraints, exact starting content, usable prerequisites, authorized write/output scope, source pointers, required checks, integration responsibility and real remaining bounds; brevity cannot omit a constraint. A pointer counts only if the worker can open it: a link relative to a skill's own folder, or a file outside the worker's workspace, does not resolve there, so pass a path it can read or paste the rule itself. Record the worker's observed identity at startup through Agent Native's association procedure.

Implement owns the complete change, meaningful checks and direct repair; it is optional guidance for that worker, not a compulsory stage. The handoff returns candidate identity, changed scope, check facts, discoveries and gaps; prompt delivery proves neither engagement (Agent Native) nor acceptance.

When several workers apply one set of decisions, such as a batch of review findings or one rewrite that must read the same in many files, make each decision once in one context and send workers only what was decided. A worker returns an uncovered case, or a blocker with evidence the decider could not see, instead of improvising or reopening the decision; the decider settles it and never drops it. Decide once, apply in parallel covers both shapes.

Integrate and obtain judgment

Name the integration responsibility before launch, and decide then whether the integrated candidate needs a fresh judgment at all. Follow the consumer repository's integration policy, include all changed paths and generated companions, and run affected checks on the actual integrated subject. Acceptance of a leaf does not establish the combined release. Within that policy, combine parallel results one at a time in dependency order and run the affected checks after each, so a failure points at one result; a merge without conflicts does not show that two changes work together. A result that conflicts, or whose own changed paths or prerequisites changed on the target after it started, goes back to its author through a follow-up that authorizes that update (Agent Native), or is redone from the current target, and reruns its checks; it is not merged blind. A write outside a worker's declared scope, or collisions that keep recurring, show the scope split cannot be trusted for this change: finish the rest serially.

For an ordinary candidate the integrated checks and CI are the gate; assign one fresh author-distinct judgment only in the costly cases Validate names, and Validate owns the single round, what counts as a finding, and when a repair needs only its checks rerun. Preserve every explicitly required review leg; advisory Review, Plan challenge and Council advice cannot stand in for a judgment the caller requested (advice or acceptance).

Reconcile feedback and resume

Preserve successful and failed evidence in the existing native task or handoff, and update affected unfinished work's native dependencies or handoff within authority. Stop or explicitly re-scope an affected active assignment before it continues on a disproven premise; the revision takes effect only on observable acknowledgment or stopped runtime state. Unaffected work continues unchanged; reconciling unchanged facts creates no new artifact or dispatch.

Plan owns consequential uncertainty and refining the next slice. New evidence may change an approach within the accepted outcome; a different promised outcome or authority choice returns to the caller, never to agent advice. Do not reopen accepted work to fit a revised story.

Known failures return to the responsible task for direct repair; a genuine causal stall gets RPI's one bounded helper, and replacement workers, retries, new subjects and compaction never reset its bounds. Use native waits for unchanged pending state instead of repeated analysis or probes.

To recover a dead worker, confirm its process stopped, not only its pane; capture its state and preserve its partial work recoverably; move its tracker assignment to the replacement rather than filing a duplicate; and start the fresh worker from that branch as exact starting content while dependents hold.

When maintained context could change the next action, use Memory find/recall.

A caller-selected external factory keeps its coordinator in control: hand it source intent through its supported door, never run its sessions by hand or mirror its work in a second tracker, and judge the returned content independently; its completion neither authorizes delivery nor establishes acceptance. For Gas City, follow Using GC.

Status block

When the caller asks for coordination status, return this shape; answer a quick question in prose. No other report or persisted artifact is required unless an existing consumer needs one.

assignments: <worker/context id> -> <task>, state as observed (how); last activity <time, kind> | unobserved
candidates:  <task> -> <exact ref>; checks <result>; judgment <ref | owed | not owed>
next:        <free capacity> -> <dispatch>, because <observed bottleneck>
held:        <task>, blocked by <prerequisite gap>
handoffs:    <affected work updated, and where>
gaps:        <unobserved state, unknown identities, unresolved dissent>

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.