| name | symphony |
| description | Launch the claude-symphony autonomous bug-fixing workflow scoped to any Linear team/project backed by GitHub. Ensures Linear login (triggers OAuth if needed), lets the user pick the team/project, confirms the target repo(s), then runs the workflow. Invoked as "/symphony:symphony" (plugin skills are namespaced), or triggered by "run symphony", "fix bugs in <project>", "arreglar bugs de <project>". |
Symphony launcher — pick a Linear project, point it at a repo, then run
This skill is the interactive front door to the claude-symphony workflow, which
ships alongside this skill in the same plugin at
$CLAUDE_PLUGIN_ROOT/workflows/claude-symphony.js. The workflow itself is
project-agnostic — team, project, repos, and the Linear state names are all
args. This launcher handles the parts a headless workflow can't: Linear login,
choosing the project, and confirming which GitHub repo to fix bugs in.
Follow these steps in order. Do NOT skip the login check.
Step 1 — Ensure Linear is authenticated
Try a lightweight Linear call: mcp__linear-server__list_teams (load it via
ToolSearch first if needed).
- If it succeeds → authenticated, continue.
- If the Linear tools are not available or the call errors with auth/permission:
call
mcp__linear-server__authenticate, give the user the returned authorize
URL, and ask them to complete the OAuth in the browser. If the redirect page
errors, have them paste the full callback URL and call
mcp__linear-server__complete_authentication with it. Re-check with
list_teams before continuing.
Step 2 — Resolve the team
- If the user named a team, use it.
- Else call
list_teams. If there's exactly one, use it. If several, ask the user
which one (AskUserQuestion).
Step 3 — Choose the Project (optional scope)
- Call
mcp__linear-server__list_projects for the team.
- Present the projects with AskUserQuestion (one option per project, plus a
"Whole team (no project filter)" option). If the user already named the project,
skip the question and use it.
- Record the chosen
project (name or id). "Whole team" → omit project.
Step 4 — Confirm the repository target
The engine defaults to single-repo mode: it fixes bugs in the GitHub repository
of the current working directory and auto-detects the slug + default branch.
- If the user is running from inside the repo they want to fix → no
repos arg needed.
- If they want to pin it or use a different repo → pass
{ repo:"owner/name", base:"main", tests:"<test command, or omit to auto-detect>" }.
- If this is a monorepo of several repos → pass a map:
{ repos: { "dir-a": {repo:"owner/a", base:"main", tests:"auto"}, ... } }.
Confirm gh is authenticated (gh auth status) — the fix path needs it to push and
open PRs.
Step 5 — Confirm scope + mode
Confirm with the user, briefly:
- team + (optional) project,
- repository target (single-repo default, pinned repo, or monorepo map),
- which mode: single
{issue:"ABC-123"}, explicit {issues:[...]}, or batch
{batch:true, limit:N} (+ optional labels / states).
Step 6 — Run
Invoke the workflow with the resolved args. Use the plugin-relative path so it works
after install (the plugin is copied to a cache dir; $CLAUDE_PLUGIN_ROOT resolves to
the installed plugin directory):
Workflow({ scriptPath: "$CLAUDE_PLUGIN_ROOT/workflows/claude-symphony.js", args: { team, project, batch:true, limit:5, tag:"<HH:MM>" } })
If $CLAUDE_PLUGIN_ROOT is not set (e.g. you're running the skill from a raw source
checkout rather than an installed plugin), fall back to the workflow's path relative
to this skill: ../../workflows/claude-symphony.js.
Use scriptPath (not name) so the latest engine edits are picked up in-session.
Then report the result; if the user wants a continuous sweep, drive it with /loop.
Notes
- The engine refuses to run with no selector (fail-safe). Batch requires explicit
{batch:true} and a team.
- Linear states used by the full flow (override via args if your team names them
differently):
In Progress (claim), In Review (handoff), Needs Human
(failed/triage), Done (promote merged PRs). Create any that are missing, or
remap them with {claimState, reviewState, needsHumanState, mergedState}.
- Triage labels (
cannot-reproduce / false-positive / already-fixed) and the
Bug label should exist in the target team for routing/labelling to work.