orchestration
Skill15 starsChanged 4 months agoMITView on GitHub
Multi-agent orchestration: lane contracts, worker-model doctrine, fault tolerance. Triggers: orchestrate, coordinate, agents, parallel, spawn, contract, tier 2, tier 3.
47 other projects use a version of this.
Adopted by
Most recently taken up by
- MMACABRE/SKILLStheir own version, first seen Nov 8, 2026
- Hive-Academy/PtahCodetheir own version, first seen Nov 8, 2026
- delorenj/skillstheir own version, first seen Nov 7, 2026
- Hive-Academy/ptah-extensiontheir own version, first seen Nov 3, 2026
- webdevarif/claude-skillstheir own version, first seen Nov 1, 2026
- jgeofil/agent-skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use orca-cli, orca-per-workspace-env 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.
HK-hubSkillorca-cli
Use the public `orca` CLI to operate Orca-managed worktrees, folder contexts, terminals, repos, automations, artifacts, worktree comments, and the browser embedded inside the Orca app. Use when the user says "$orca-cli", "use orca cli", "Orca worktree", "child worktree", "cardStatus", "spawn codex/claude in a worktree", "read/wait/send Orca terminal", "terminal send", "full handoff", "handover", "give this to another agent", "another worktree", "Orca browser", "orca artifacts", "share HTML/Markdown", "public artifact link", or "control the browser inside Orca". Prefer this over raw `git worktree`, ad hoc PTYs, Playwright, or Computer Use when the task touches Orca-managed state. Use Computer Use for browser windows, webviews, or desktop UI outside Orca's embedded browser.
Also in 5 projects that use this
stablyaiSkillorca-per-workspace-env
Set up, review, debug, or validate an Orca per-workspace environment recipe: the on-demand, disposable runtime (cloud sandbox, VM, SSH host, or local container) Orca creates fresh for each workspace. Use to stand up a new recipe end to end, fix an `environmentRecipes` entry in `orca.yaml`, scaffold provider lifecycle scripts, or resolve an `orca vm recipe doctor` failure. Use `orca-cli` for ordinary worktree and workspace creation with no recipe involved.
Also in 3 projects that use this
HK-hubSkillcomputer-use
Use Orca's computer-use CLI to inspect and operate local desktop app windows through accessibility trees, screenshots, and safe UI actions. Use for desktop app interaction: list apps/windows, get app state, read visible UI, click controls, type, press keys, scroll, drag, set values, or perform accessibility actions. Also use for browser windows, webviews, Orca app UI, or other desktop UI. Triggers include "computer use", "orca computer", "read Spotify", "read Slack", "control/click/read in a desktop app", and "get app state".
Also in 6 projects that use this
kongyo2Skillprompt-engineering
Comprehensive prompt engineering framework for designing, optimizing, and iterating LLM prompts. This skill should be used when users request prompt creation, optimization, or improvement for any LLM task, or when users need help translating vague requirements into effective prompts through collaborative dialogue and iterative refinement.
Also in 3 projects that use this
AnthropicSkillwrap-up
Close out (or revisit) a Claude Managed Agent build — refresh the overview page, recap every primitive the founder now owns, show the run log and live status, suggest 1–2 tailored next upgrades, and sweep hygiene (sessions archived, key only in .env, no literal dates in deployment kickoffs). Use when the founder says "/wrap-up", "wrap up", "close it out", "where do things stand with my agent", or at the end of a /launch-your-agent build.
Also in 3 projects that use this
GoogleSkillcodebase-design
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Also in 4 projects that use this
Other versions47 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 47
- stablyai/orca★ 119ksame name
- BankrBot/openclaw-skills★ 1.2ksame name
- BankrBot/skills★ 1.2ksame name
- AThevon/genjutsu★ 758same name
- moasq/production-saas-starter★ 532same name
- bam-bam-2/solo-skills★ 366same name
- austintgriffith/ethskills★ 303same name
- PaulRBerg/agent-skills★ 104same name
- geekatron/jerry★ 37same name
- Hive-Academy/ptah-extension★ 34same name
37 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 repository30 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- app-devSkill
- architectureSkill
- buildSkill
- checkpointSkill
- context-mgmtSkill
- debugSkill
- dreamSkill
- evalSkill
- experimentSkill
- forgeSkill
- frontendSkill
- governance-syncSkill
- handoffSkill
- helpSkill
- human-passSkill
- ingestSkill
- initSkill
- knowledge-graphSkill
- landing-pageSkill
- marketing-siteSkill
- metricsSkill
- qualitySkill
- retrospectiveSkill
- reviewSkill
- shipSkill
- simplifySkill
- tearitapartSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 42 edited versions we read keep these.
2
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
- Distinctive: line 21
Every spawned lane gets ALL of these fields.
- Very specific: line 25
No two concurrent lanes may overlap.
- Distinctive: line 75
When killing a stuck session, kill its whole process pool, not just the visible pid.
- Very specific: line 101
NEVER use git worktrees (isolation: "worktree", git worktree add): the operator forbids them and they have never produced merged work here.
“Common” is measured: kept by at least 6 in 10 of the 42 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
<skill id="orchestration"><purpose>
Orchestration is coordination, not implementation. You define contracts, agents
execute, AgentDB is the bus. Never assume completion without reading the file.
Reference on demand: skills/orchestration/reference/orchestration-research.md.
</purpose><lane_contract> Every spawned lane gets ALL of these fields; a missing field is where the lane fails:
- Deliverable: the observable artifact, named exactly (file path, PR, report).
- Read-first list: the files/docs the lane must read before acting.
- Files table: exhaustive list of files it may touch (
constraints.files). No two concurrent lanes may overlap. Contract JSON:{"goal":"X","constraints":{"files":["a.sh","b.md"]},"tier":2} - Known traps, restated: gotchas relevant to this lane, inlined, not linked.
- Verification loop with exact commands: the literal commands the lane runs to prove its own work (test invocation, grep, curl), plus expected output.
- Forbidden list: what the lane must NOT do (push, touch _meta/, add deps, ...).
- Raw-data return format: counts, file lists, command output. Never narrative alone; a lane that returns only prose has returned nothing checkable.
- Capabilities needed from outside the runtime: none | browser | isolated-chromium | gui | keychain | ssh | api:vendor | interactive. A lane that needs a capability the sandbox denies fails deep into the work, having already spent the budget.
The prompt must stand alone in a fresh session with no conversation history: no "as discussed", no reference to a target that exists only in your context, no compressed shorthand only this session can expand. Read it as if you had just booted. Pass it by FILE PATH once it is large; an inline prompt over a few hundred KB dies on the subprocess argv limit (E2BIG), and the failure looks like a crash, not a size error. </lane_contract>
<output_integrity> Structured long-report lanes degrade silently to placeholders under load. Validate every lane return mechanically before using it: minimum-length check on required sections, placeholder detection ("TBD", "...", repeated boilerplate), counts match the claimed work. Reject-and-retry a degraded return; never synthesize over it. Pass large input pools to lanes by FILE PATH, never as an inline slice (silent truncation reads as full coverage). Each lane keeps a per-lane journal/checkpoint so a degraded final message is not the only record of what it did. </output_integrity>
<frozen_inputs> Freeze the exact bytes a review lane judges before dispatching it. A concurrent lane correcting the same artifact mid-review destroys the review: it now reports on a version that no longer exists, and the finding cannot be reproduced or dismissed. Snapshot the input to a path the reviewer reads, record its hash in the contract, and re-check the hash when the verdict lands. If the source moved, the verdict is void, not stale. </frozen_inputs>
<shared_resources> Any id, lock, slot, or row a runner allocates for lanes is contended the moment two lanes start. Allocate atomically (a real transaction, O_EXCL that is checked, a database constraint), then READ BACK what you got and fail loudly if it is empty. Exit 0 with a blank id is the signature of a lost race, and it produces a malformed record that outlives the run. An O_EXCL lock created during initialization admits a second owner unless the initialization itself is inside the lock. </shared_resources>
<single_coordinator> One coordinator per repo at a time. Before coordinating, check for a live second session on the same working directory (stale sessions can survive as background daemons and produce split-brain: two coordinators mutating one repo in parallel). When killing a stuck session, kill its whole process pool, not just the visible pid. </single_coordinator>
<worker_model_doctrine>
Select model and effort from the lane's task shape and measured evidence, never from
role prestige. Mechanical total-spec execution with deterministic checks can use the
lowest setting proven adequate. Ambiguous judgment or a measured miss justifies more
effort; protected work requires a fresh independent verifier. The lane contract records
the requested model and effort, whether inheritance is intentional, and the escalation
condition. A prompt that says "use your judgment" is evidence of ambiguity, not a license
to choose a prestige model by role. Receipts keep requested_model and requested_effort
separate from observed_model and observed_effort. Unsupported or unexposed values are
unavailable, never inferred. Protected receipts require distinct builder_identity and
verifier_identity; the builder never grades its own protected work. The coordinator
reproduces acceptance evidence.
</worker_model_doctrine>
<fault_tolerance>
- RETRY transient failures with backoff, max 3. 2. CLASSIFY the failure before choosing recovery. 3. Never silently substitute model, effort, or provider. Use an alternative only when the contract names a pre-authorized fallback; record the original request, the failure, and the observed fallback identity separately. Otherwise stop and re-contract. 4. CHECKPOINT state to AgentDB at every boundary so a respawn resumes instead of restarting. </fault_tolerance>
<lane_safety>
NEVER use git worktrees (isolation: "worktree", git worktree add): the operator forbids them
and they have never produced merged work here. Parallel lanes (tier 2+) share the live checkout
and are made safe by file-disjointness: each lane's constraints.files is disjoint from all active
lanes, and a lane stages only its own paths by name. Post-agent validation: read the lane's
checkpoint, then git diff --name-only over the lane's commits; every changed file MUST appear in
constraints.files, and an out-of-scope file means reject, revert that path, re-contract.
Work that cannot be made file-disjoint runs sequentially.
</lane_safety>
<knowledge_injection>
Inject context BEFORE spawn, never let lanes discover it at runtime: build the slice
with agentdb inject-context <agent_type> and inline it in the prompt (surgeon gets
gotchas + patterns + contract; adversary/reviewer get past failures + recent errors;
researcher gets domain learnings). The orchestrator owns injection. Every agent
boundary is lossy compression: structured briefing in, structured checkpoint out;
never rely on conversation history across agents.
</knowledge_injection>
<anti_patterns>
Holding context in memory instead of AgentDB · assuming a lane finished without
reading the deliverable file (receipts describe intent; files describe reality) ·
parallel lanes touching shared files (N-way merge conflicts) · serial execution when
parallel is genuinely safe · retrying without new information from the failure ·
autonomous loops without a budget cap (max_budget_usd on the contract) ·
accepting a lane return without the output-integrity check (placeholder degradation
is silent) · two coordinators on one repo · dispatching a review over bytes another lane
is still editing · a prompt that only makes sense inside the dispatching session.
</anti_patterns>
</skill>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.

