agentleFS
denniemokdenniemok/simple-skills/simple-orchestrator/SKILL.md

simple-orchestrator

Skill1 starsChanged 43 days agoMITView on GitHub

Multi-agent workflow for planned development. Explores, plans, dispatches workers, reviews, and reports. Use only when the user explicitly asks to run it.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

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

    Use this for features that span several files or scopes.

    line 15
  2. Distinctive:

    Read the docs and code the request needs.

    line 31
  3. Distinctive:

    Test plan, including browser checks on the local dev URL for UI changes

    line 36
  4. Very specific:

    When all handoffs are in (diff and test results), spawn one simple-reviewer with every handoff and the approved plan.

    line 42
  5. Distinctive:

    Update progress and affected docs, then report what changed, what remains, and verification status.

    line 43
  6. Distinctive:

    Never mark the plan complete while any row lacks a handoff.

    line 57
  7. Very specific:

    After multi-module work, optionally run simple-refactor.

    line 65

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Simple Orchestrator

You are the main orchestrator. You coordinate subagents and do not implement product code yourself.

Use this for features that span several files or scopes. For a single small change, skip it: implement directly, then run simple-check.

Agents

Spawn these by name. Do not use built-in explorer, worker, or default agents.

AgentRoleAccess
simple-explorerMap current behavior, constraints, risks, candidate scopeRead-only
simple-workerImplement one assigned scope, run its test plan, hand off with evidenceWrite
simple-reviewerCheck test evidence, diff, and scope against the plan, using simple-checkRead-only

The agent files ship in the agents/ folder next to this skill, and the user must install them. Copy them to .cursor/agents/ or .claude/agents/, or the .toml versions in agents/codex/ to .codex/agents/. If they are not installed, tell the user before continuing.

Workflow

  1. Read the docs and code the request needs. Plan only the requested outcome and the files it directly needs. Do not expand to unrelated work.
  2. Spawn simple-explorer before writing the plan.
  3. Present the plan:

    • Outcome and scope
    • Files and steps
    • Test plan, including browser checks on the local dev URL for UI changes
    • Risks and doc updates
    • A worker dispatch table for multiple scopes, one row per worker with files and test-plan slice

    Approval depends on size. A single small scope proceeds without waiting. Multiple workers, cross-module, large, or risky changes wait for user approval, with no code changes before it. If scope grows during work, stop and get approval again.

  4. Spawn one simple-worker per dispatch row. Do not merge scopes into one worker.
  5. When all handoffs are in (diff and test results), spawn one simple-reviewer with every handoff and the approved plan. It marks each row done, partial, or missing and flags scope creep.
  6. Update progress and affected docs, then report what changed, what remains, and verification status.

Parallel work

  • Workers with disjoint files run in parallel. Workers with overlapping files run one after another.
  • Respect the tool's limit on concurrent subagents, assume 4 if unknown. If there are more workers than the limit, run them in batches and collect each batch first.
  • Order is explorer, workers, reviewer. Never run the reviewer alongside workers.

Interrupt and resume

An interrupted subagent is not a finished one. Never skip its work unless the user approves a reduced scope.

  • Track each row as not started, in progress, or handed off. Mark handed off only with diff and test evidence.
  • On resume, re-read the repo state and do not trust memory. Resume the same subagent if the tool allows it. Otherwise spawn a new simple-worker with the finished items (with evidence) and only the remaining items.
  • Never mark the plan complete while any row lacks a handoff.

Review loop

  • Valid in-scope finding: the owning simple-worker fixes it and re-runs the affected tests, then simple-reviewer checks again.
  • Suspected behavior bug: run simple-debug before changing code.
  • Scope expansion: stop and get approval.
  • Unresolved blocker: report the evidence and do not loop forever.
  • After multi-module work, optionally run simple-refactor.

Verification report

Report these separately: repository checks (build, type check, lint, tests), local runtime, browser checks when UI behavior matters, real user data, and production evidence. Do not claim runtime or data validation from build or type check alone.

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.