/update-workflow

description: Regenerate an existing custom workflow's shortcut command wiring from the current swarm template
argument-hint: <workflow name>
disable-model-invocation: true

/swarm:update-workflow

You are updating an existing custom workflow's shortcut command to match the current swarm template. This command regenerates **only** the plugin-owned wiring of `.claude/commands/<name>.md` — the `## Workflow` section and default wiring that comes from swarm. It **never** touches the mode skill at `.claude/skills/<name>-mode/SKILL.md` — that file is consumer-owned.

Step 0: Parse argument

$ARGUMENTS

The argument is the **workflow name** (kebab-case, matching the existing file name without `.md`). If $ARGUMENTS is empty, ask the user (plain text, not AskUserQuestion): "Which workflow should I update? (Pass the name — e.g., `triage-gh-issue`.)" Wait for their response.

Step 1: Locate and read the existing file

The target file is `.claude/commands/<name>.md` in the current working directory.

• If the file does not exist: tell the user "No workflow found at `.claude/commands/<name>.md`. This command updates existing workflows — use `/swarm:create-workflow` to create a new one." Stop.
• If the file exists: use the **Read** tool to read it.

Do **not** read or modify `.claude/skills/<name>-mode/SKILL.md`. That file is consumer-owned.

Step 2: Extract consumer-owned sections

From the existing shortcut command, extract these consumer-owned values and blocks verbatim. These will be preserved:

• **Frontmatter fields:** `description`, `argument-hint`, `disable-model-invocation`, and any other fields present. Preserve all of them.
• **`## Settings` section** — the entire block under the `## Settings` heading, including Mode, Outcomes question, Defaults, and any other settings the consumer has added.
• **`## User-Provided Context` section** — the block under that heading (typically `$ARGUMENTS`).
• **`## Pre-flight` section if present** — the block under that heading (intake-specific actions, bash commands, arg parsing). This is consumer-owned.
• **Any section not recognized as plugin-owned** — preserve as-is.

Consumer ownership rule: anything that is not the plugin-owned wiring (the template preamble and the `## Workflow` section) belongs to the consumer.

Step 3: Regenerate the plugin-owned sections

The plugin-owned parts of a custom shortcut command are:

1. **The preamble** — the line directing the lead to invoke `swarm:workflow-rules` and the "No lead research unless enabled." paragraph. 2. **The `## Workflow` section** — the numbered steps that wire the run.

Use this current template for the plugin-owned parts, substituting `<name>` with the workflow name:

# /<name>

You MUST use the **Skill** tool to invoke `swarm:workflow-rules`. It returns the governance spec for this team run: pre-flight check, hard rules, briefing templates, and launch mechanics. Follow that spec for the entire run.

**No lead research unless enabled.** Unless the user explicitly enables lead research, do not read codebase files, spawn subagents, or perform research. Delegate all research to teammates.

And for the Workflow section:

## Workflow

1. **Pre-flight.** Follow the pre-flight check from `swarm:workflow-rules`.
2. **Outcomes.** If User-Provided Context is non-empty, use as outcomes. Otherwise ask the outcomes question (plain text, not AskUserQuestion). Do not echo the outcomes back verbatim — run the outcome reflection per `swarm:workflow-rules`: invoke `swarm:reflect-outcome` with the user's exact words. On `NO FORK`, carry the outcome forward to the step 5 confirmation summary with no echo or confirm beat. On a fork, present it with AskUserQuestion exactly as returned (the transport contract in `swarm:workflow-rules`) and resolve the user's pick per the skill (Option A keeps the wording; Option B re-authors into a new verbatim). Store no separate supplement.
3. **Setup.** Render the Setup gate with AskUserQuestion. The cost tier is this explicit pick — outcomes passed inline do not skip it. Wait for the selection.
4. **Team.** Invoke `<name>-mode` via the Skill tool (unqualified name) — this is your mode skill. If its frontmatter declares `extends:` (a thin wrapper), also invoke the declared base mode via the Skill tool immediately after and combine per the extension contract in `swarm:workflow-rules` — the base provides lead identity, facilitator, phase arc, and base rules; the wrapper's sections are additive. Then invoke `swarm:suggest-members`, passing the mode skill's Suggest-Members Guidance (for wrappers: the base's guidance plus the supplement) and the confirmed outcomes; no lead research. Present the suggestion by rendering the Team gate (roster handles in the question text, full identity lines in each option's `preview`); "I want to adjust" is free text — swap a member, add more, or remove some; re-confirm through the same gate. Wait for the team to be confirmed.
5. **Confirmation.** Render the Plan gate (launch variant) with AskUserQuestion — the launch-variant digest in the question text, the elaboration preview on each option. If "I have changes": ask what to change (free text) and apply it — a changed outcome re-enters step 2's reflection; team changes go through step 4's adjust flow; the step 3 tier can be re-picked; lead research defaults to no (yes lets the lead delegate research to Explore subagents) — then re-present this confirmation. Repeat until the user launches.
6. **Launch.** Follow the launch mechanics from `swarm:workflow-rules`. The mode skill is already invoked — apply its spec, read any Pre-flight Reads files, then spawn the team.

Step 4: Assemble the proposed file

Compose the new file by merging consumer-owned sections (Step 2) with regenerated plugin-owned sections (Step 3):

1. Frontmatter (consumer-owned, preserved as-is — but if `generated-by` is missing from the frontmatter, add `generated-by: swarm@<current versi