agentleFS
epicsagasepicsagas/epic-harness/skills/orchestrate/SKILL.md

orchestrate

Skill20 starsChanged 2 months agoApache-2.0View on GitHub

Trigger: active multi-agent run. Handles inbox reading, dep resolution, message formatting, handoffs. Also provides status dashboard and intervention control via internal modes.

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

  • xfstudioSkill

    reverse-engineer

    Expert reverse engineer specializing in binary analysis,

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 144 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 14

    Very specific

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

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

    CRITICAL: Run HARNESS_DIR=$(epic-harness path) first.

    line 12
  2. Distinctive:

    If no active run, this skill does not apply — return

    line 21
  3. Distinctive:

    If a directive targets this agent (or "all"), act on it:

    line 31
  4. Distinctive:

    cancel: stop immediately, set status to "cancelled"

    line 33
  5. Very specific:

    After acting on a directive, increment generation in control.json to acknowledge

    line 36
  6. Very specific:

    Read $HARNESS_DIR/orchestrator/run.json dependency graph

    line 39
  7. Very specific:

    Read their status.json — if any dependency is not DONE, wait

    line 41
  8. Distinctive:

    If all dependencies are DONE, proceed with task

    line 42
  9. Distinctive:

    No manual progress reporting needed — the hook handles it

    line 48
  10. Distinctive:

    When task is complete:

    line 51
  11. Distinctive:

    If results should be shared with specific agents, include in the output summary

    line 54
  12. Very specific:

    Read-only view of the current orchestration run.

    line 60
  13. Very specific:

    Check if $HARNESS_DIR/orchestrator/run.json exists

    line 64
  14. Distinctive:

    If the file does not exist, output:

    line 65
  15. Very specific:

    If status is not "running", output:

    line 67
  16. Very specific:

    If status is "running", proceed to Step 2.

    line 69
  17. Very specific:

    Read agent status from $HARNESS_DIR/orchestrator/agents/{id}/status.json (mark unknown if missing)

    line 75
  18. Very specific:

    Read the last 5 events from $HARNESS_DIR/orchestrator/agents/{id}/stream.jsonl (show "no events yet" if missing)

    line 76
  19. Very specific:

    Read the dependency graph from run.json.dependencies

    line 81
  20. Very specific:

    Read edges from run.json.dependencies (format: {"agent_a": ["agent_b", "agent_c"]})

    line 112
  21. Distinctive:

    If no dependencies exist, output: "No inter-agent dependencies."

    line 114
  22. Distinctive:

    If changes exist, append:

    line 127
  23. Very specific:

    Write control directives that the orchestrate hook reads on the next agent tool call.

    line 141
  24. Distinctive:

    If no active run (status != "running"), output: "No active orchestration to intervene in."

    line 146
  25. Distinctive:

    If the user provides no arguments, ask which action and target they want.

    line 159
  26. Very specific:

    Read current generation from $HARNESS_DIR/orchestrator/control.json (or 0 if file doesn't exist).

    line 165
  27. Distinctive:

    When agents need to communicate (via SendMessage or future inbox/outbox):

    line 206
  28. Distinctive:

    Not reporting BLOCKED state when stuck

    line 241

“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

Skill: Orchestrate

CRITICAL: Run HARNESS_DIR=$(epic-harness path) first. NEVER use .harness/ in the project directory.

Mode: auto (default)

Triggered automatically when an active multi-agent orchestration is detected.

Step 1: Check orchestration state

  1. Run HARNESS_DIR=$(epic-harness path)
  2. Read $HARNESS_DIR/orchestrator/run.json
  3. If no active run, this skill does not apply — return

Step 2: Read agent inbox

  1. Read $HARNESS_DIR/orchestrator/agents/{my_id}/inbox.jsonl
  2. Process any pending messages from other agents or user interventions
  3. Messages from other agents: integrate into current task context
  4. Messages from user (via intervene redirect): adjust task accordingly

Step 3: Check control directives

  1. Read $HARNESS_DIR/orchestrator/control.json
  2. If a directive targets this agent (or "all"), act on it:
    • pause: halt work after current tool call, wait for resume
    • cancel: stop immediately, set status to "cancelled"
    • redirect: adopt the new instruction, discard current task
    • resume: resume from paused state
  3. After acting on a directive, increment generation in control.json to acknowledge

Step 4: Check dependencies

  1. Read $HARNESS_DIR/orchestrator/run.json dependency graph
  2. Identify which agents this agent depends on
  3. Read their status.json — if any dependency is not DONE, wait
  4. If all dependencies are DONE, proceed with task

Step 5: Execute with progress reporting

While working on the assigned task:

  1. The Rust orchestrate hook automatically appends events to stream.jsonl on each tool call
  2. Status updates happen automatically via the hook
  3. No manual progress reporting needed — the hook handles it

Step 6: Complete and hand off

When task is complete:

  1. Report status via structured output format (DONE/DONE_WITH_CONCERNS/BLOCKED/NEEDS_CONTEXT)
  2. The orchestrate hook will evaluate dependencies and notify downstream agents
  3. If results should be shared with specific agents, include in the output summary

Mode: status — Orchestration Dashboard

Read-only view of the current orchestration run. Displayed when user runs /status or asks about orchestration state.

Step 1: Check orchestration state

  1. Check if $HARNESS_DIR/orchestrator/run.json exists
  2. If the file does not exist, output:

    No active orchestration. Run /go or /orbit to start.

  3. If status is not "running", output:

    Last orchestration ended with status: {status}. No active run.

  4. If status is "running", proceed to Step 2.

Step 2: Read all agent states

Extract the agent list from run.json.agents. For each agent {id}:

  1. Read agent status from $HARNESS_DIR/orchestrator/agents/{id}/status.json (mark unknown if missing)
  2. Read the last 5 events from $HARNESS_DIR/orchestrator/agents/{id}/stream.jsonl (show "no events yet" if missing)
  3. Calculate elapsed time:
    • started_at set, completed_at not set: elapsed = now - started_at
    • Both set: elapsed = completed_at - started_at
    • Format as Xm Ys or Xh Ym
  4. Read the dependency graph from run.json.dependencies

Step 3: Render dashboard

Output a formatted dashboard (keep total under 30 lines):

## Orchestration Dashboard

- **Run ID**: {run.id}
- **Status**: {run.status}
- **Elapsed**: {total_elapsed since run.started_at}
- **Agents**: {count where status=running} / {total} active

| Agent | Role | Status | Elapsed | Last Event |
|-------|------|--------|---------|------------|
| {id} | {role} | {status} | {elapsed} | {summary of last event} |

### Dependency Graph
{render with ASCII arrows, e.g.:}
  builder ──→ reviewer ──→ integrator
  builder ──→ tester

### Recent Events (last 5 across all agents)
- [{timestamp}] {agent_id}: {event_summary}

### User Interventions
{read control.json; show directives if any, else "none"}

Dependency graph rendering rules:

  • Read edges from run.json.dependencies (format: {"agent_a": ["agent_b", "agent_c"]})
  • Render using ──→ arrows
  • If no dependencies exist, output: "No inter-agent dependencies."

Event summary formatting:

  • Each event is one line from stream.jsonl with fields: timestamp, type, message
  • Summarize message to at most 60 characters
  • Sort by timestamp descending, take top 5

Step 4: Optional — file change summary

git diff --stat

If changes exist, append:

### File Changes
- {count} files modified ({insertions} insertions, {deletions} deletions)
- Key changes: {list up to 5 file paths}

Note: This mode is read-only — never modify orchestration state.


Mode: intervene — Agent Intervention

Write control directives that the orchestrate hook reads on the next agent tool call. Triggered when user runs /intervene.

Step 1: Check active orchestration

  1. Read $HARNESS_DIR/orchestrator/run.json
  2. If no active run (status != "running"), output: "No active orchestration to intervene in."
  3. Show current agent list with statuses

Step 2: Parse user command

Invocation format:

  • intervene pause {agent_id} — pause a specific agent (blocks next tool call)
  • intervene pause all — pause all agents
  • intervene cancel {agent_id} — cancel a specific agent
  • intervene cancel all — cancel entire orchestration
  • intervene redirect {agent_id} {new_instruction} — change what an agent is doing
  • intervene resume {agent_id} — resume a paused agent

If the user provides no arguments, ask which action and target they want.

Validate the agent_id against the agent list in run.json. If not found, output: "Agent '{agent_id}' not found in active orchestration. Available agents: {list}" and stop.

Step 3: Write control directive

Read current generation from $HARNESS_DIR/orchestrator/control.json (or 0 if file doesn't exist). Increment by 1.

Write to $HARNESS_DIR/orchestrator/control.json:

{
  "action": "pause|cancel|redirect|resume",
  "target": "agent_id or 'all'",
  "message": "optional user message",
  "generation": <current_generation + 1>
}

For redirect, the message field contains the new instruction. For pause/cancel, the message field is optional — use an empty string if none provided. For resume, set action to "resume" and target to the agent_id.

Additional actions by type:

  • cancel all: Also update $HARNESS_DIR/orchestrator/run.json status to "aborted"
  • redirect: Also append the new instruction to the target agent's $HARNESS_DIR/orchestrator/inbox/{agent_id}.jsonl as a new line: {"type": "redirect", "instruction": "{new_instruction}", "at": "{ISO-8601}"}
  • cancel {agent_id}: Also update the agent's status in run.json to "cancelled"

Step 4: Confirm

Output confirmation:

Intervention recorded: {action} {target}
The {target} agent will respond on its next tool call.
Use /status to monitor.

Notes:

  • Multiple interventions can be queued (generation number increases each time)
  • The orchestrate hook checks control.json before every agent tool call, so interventions take effect within one tool call cycle
  • "cancel all" is destructive — confirm with the user before executing
  • "redirect" requires a new instruction — if none is provided, ask the user

Message Format Convention

When agents need to communicate (via SendMessage or future inbox/outbox):

{
  "from": "agent_id",
  "to": "agent_id",
  "type": "handoff|question|blocked|result",
  "body": "message content",
  "timestamp": "ISO-8601"
}

Anti-Rationalization

ExcuseRebuttalWhat to do instead
"I'll just work independently"Orchestration exists to prevent conflicts and duplicationCheck dependencies first, report status
"Progress reporting slows me down"The hook does it automatically on every tool callNo manual action needed
"I'll read all agents' state"Only read your own inbox and dependenciesRespect isolation boundaries
"I'll intervene directly in agent files"Direct file edits bypass the generation protocolAlways write to control.json
"I'll skip the status check"Stale state leads to incorrect interventionsAlways read run.json first

Evidence Required

  • Inbox checked before starting work
  • Control directives checked (auto mode)
  • Dependencies verified (all upstream agents DONE)
  • Structured output format used for completion report
  • Dashboard shows all agent states accurately (status mode)
  • Intervention written to control.json with incremented generation (intervene mode)

Red Flags

  • Starting work before dependencies are met
  • Ignoring inbox messages from other agents
  • Not reporting BLOCKED state when stuck
  • Modifying orchestration state in status mode (read-only)
  • Cancelling all agents without user confirmation
  • Redirecting an agent without a concrete new instruction
  • Writing to control.json when run.json status is "aborted" or "complete"
  • Intervening without an active orchestration (check run.json first)
  • Showing raw JSON instead of a formatted dashboard (status mode)

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.