agentleFS
AirMileAirMile/claude-config/skills/core-orchestrate/SKILL.md

core-orchestrate

Skill0 starsChanged 4 months agoMITView on GitHub

Orchestrate a task with agent fan-out and research. Use with /core-orchestrate.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Run a substantive task as an orchestrated flow — scope, parallel research fan-out, evidence-disciplined synthesis, execution, adversarial …

    line 12
  2. Distinctive:

    STOP: before any irreversible action (delete, force-push, overwrite of user-owned files, external publish): confirm it is in the approved …

    line 66
  3. Very specific:

    Verify against the deliverables from PHASE 0, per CODING-RULES.md R009: every done-claim is backed by a command run fresh, with output …

    line 72

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

Orchestrate

Run a substantive task as an orchestrated flow — scope, parallel research fan-out, evidence-disciplined synthesis, execution, adversarial verification — instead of one long inline pass. This is a discipline skill: it structures how the work runs; the task itself supplies the content.

Trigger: /core-orchestrate <task> — the argument is the task. No argument → ask for the task in one line (no AskUserQuestion needed).

When NOT to use: 1-3 file changes (/dev-tweak, /game-tweak), pipeline features (/dev-ship, /game-ship), pure conversation. Those flows already carry their own structure — say so and stop.

Model selection

Work typeModel
Mechanical: search, extraction, probes, rehearsals, draftssonnet
Judgment: synthesis, architecture, trade-offs, final reviewopus
Anything elseomit model — inherit the session

Passing paths beats passing content: agents read files themselves (SKILL-PATTERNS.md § Pass Paths, Not Content).

PHASE 0: Scope

Produce a scope block before any agent runs:

SCOPE: [task]
Deliverables: [concrete artifacts]
Unknowns: [each unknown → one research question]
Execution surface: [files/systems that will change, or "analysis only"]

A vague task gets at most one AskUserQuestion (recommended option first) to pin deliverables — then commit to the scope. Every research question in Unknowns becomes exactly one agent in PHASE 1; a question no agent will answer is cut here, not silently dropped later.

PHASE 1: Research fan-out

Launch one agent per research question, all in parallel, model: sonnet, each with a JSON output schema (schema-forced output beats prose parsing):

  • Web: WebSearch for external facts, prior art, failure modes — claims need sources.
  • Docs: context7 (mcp__context7__resolve-library-id + query-docs) for library/framework/API facts — never answer those from memory.
  • Codebase: Explore agents for repo questions — paths in, conclusions out.
  • Probes: when the deliverable will be executed by a model (skill, prompt, agent definition), add a rehearsal probe on the executing model's tier that reads the current artifact and reports what it would skip, misread, or improvise. Probes never see the draft they are meant to test.

4+ agents or multi-stage dependencies between them → use the Workflow tool (this skill instruction is the opt-in); below that, parallel Agent calls in one message.

PHASE 2: Synthesis

Merge agent outputs against the scope block at opus level (inline when the session model is opus-class, else one model: opus agent). Apply the evidence rule: a claim survives only with a cited source or an agent finding behind it — unevidenced claims are dropped and listed as dropped, not blended in. Output: a decision list (what will be built/changed and why), each entry traceable to evidence.

Second-opinion hook (auto-fires before the user-facing fork below, at most once this phase) — if ≥2 agents reached conflicting conclusions on the same question, or the synthesis itself is ambiguous about which path to recommend: read .claude/skills/shared/SECOND-OPINION.md and follow it — the trigger auto-fires the consult (no confirm step) with INPUT = the per-agent findings (paths or inline digest) + the ambiguous decision point (orchestrate-synthesis row of § Brief contents). Show the digest before the user fork below (attended) or fold it into the decision list itself (unattended — Opus weighs it and revises the list or confirms it), set secondOpinionUsed, carry the outcome to the report's Second opinion: row.

Real decision forks go to the user via AskUserQuestion, recommended option first (the digest's recommendation, if any, shown as part of that option's description); everything else is decided here.

PHASE 3: Execute

Execute the decision list:

  • Small edit set → inline in the main chat.
  • Parallelizable independent work → agents; add isolation: worktree only when agents mutate files concurrently (worktrees cost setup time — never by default).
  • STOP before any irreversible action (delete, force-push, overwrite of user-owned files, external publish): confirm it is in the approved scope; if not, ask first.

Each executed item points at its artifact (file, commit, output block) — PHASE 4 consumes these artifacts, so an item without one is not done.

PHASE 4: Verify

Verify against the deliverables from PHASE 0, per CODING-RULES.md R009: every done-claim is backed by a command run fresh, with output shown.

  • Deterministic first: tests, validators, linters that cover the artifacts.
  • Model-executed deliverables get a rehearsal agent on the tier that will run them (e.g. model: sonnet executor reading only the artifact + a target): it must produce concrete results without meta-questions — vague output means the artifact failed, revise and re-run.
  • Contested or high-stakes findings get an adversarial pass: 2-3 agents prompted to refute, majority decides.

Report:

ORCHESTRATED: [task]

| Phase | Result |
|-------|--------|
| Scope | [deliverables count, unknowns count] |
| Research | [n agents, n findings kept / n dropped] |
| Synthesis | [n decisions, n user forks] |
| Execute | [artifacts] |
| Verify | [checks run + outcomes, rehearsal verdict] |
| Second opinion | {none \| consulted ({trigger}) \| consulted ({trigger}) → revised \| unavailable} |

Next steps: [follow-ups, or none]

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.