Startcycle Graph User

⚡ Light Graph — disposable multi-agent fan-out

/startcycle-graph's dispatcher graph is a permanent, project-scoped contract: seven fixed BDB roles, a state.json schema, a repair loop, a Stop-hook gate. That's the right tool for the BDB build pipeline — and the wrong tool for "spawn me 3 workers for this one thing right now" in a project that has never heard of .agents/graph.md and never should. This skill is that lighter tool: a graph sized to the task in front of you, run once, nothing left behind.

1. Design the graph — you do this, before touching any tool

Read the task. Decide how many nodes it actually needs — most tasks need 2 to 4, not seven:

• Plan (always, even if it's one line): what are the parallel workstreams, and what does "done" look like for each.
• Workers (1 to N, run in parallel): the actual fan-out. If the task doesn't parallelize, this is one node, not several for appearance's sake.
• Review (usually, skip only for genuinely trivial work): one adversarial pass over the workers' output before you call it finished.

Do not invent more structure than the task has. A two-file edit doesn't need a Plan node — just do it. This skill is for the cases actually shaped like a small graph, not an excuse to always draw one.

1b. Injecting a specific skill (optional)

/startcycle-graph-user --skill=<name> <task> (repeatable, quote a name with spaces) forces that skill into this run as a hard requirement — for a private skill of the user's own this throwaway graph would otherwise never know to reach for. Extract any --skill= flag(s) from the invocation text before step 1, confirm each name resolves to a real SKILL.md (under any harness's global skills directory — ~/.claude/skills/<name>/, ~/.agents/skills/, ~/.codex/skills/, ~/.cursor/skills/, ~/.roo/skills/ — or this project's own skills/ tree if it has one) — stop and tell the user if one doesn't, never silently proceed without it — and include it as a hard requirement, not a suggestion in the Plan node's and every Worker node's prompt. The Review node checks the combined output for evidence the skill was actually applied, not just mentioned, and calls that out explicitly if it wasn't. Nothing about this gets persisted, same as everything else in this skill — it's a per-run instruction, not a contract. See .agents/graph.md's "Mandatory Skill Injection" section for the same mechanic in the durable graph variant.

2. Detect what's available — before deciding how workers run

command -v agy      >/dev/null 2>&1 && echo agy
command -v opencode  >/dev/null 2>&1 && echo opencode
command -v codex     >/dev/null 2>&1 && echo codex

This machine may have none of these — the skill (and whoever installed this package) cannot assume Antigravity, OpenCode, or a Codex plugin connector is present.

Prefer a plugin's own delegation subagent over shelling out to its CLI. If a delegation plugin is installed, it exposes a subagent that already handles the wrapper flags, the cost discipline, and the digest contract for you — reach for that first, and only drop to a raw CLI call when no such subagent exists:

These subagents are Claude Code plugins, so they exist only when that harness is running and the plugin is installed. Check what is actually available rather than assuming — on any other harness, or a machine without the plugins, the raw CLI column is the only path. Neither column ships with AOS: both depend on tooling the user installed separately.

Pick the worker path in this priority order, first one found wins:

1. A delegation plugin subagent is available → use it (table above). Separate compute pool, zero Anthropic tokens for the work itself, and the wrapper reports failures in a shape the plugin already knows how to read.
2. The CLI is present but its plugin subagent is not → call the CLI directly per the raw-fallback column, following the antigravity skill's invocation pattern and cost discipline.
3. None present → fall back to Claude Code's own Agent tool for each worker, with an explicit model: "haiku" override. This is the only path that costs Anthropic tokens for the worker step, and the only one guaranteed to exist everywhere — it is the floor, not the default.

Give the delegation a real timeout. Measured 2026-09: a trivial headless agy prompt took 605s. agy-delegate defaults to --print-timeout 5m, so it aborts at 300s and reports an empty body while the answer is still on its way — pass --timeout 15m for anything non-trivial. Budget worker wall-clock accordingly; this is the single most likely reason a fan-out "fails" on a machine where the CLI is perfectly healthy.

Verify the delegation actually produced content — a status string is not a result. A timed-out delegation returns {"status": "SUCCESS", "usage": {"total": 0}} with an empty body: success by every field except the one that matters. The zero token counts are not proof the prompt never arrived — headless usage reporting is simply unpopulated. Check the returned text itself, and treat an empty body as a failure no matter what the status says.

This decision happens here, in your own turn, via Bash — never inside a Workflow script. A Workflow script's body has no shell or filesystem access (ambient agent()/pipeline() globals only), so it cannot itself check command -v or shell out to agy-job. If you reach for the Workflow tool for the worker step, that already means you're on the haiku fallback path (case 4) — cases 1-3 are driven directly from your own Bash calls, no Workflow tool involved.

3. Model tiers — fixed by role, not by whatever the session happens to be set to

Force these explicitly on every Agent/agent() call (model: "opus" / "haiku" / "sonnet") — do not let a node inherit the main session's current model. If the user has the session set to Opus for everything, a worker node that silently inherits that is the exact waste this tiering exists to avoid.

4. Run it, once

• Plan node: one call, produces the concrete work-list for the worker nodes (file-level or task-level, whatever the task needs).
• Worker nodes: fan out per step 2's chosen path, in parallel where the tasks are actually independent.
• Review node: one adversarial pass ("find what's wrong," not "does this look good") over the combined worker output, sonnet-tier.
• Report the outcome directly to the user. Nothing gets written to .agents/, no state.json, no persistent contract — this graph existed for the duration of the task and is gone once it's done.

5. When to reach for /startcycle-graph instead

If the task turns out to actually need the full pipeline — multiple build domains (UI/UX, Engineering, Media/EventTech), a real repair loop with a no-progress guard, or a durable record of what happened for future sessions — stop and use /startcycle-graph, not this. This skill is deliberately too small for that job; don't stretch it to cover what the real dispatcher graph (.agents/graph.md) already does properly.

6. Common Rationalizations

7. Red Flags

• Any worker node running on sonnet/opus without a specific reason forced by the task.
• Assuming agy/OpenCode/Codex is present without checking.
• Writing .agents/, state.json, or any persistent file for a task this skill was invoked for — that's /startcycle-graph's job, not this one's.
• A "light" graph with more nodes than the task actually has independent workstreams.

8. Verification

• Detection step actually ran (command -v checks), not assumed.
• A plugin delegation subagent was preferred where one was available, rather than shelling out to the CLI anyway.
• Each node's model was explicitly forced, not inherited.
• Each worker's returned content was checked, not just its status field — an empty body is a failure regardless of a SUCCESS status.
• Nothing persistent was left behind after the task completed.