agentleFS
grainulationgrainulation/grainulator/skills/orchestrate/SKILL.md

orchestrate

Skill86 starsChanged 9 days agoMITView on GitHub

Multi-sprint orchestration — view dependency graph, identify the next ready sprint

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

We split this skill into the rules it gives an agent

12 rules. 0 are common, 5 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 144 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

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

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

    Search for orchard.json in these locations (in order):

    line 22
  2. Distinctive:

    Use Glob to find it:

    line 27
  3. Distinctive:

    If NOT found, skip to Step 5.

    line 37
  4. Very specific:

    Run with working directory <config-parent>:

    line 41
  5. Very specific:

    If the user passed arguments like --mermaid or --format mermaid, forward them:

    line 49
  6. Distinctive:

    If the command fails (e.g., all sprints are done or blocked), note that in the summary.

    line 65
  7. Distinctive:

    If no sprints are ready but some are blocked, explain which dependencies need to complete first.

    line 91
  8. Distinctive:

    If all sprints are done, congratulate and suggest:

    line 93
  9. Very specific:

    If no orchard.json was found in Step 1, explain how to create one:

    line 109
  10. Very specific:

    Always run plan before next so the user sees the full graph context.

    line 153
  11. Very specific:

    Do NOT modify orchard.json -- this skill is read-only.

    line 154
  12. Very specific:

    If grainulator orchestrate fails with a module-not-found error, suggest: grainulator doctor and use the local checkout CLI.

    line 156

“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

/orchestrate -- Multi-sprint orchestration

View the sprint dependency graph, check sprint states, and dispatch the next ready sprint for execution.

Arguments

$ARGUMENTS

Instructions

Step 1: Locate orchard.json

Search for orchard.json in these locations (in order):

  1. Project root (current working directory)
  2. .grainulator/ subdirectory

Use Glob to find it:

**/orchard.json

If found, read it and resolve its absolute parent directory as <config-parent>. Run every subsequent orchestration CLI call with its working directory set to <config-parent>, including when the file is under .grainulator/. The CLI searches the working directory and ancestors, not child directories; --root is not a directory override for plan or next. Sprint paths in the configuration are relative to this parent directory.

Preserve the caller’s working directory outside these scoped commands. For a shell-only host, use a subshell with a safely quoted cd; a command tool’s working-directory parameter is preferable. Then proceed to Step 2.

If NOT found, skip to Step 5.

Step 2: Show the dependency graph

Run with working directory <config-parent>:

grainulator orchestrate plan --format ascii

This prints the full sprint dependency graph with status indicators. Display the output as-is -- it already includes status markers (done, active, blocked, ready).

If the user passed arguments like --mermaid or --format mermaid, forward them:

grainulator orchestrate plan --mermaid

Step 3: Get next ready sprints

Run with working directory <config-parent>:

grainulator orchestrate next --json

This returns a JSON array of sprints whose dependencies are satisfied and are ready for execution. Parse the output.

If the command fails (e.g., all sprints are done or blocked), note that in the summary.

Step 4: Display actionable commands

For each ready sprint from Step 3, format it as a concrete command the user can run:

Ready sprints:
  /research "Sprint question here"   -- path: .grainulator/sprints/sprint-slug
  /research "Another question"       -- path: .grainulator/sprints/other-slug

Then print a summary:

Orchestration: <total> sprints, <done> done, <active> active, <ready> ready, <blocked> blocked

Auto

- <authorized next action>

Manual

- <action requiring the user, or None.>

If no sprints are ready but some are blocked, explain which dependencies need to complete first.

If all sprints are done, congratulate and suggest:

All sprints complete.

Auto

- <authorized next action>

Manual

- <action requiring the user, or None.>

Step 5: No orchard.json found

If no orchard.json was found in Step 1, explain how to create one:

No orchard.json found. Grainulator coordinates multi-sprint research with dependency tracking.

To get started, run:

  grainulator orchestrate init --root <intended-config-parent>

Or create orchard.json manually:

  {
    "sprints": [
      {
        "path": "./.grainulator/sprints/step-1-research",
        "question": "What are the key findings on topic X?",
        "depends_on": [],
        "assigned_to": "claude",
        "status": "ready"
      },
      {
        "path": "./.grainulator/sprints/step-2-validate",
        "question": "Do the findings from step 1 hold up?",
        "depends_on": ["./.grainulator/sprints/step-1-research"],
        "assigned_to": "claude",
        "status": "blocked"
      }
    ],
    "settings": {
      "sync_interval": "manual"
    }
  }

Auto

- <authorized next action>

Manual

- <action requiring the user, or None.>

Rules

  • Always run plan before next so the user sees the full graph context.
  • Do NOT modify orchard.json -- this skill is read-only. Use grainulator orchestrate sync or manual edits to change state.
  • Forward any extra arguments the user provides (e.g., --mermaid, --verbose) to the underlying orchestration commands.
  • If grainulator orchestrate fails with a module-not-found error, suggest: grainulator doctor and use the local checkout CLI.

Host access

Use available grainulator MCP tools, passing the active sprint dir explicitly for evidence operations. If a tool is unavailable, use the local grainulator CLI (or node <checkout>/bin/grainulator.js). Read sibling skill files directly when slash commands are unavailable. Resolve template paths relative to this skill’s checkout when CLAUDE_PLUGIN_ROOT is unset. Optional external connectors are not required for local work; use local code, supplied documents, or available web tools. Do not write managed ledger files directly to bypass a missing MCP connection.

Next-step output

For standalone fetch, setup, or read-only orchestration without an evidence sprint, derive next steps from that task. Do not initialize or compile an unrelated ledger just to produce this footer.

When working in an evidence sprint, use the current compiler's next_actions to present exactly two bullet lists labeled Auto and Manual. Auto is work the agent can continue under existing authorization. Manual is only work requiring the user's decision, access, or action. Classify using the current request and constraints; compiler suggestions never grant permission. Continue authorized Auto work without asking again.

Keep 2–3 useful actions total when available, use short concrete labels and commands where useful, and show None. for an empty group. Do not invent work to fill a quota. Never omit next steps merely because compilation is ready or the answer should be brief. Refresh stale compilation first and exclude work the user removed from scope. When the user asks only for next steps, output only these two lists: no findings recap, counts, reasons, or offer to continue.

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.

Reviews can't be read right now.

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.