Overview
/silver:bugfix is the Silver Bullet orchestrator for bugs, regressions, crashes, errors, and failing tests. It enforces triage-first discipline: classify the failure type before any investigation begins.
It never implements fixes directly — it orchestrates only. Investigation, planning, execution, review, and verification are all delegated to specialist skills.
The key design insight: three very different failure categories require three different starting points. Applying the wrong investigation technique wastes time and produces incomplete diagnoses. Triage first, investigate second.
silver:bugfix uses composable flows architecture — it composes paths from the 18-flow catalog tailored to bug context. A typical composition: FLOW 0 (BOOTSTRAP) → FLOW 1 (ORIENT) → FLOW 14 (DEBUG) → FLOW 5 (PLAN) → FLOW 7 (EXECUTE) → FLOW 11 (VERIFY) → FLOW 13 (SHIP). See Composable Flows for the full catalog.
When to use
Use /silver:bugfix for any of these entry trigger signals:
- "bug" / "broken" / "crash" / "error"
- "regression" / "failing test" / "not working"
- Any observation that something that used to work has stopped working
- A test that was green is now red
- A GSD workflow or plan that failed mid-execution
silver:bugfix always takes precedence over silver:feature and silver:ui when triggered by a bug report.
Workflow steps
Pre-flight
Silver Bullet reads silver-bullet.md §10 to load user workflow preferences before any step executes.
Step 0 — Triage: classify failure type
Before any investigation, Silver Bullet presents a classification question:
The selection routes to one of three paths. All paths converge at Step 2 (TDD).
Path 1A — Known symptom, unknown fix
Invoked when triage selects A, OR after Path 1B/1C forensics completes and hands off here.
1A.1 — Systematic debugging hypothesis
Invoke superpowers:systematic-debugging. Purpose: structure the debugging hypothesis before executing investigation — ensures a systematic approach before diving into code. Produces a testable hypothesis with reproduction steps.
1A.2 — Persistent debugging investigation
Invoke gsd:debug. Purpose: execute investigation with persistent state across context resets. After gsd:debug completes, proceed to Step 2 (TDD).
Path 1B — Unknown cause, needs reconstruction
Invoked when triage selects B — session history is unclear or cause cannot be determined from current state.
1B.1 — Forensic cause reconstruction
Invoke silver:forensics. Purpose: SB-owned forensics skill that reconstructs cause from git history, artifacts, and state. Produces a cause classification report. After forensics completes: hand off to Path 1A (start at Step 1A.1 with the reconstructed context).
Path 1C — Failed GSD workflow
Invoked when triage selects C — a GSD plan, execution phase, or GSD command failed.
1C.1 — GSD-specific post-mortem
Invoke gsd:forensics. Purpose: GSD-owned post-mortem for failed GSD workflows (failed plans, broken state, incomplete phases). Produces a diagnosis of what went wrong in the GSD layer. After gsd:forensics completes: hand off to Path 1A (start at Step 1A.1 with the GSD diagnosis context).
Step 2 — TDD regression test (all paths converge here)
All three paths converge at this step. Before writing any fix code:
Invoke the SB tdd gate. Purpose: write a failing regression test first — RED must appear before writing any fix. The SB wrapper delegates to the Superpowers TDD skill only at this execution boundary, so bugfix work stays routed through SB+GSD while preserving failing-test-first discipline.
Step 3 — Plan the fix
Invoke gsd:plan-phase (lightweight — 1–2 tasks only. This is a fix, not a feature).
Step 4 — Execute fix and verify green
Invoke gsd:execute-phase --tdd. After execution, verify the regression test from Step 2 is now green.
Step 5 — Code review
Run the full review sequence in order: /requesting-code-review (superpowers:requesting-code-review) → gsd:code-review → /receiving-code-review (superpowers:receiving-code-review).
Step 6 — Verify work
Invoke gsd:verify-work. Purpose: confirm fix, zero regression. Non-skippable gate.
Step 7 — Security-sensitive review
Check the fix through the security criteria used by code review and the Security dimension of /silver:quality-gates. Security is enforced as part of the review and quality-gate path.
Step 7b — Quality gates
Invoke /silver:quality-gates for affected quality dimensions of the changed code. Non-skippable.
Step 8 — Ship
Invoke gsd:ship. Purpose: push branch, create PR.
Non-skippable gates
- Security dimension inside
/silver:quality-gates(Step 7b) /silver:quality-gatespre-ship (Step 7b)gsd:verify-work(Step 6)
Example invocation
Silver Bullet presents triage options. You select A (known symptom, unknown fix). SB invokes systematic-debugging to form a hypothesis, then gsd:debug to investigate. Root cause found → write failing regression test → plan fix → execute → review → verify → ship.