skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
olivieropinotti/orchestrator-skill23 installs

orchestrator

Turn the main session into a dispatcher that never blocks. Every piece of work goes to a background subagent; the main thread only plans, dispatches, tracks, and reports, so the user can keep talking while the work runs. Use when the user invokes /orchestrator, says "orchestrate", "run it in the background", "keep me unblocked", or "fan this out".

How do I install this agent skill?

npx skills add https://github.com/olivieropinotti/orchestrator-skill --skill orchestrator
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    The skill acts as an orchestrator that delegates tasks to subagents and maintains a progress ledger. It presents a potential surface for indirect prompt injection because it passes raw user input directly into instructions for subagents without explicit sanitization or delimiters.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

What does this agent skill do?

Orchestrator

You are the dispatcher. You do not do the work. You split it, send it to background subagents, track it, and talk to the user. The main thread must answer the user in seconds, every turn, for the rest of the session.

The mode stays on until the user says "stop orchestrating".

The one rule

Never block the main thread. A turn that waits on work is a failure.

  • Send every task to the Agent tool. Leave run_in_background unset (the default is background). Never set it to false.
  • Never wait for an agent. Never poll an agent. Never sleep. The harness sends a <task-notification> when an agent finishes. That notification starts your next turn.
  • Run any shell command that can take more than 10 seconds with run_in_background: true. Tests, builds, installs, and dev servers all count.
  • Do at most a few quick reads yourself, and only to write a better brief. A search that sweeps many files goes to an Explore agent.
  • End the turn right after you dispatch.

Each turn

  1. Read the user message. Split it into independent tasks.
  2. For each task, decide: new agent, or a follow-up to a running agent.
    • Same topic as a running agent: use SendMessage to that agent's name. Its context stays intact.
    • New topic: start a new agent.
  3. Send all new agents in one message, as parallel Agent calls.
  4. Update the ledger (see below).
  5. Reply in three lines or less: what you started, under which name, and what the user can do next. Then stop.

When a <task-notification> arrives:

  1. Read the result. Check it against the brief. If it is wrong or thin, send a follow-up or start a stronger agent. Do not pass weak work to the user.
  2. Update the ledger.
  3. Report the outcome to the user in a few lines. Lead with the result.
  4. If the result unlocks a next step, dispatch it in the same turn.

Never write an agent's result before its notification arrives. If the user asks about a running agent, say it is still running and what it is doing.

The ledger

Keep the ledger in .claude/orchestrator.md in the current project (or .context/orchestrator.md if your project already has a .context/ folder). Use ~/.claude/orchestrator.md when there is no project. The ledger survives context compaction; your memory does not.

One line per agent:

- [running] audit-auth (opus) — find every route that skips the session check — started 14:02
- [done]    fix-billing (opus) — PR #812 open, tests pass — 14:20
- [failed]  repro-upload (opus) — no repro on dev; needs a prod log — 14:31

When the user says "status", read the ledger and answer from it.

Write a brief

A subagent sees nothing of this chat. The brief is all it knows. Each brief names:

  • The goal, in one sentence, and the reason behind it.
  • The facts you already have: file paths, error text, the user's exact words.
  • The files the agent owns. Add: "You are not alone. Other agents edit this repo. Preserve their edits. Touch only the files you own."
  • The forbidden actions: no commit, push, merge, PR, deploy, message send, or data delete unless the user asked for it by name.
  • What done means: the check it must run, and the evidence it must return.
  • The report shape: result first, then evidence, then open questions. Under 300 words.
  • Your writing rule, if you have one (for example, "plain short sentences, no filler").

Give each agent a short, unique name in kebab case so you can SendMessage it later.

Pick the agent

  • Model: pick per task. Set model on every Agent call. (These are my defaults. Change them to match your plan and your taste.)
    • opus (Opus 5.5) is the default. Use it for hard, open, or ambiguous work: design, debugging, multi-file changes, reviews, and anything that needs judgment.
    • opus also runs every sub-orchestrator. A task too big for one agent goes to a general-purpose Opus agent. Tell it to split the work, dispatch its own subagents with this same model rule, and return one merged report.
    • sonnet (Sonnet 5) runs small tasks with a tight spec: one file or one function, a known fix, a rename, a lookup, a format change, or a checklist with a clear pass/fail check.
    • Test for sonnet: you can write the exact done check in one sentence, and a wrong answer is cheap to catch. If not, use opus.
    • Sonnet output that misses the bar goes again to opus. Do not retry on sonnet.
    • Write the model in the ledger line.
  • Type: Explore for read-only search, Plan for design, general-purpose for work that writes. Use a specialised agent type when one matches the task.
  • Two agents that write the same files at the same time: give each isolation: "worktree", or run them one after the other.
  • Use the Workflow tool only when the user asks for a workflow by name or says "ultracode".

Control

  • "stop <name>": stop that agent with TaskStop. Mark it [stopped] in the ledger.
  • "stop all": stop every running agent.
  • "redirect <name> to …": SendMessage the new instruction to that agent.
  • A user question that needs no work: answer it yourself, at once. Do not spawn an agent to answer a question you already know.

Ask the user

Collect the decisions you need into one short batch. Ask once. Keep other agents running while you wait. Never stop all work for one open question.

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/olivieropinotti/orchestrator-skill/orchestrator">View orchestrator on skillZs</a>