superscalar

# Superscalar — execution-scheduling discipline Two jobs in one skill. **Invoked with an argument** (`/superscalar always|auto|off|status`) it is a **mode toggle** — see §0. **Invoked with no argument, or consulted before a fan-out**, it is the dispatch checklist — §1 onward, read through the lens of the current mode. ## 0. Mode toggle — how eagerly to fan out (`always` | `auto` | `off`) State = **one marker file**, `.agent/superscalar.json` → `{"mode": "always"|"auto"|"off", "since": "<date>", "note": "<why>"}`. **Absent ⇒ `auto`.** Read it at dispatch time; never mirror the mode into other settings surfaces. - `/superscalar always` — write the marker with `always` · `/superscalar auto` — write `auto` (or delete the marker) · `/superscalar off` — write `off` · `/superscalar status` — read it back and report the mode plus where it would apply to the work in front of you. | Mode | What it changes | What it does not change | |---|---|---| | `off` | No fan-out on your own initiative — independent work runs in declared order. An explicit user request to parallelize is still honored; record it as an override. | — | | `auto` *(default)* | §2's cost-benefit gate arbitrates, as before. | — | | `always` | **Burden of proof inverts**: with ≥2 independent lanes, fan out *unless* a veto below applies. The gate becomes a veto list, not a hurdle. Prefer `Workflow`/`pipeline` over serial inline for multi-item work. | Every safety invariant. See below. | **`always` vetoes** (still seri...