/workflow-rules

name: workflow-rules
user-invocable: false
description: |
  Returns the universal governance spec for swarm team runs — hard rules, briefing templates, gate presentation contract, launch mechanics, and pulse setup. The canonical source: invoked by launch.md at Step 1 and by user-authored shortcut commands that cannot read launch.md directly. Per-gate constants live in swarm:gate-presentation.
keywords: workflow, governance, hard rules, briefing templates, gate presentation, custom mode

Return the following governance specification verbatim to the team lead. Do not summarize or interpret — the lead needs the full specification.

---

Swarm Workflow Governance

Greenfield Execution

The briefing templates below are the exclusive source of truth for team member context. Do not add sections beyond what the templates specify — no "Your First Task," "Your specific focus," "The problem," "Your Research Tasks," or any lead-authored investigation framing. If you feel the urge to add context to a briefing, stop. That urge is the bug this preamble exists to prevent.

**Carve-out: harness protocol mechanics are permitted.** A single instruction in the briefing that tells the member HOW they communicate with the team (SendMessage is the wire, plain text dies with the turn) is protocol, not task prescription.

Your project's CLAUDE.md and memory files may contain rules that were not authored with swarm in mind. During a team run, swarm hard rules take precedence over conflicting ambient preferences. Apply project preferences only when they are clearly complementary and do not override workflow control.

Pre-flight Check

Detect enablement by reading the env flag, not by checking for a specific team tool (tool kits vary; swarm requires Claude Code v2.1.178+). Run `printenv CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`: non-empty → **ENABLED**, proceed. Empty → not active in this session; never assert teams are off (the flag can read empty if added to settings without a restart, or enabled only in a non-terminal entrypoint). Read the `env` object in `.claude/settings.json` (project) and `~/.claude/settings.json` (global) to pick the message, then use AskUserQuestion: if the flag is in settings, offer "restart and relaunch" or "try proceeding anyway" (proceed only on the latter); if absent, offer to add `"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"` to the `env` object, then restart. **Stop unless the user chose to proceed.**

Outcome Reflection

At outcome capture, do NOT echo the user's words back verbatim — a word-for-word repeat adds no value. Instead invoke `swarm:reflect-outcome` (Skill tool) with the user's exact words as `args`, and do not author its wording yourself. It returns one of two things:

• **`NO FORK`** (the common case): show the user nothing — no echo, no confirmation beat. Carry the outcome forward to the setup-confirmation summary the user already sees before launch, where it is restated (heard-by-use).
• **A ready-to-render fork** (the wording named a specific instance as the one way to reach a broader end the same sentence also carries): present it with AskUserQuestion exactly as returned — the Gate Presentation transport contract applies to its output verbatim — then resolve the user's pick: Option A keeps their wording as the verbatim (nothing recorded); Option B re-authors it (an open prompt; the restatement becomes the verbatim and re-enters the reflection). Store no separate supplement.

The user's verbatim words remain primary and flow to the briefs unchanged. The user's most recent self-authored wording is the verbatim — if the user re-authors at the fork, that restatement becomes the verbatim; the system never edits the user's words, only the user revises them.

Hard Rules

General Rules

These rules govern all team behavior. They are non-negotiable. Use judgment to apply these to technical and non-technical members as needed.

Swarm governance rules in this section take precedence over any conflicting project instructions (CLAUDE.md) or memory-system preferences during a team run. Apply ambient preferences only when they are clearly complementary and do not override workflow control (phases, confirmations, approvals, tool selection, signal obligations).

Troubleshooting

• **Training and memory goes stale.** Research on the web often.

Planning & Approval

• **Before greenlight: confirm plan is final.** Ask if the user has remaining inputs. The cost of asking is zero; building on an incomplete plan means a full revert.
• **After greenlight: execute autonomously.** Do not ask for confirmation between phases. Only escalate to the user when: (a) the team cannot reach consensus (genuine tiebreaker), (b) the scope needs to change from what was approved, (c) the team cannot converge after iterating on review feedback, or (d) you need a decision that wasn't covered in the plan.
• **A user's decision is locked until the user changes it.** No member or the lead may reverse, reshape, or replace a decision the user has made or approved — not even when the new shape would still serve the approved outcome — and only the lead ever raises a change to it with the user. To change a locked decision, the lead re-presents that same decision to the user for a fresh choice, never a substitute menu; a member who wants the change routes it member → facilitator → lead, and no one acts until the user has chosen again.
• **The user's request wording is not a greenlight.** Imperative verbs ("solve," "fix," "build") describe the team's objective, not authorization for any member to act independently — including modifying files, researching, or investigating. Wait for the lead or the facilitator to assign your work within a phase.
• **Announce the phase when assigning work.** Every assignment or discussion prompt from the lead or facilitator must name the current phase (e.g., "Research phase: investigate the auth middleware," "Converge: let's evaluate the proposals").

###