Overview
/silver is Silver Bullet's dynamic workflow composer. It is the portable way to ask SB to classify a task and route it through the right SB, GSD, and plugin path. You can still invoke specific orchestration workflows directly when you know the exact command.
Every request passing through /silver goes through two sequential steps before work begins:
- Explicit or host-supported routing — explicit
/silverinvocation is always supported; plain-request interception is host/runtime dependent. - Complexity triage — the router classifies the request as Trivial, Simple, Fuzzy, or Complex to determine whether an exploration step is needed and which paths to compose.
After triage, /silver performs path composition — selecting from 18 composable flows and assembling an ordered chain appropriate for the classified work. This replaces fixed step-by-step pipelines: each composition is tailored to the context, not predetermined. See Composable Workflow Orchestration for the full flow catalog.
Explicit and Host-Supported Routing
Use /silver when you want Silver Bullet to classify a natural-language work request. Some host runtimes may support bare-instruction interception, but explicit invocation is the cross-host behavior to rely on.
Why interception exists
Without routing through SB, it is easy to accidentally bypass orchestration. If a plain assistant starts writing code immediately, it can skip clarification, spec work, quality gates, GSD planning, review, and verification. /silver makes the workflow decision explicit and traceable.
How it works
- User invokes
/silverwith a natural-language work request, or the host routes a supported plain request into/silver. - Silver Bullet checks whether this is a non-trivial work request and what kind of work it is.
/silverperforms complexity triage and composes the correct workflow path.- The work proceeds through the full orchestrated pipeline
What should route through /silver
| Message type | Route through /silver? | Example |
|---|---|---|
| Work request / change request | Yes | "Add a login form to the auth page" |
| Feature request | Yes | "Build a dark mode toggle" |
| Bug fix request | Yes | "Fix the crash on the settings page" |
| Deployment request | Yes | "Deploy to staging" |
| Refactor request | Yes | "Refactor the auth module to use the new token service" |
| Slash command | No | /gsd:plan-phase, /silver:fast |
| Pure question | No | "How does the auth module work?" |
| Simple yes/no confirmation | No | "Yes, proceed" (during an active workflow) |
| Single-word acknowledgement | No | "OK", "thanks", "got it" |
| Reply while skill is running | No | Answering a clarifying question mid-workflow |
/silver, the runtime must follow the composed workflow instead of jumping straight into code. The router exists to ensure every task reaches the right skill path; bypassing the selected path defeats the enforcement model.Complexity Triage Decision Tree
Once a request reaches /silver, the router classifies it by scope, risk, and ambiguity. The classification determines which workflow fires and whether a scoping step runs first.
The main classifications
Work through these questions in order:
Classification summary
| Classification | Characteristics | Route | Extra scoping step? |
|---|---|---|---|
| Trivial | ≤3 files, typos, renames, config tweaks, one-liners | silver:fast |
No |
| Bounded medium | 4–10 files, small logic change, dependency update, no cross-cutting impact | silver:fast → gsd:quick |
Only if gsd:quick flags require it |
| Simple | Clear scope, single phase, well-understood problem | Intent-matched workflow | No — skip to workflow |
| Fuzzy | Vague intent, unclear scope, needs clarification | silver:clarify → re-classify |
Yes — clarify first |
| Complex | Multi-phase, cross-cutting, architectural, significant unknowns | Intent-matched workflow with full pre-work | Yes — clarify + synthesis |
silver:fast routes Tier 1 work to gsd:fast and bounded Tier 2 work to gsd:quick with --discuss, --research, --validate, or --full as needed. If the work grows beyond Tier 2, Silver Bullet escalates to silver:feature. §10 routing preferences are not applied to silver:fast by design.Full Routing Table
After complexity triage confirms the request is not Trivial or unresolved Fuzzy, /silver matches intent signals to an orchestration workflow or spec/docs utility:
| Workflow | Entry triggers | First step |
|---|---|---|
| /silver:clarify | "I want to build", "I'm thinking of", "here's my idea", "what if we", "concept:" — when no SPEC.md exists | silver:clarify → gsd:discuss-phase |
| /silver:feature | "add X", "build X", "implement X", "new feature", "enhance X", "extend X" | gsd-scan / /gsd:map-codebase → silver:clarify as needed |
| /silver:bugfix | "bug", "broken", "crash", "error", "regression", "failing test", "not working" | SB triage → systematic-debugging → gsd:debug |
| /silver:ui | "UI", "frontend", "component", "screen", "design", "interface", "page", "layout" | gsd-scan → silver:clarify → gsd:ui-phase |
| /silver:devops | "infra", "CI/CD", "deploy", "pipeline", "terraform", "IaC", "kubernetes", "cloud", "ops" | gsd-scan → silver:blast-radius → /devops-skill-router |
| /silver:research | "how should we", "which technology", "compare X vs Y", "spike", "investigate", "architecture decision" | silver:clarify → configured research path → research artifact → handoff |
| /silver:release | "release", "publish", "version", "go live", "cut a release", "tag v", "ship to users" | silver:quality-gates → gsd:audit-uat → gsd:audit-milestone |
| /silver:fast | "trivial", "quick fix", "typo", "one-liner", "config value", bounded dependency or small logic update | Classify tier → gsd:fast, gsd:quick, or silver:feature |
Ship Disambiguation
The word "ship" is ambiguous in Silver Bullet. It can mean a phase-level merge (a branch PR) or a milestone-level publish (a versioned release). /silver disambiguates at routing time based on signal keywords:
| Signal in message | Route | What it does |
|---|---|---|
| Contains version number (v2.0, 1.4.0, etc.) | silver:release |
Milestone publish: quality gates, audit, create GitHub Release, git tag |
| Contains "changelog" or "release notes" | silver:release |
Milestone publish |
| Contains "go live", "to production", "publicly" | silver:release |
Milestone publish |
| Active phase in progress, no version signal | gsd:ship |
Phase-level merge: push branch, create PR |
| No active phase, end of milestone | silver:release |
Milestone publish |
/gsd:ship runs inside any workflow as the final phase-level step (push → PR). silver:release is a dedicated milestone-level workflow that runs quality gates, UAT audit, milestone audit, and then creates a versioned GitHub Release. Running the wrong one at the wrong scope is a common mistake — let /silver disambiguate for you.See Also
- Composable Workflow Orchestration — the 18-flow catalog that routing composes from
- silver:feature workflow — feature development end-to-end
- silver:bugfix workflow — triage-first bug investigation
- silver:ui workflow — UI/UX with accessibility review
- silver:devops workflow — IaC with blast radius assessment
- silver:research workflow — technology decisions and spikes
- silver:release workflow — milestone publish
- silver:fast workflow — trivial changes bypass
- Getting Started — session startup and first workflow run
- Verification Before Completion — the §3 enforcement gate at the end of every workflow