agentleFS
ariaxhanariaxhan/kernel-claude/skills/orchestration/SKILL.md

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

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

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

  • stablyaiSkill

    orca-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-hubSkill

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

  • kongyo2Skill

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

  • AnthropicSkill

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

  • GoogleSkill

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

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
  1. Distinctive:

    Every spawned lane gets ALL of these fields.

    line 21
  2. Very specific:

    No two concurrent lanes may overlap.

    line 25
  3. Distinctive:

    When killing a stuck session, kill its whole process pool, not just the visible pid.

    line 75
  4. Very specific:

    NEVER use git worktrees (isolation: "worktree", git worktree add): the operator forbids them and they have never produced merged work here.

    line 101

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

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<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:

  1. Deliverable: the observable artifact, named exactly (file path, PR, report).
  2. Read-first list: the files/docs the lane must read before acting.
  3. 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}
  4. Known traps, restated: gotchas relevant to this lane, inlined, not linked.
  5. Verification loop with exact commands: the literal commands the lane runs to prove its own work (test invocation, grep, curl), plus expected output.
  6. Forbidden list: what the lane must NOT do (push, touch _meta/, add deps, ...).
  7. Raw-data return format: counts, file lists, command output. Never narrative alone; a lane that returns only prose has returned nothing checkable.
  8. 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>

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

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.