Type `/orchestrate <goal>` and this skill spawns a tree of parallel Cursor cloud agents to tackle large tasks without you babysitting each step. The planner decomposes work into a plan.json, workers execute in isolated repo clones, and everyone communicates through structured handoffs stored in Git. No cross-talk between siblings, no shared state, just propagation up the tree. It's built for tasks too big to hold in one context window or too parallelizable to run serially. The setup demands CURSOR_API_KEY and lives in scripts/cli.ts. Optional Slack integration mirrors progress and lets you pull the Andon cord. Read the cursor-sdk skill first because auth and error handling live there.
npx -y skills add cursor/plugins --skill orchestrate --agent claude-codeInstalls into .claude/skills of the current project.
An explicit /orchestrate <goal> fans out a large task across parallel Cursor cloud agents. Workers don't talk to each other; they talk up through structured handoffs. The spawn, wait, and handoff loop lives in scripts/cli.ts. The planner writes plan.json, the script executes it, and the planner reads handoffs to decide what comes next. Long-running agent loops drift; a script with a JSON state file keeps its footing.
Required reading: the cursor-sdk skill (cursor/plugins/cursor-sdk). Spawning, auth, and the error taxonomy live there. Don't reimplement what that skill already documents.
CURSOR_API_KEY must be a personal/user key. Create it from Cursor Dashboard > Integrations, then read cursor-sdk Auth before using it.SLACK_BOT_TOKEN is optional. When set, pass --slack-channel <id> to kickoff or the first run --root, or set SLACK_CHANNEL_ID. The script stores the channel in plan.slackChannel, posts the kickoff thread there, mirrors task status, and reads Andon reactions. When the token is unset, the script logs once and runs without Slack visibility; correctness does not change.These rules make the tree self-converging without global coordination.
plan.json, reading handoffs, and deciding what's next are planner work. Editing files, running git merge, and fixing conflicts inline are not. If a planner feels the urge to code, it publishes a task for a worker instead.| Node | Runs the loop? | Scope | Output |
|---|---|---|---|
| Planner | yes | Entire user goal | User-facing message + optional PR |
| Subplanner (↻) | yes | One slice of parent's scope | Handoff to parent |
| Worker | no | One concrete task | Handoff to spawning planner |
| Verifier | no | One target's acceptance criteria | Verdict handoff to spawning planner |
| Git | n/a | Shared medium | Branches (code) + handoffs/ (meaning) |
Two roles, one skill. Read your role's reference file and skip the other.
Dispatcher. You're in a local IDE session and the user typed /orchestrate <goal>. Your job is to kick off a cloud root planner and return its URL. See references/dispatcher.md. One-shot; you are not the planner.
Planner (root or sub). You were spawned with a structured prompt that opens with "You are the root planner for:" or "You are a subplanner for:". Or the user chose to run the planning loop locally. You own a scope, publish tasks, read handoffs, decide what's next. See references/planner.md.
disable-model-invocation: true means this skill loads only on explicit invocation.
sickn33/antigravity-awesome-skills
moizibnyousaf/ai-agent-skills
github/awesome-copilot