StartConceptsWorkflowsReferenceTroubleshoot

Routing Logic

How /silver classifies instructions, performs complexity triage, and composes orchestration workflows when you invoke it explicitly (or when the host supports plain-request routing).

Overview

/silver is Silver Bullet's dynamic workflow composer — the runtime face of catalog atom AF-ROUTE and workflow WF-SILVER-ROUTER. It is the portable way to ask SB to classify a task and route it through the right SB lifecycle and optional extension 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:

  1. Explicit or host-supported routing — explicit /silver invocation is always supported; plain-request interception is host/runtime dependent.
  2. 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 catalog-backed atomic flows from the canonical AF-* catalog 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 canonical AF-* 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, planning, review, and verification. /silver makes the workflow decision explicit and traceable.

How it works

  1. User invokes /silver with a natural-language work request, or the host routes a supported plain request into /silver.
  2. Silver Bullet checks whether this is a non-trivial work request and what kind of work it is.
  3. /silver performs complexity triage and composes the correct workflow path.
  4. The work proceeds through the full orchestrated pipeline

What should route through /silver

Message typeRoute 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 /silver:plan, /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
Anti-skip rule: when work is routed through /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:

Is the change small and bounded enough for fast-path triage? YES → Trivial or bounded medium → route to silver:fast Tier 1 uses the SB fast path; Tier 2 uses bounded SB quick handling with flags Is the intent vague or scope unclear? Would you need to clarify before planning? YES → Fuzzy → run silver:clarify first, then re-classify Is the scope clear and does it fit within a single phase? YES → Simple → route to the correct workflow, skip clarify step Multi-phase, cross-cutting, architectural, or has significant unknowns? YES → Complex → full workflow with silver:clarify + synthesis

Classification summary

ClassificationCharacteristicsRouteExtra 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 Tier 2 Only if SB Tier 2 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
Fast-path work still has a boundary. silver:fast routes Tier 1 work through SB fast execution and bounded Tier 2 work through SB quick handling 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:

WorkflowEntry triggersFirst step
/silver freeform intent, route, classify ROUTE → composed workflow
/silver:deep-research "how should we", "which technology", "compare X vs Y", "spike", "investigate", "architecture decision" silver:clarify → direct research by default → optional multi-AI only when explicitly requested → research artifact → handoff
/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 → silver:context
/silver:spec "write a spec", "acceptance criteria", "user stories", "formal spec" SPECIFY
/silver:ingest "JIRA", "Figma", "Google Docs", "Confluence", external artifact SPECIFY (ingest sub-step)
/silver:validate "validate spec", "validate plan", "gap analysis" VALIDATE
/silver:feature "add X", "build X", "implement X", "new feature", "enhance X", "extend X" silver:scan / silver:context → silver:clarify as needed
/silver:bugfix "bug", "broken", "crash", "error", "regression", "failing test", "not working" SB triage → silver:debug
/silver:ui "UI", "frontend", "component", "screen", "design", "interface", "page", "layout" silver:scan → silver:clarify → silver:ui-contract
/silver:fast "trivial", "quick fix", "typo", "one-liner", "config value", bounded dependency or small logic update Classify tier → silver:fast or silver:feature
/silver:test "write tests", "E2E", "test hardening", "fix tests" PLAN → EXECUTE → VERIFY
/silver:refactor "refactor", "rename", "split", "extract", behavior-preserving change PLAN → EXECUTE → VERIFY → post-exec gates
/silver:devops "infra", "CI/CD", "deploy", "pipeline", "terraform", "IaC", "kubernetes", "cloud", "ops" silver:scan → silver:blast-radius → optional DevOps skill router
/silver:deploy "deploy", "production deploy", "staging deploy", "rollout" BLAST_RADIUS → VERIFY → SECURE → SHIP
/silver:release "release", "publish", "version", "go live", "cut a release", "tag v", "ship to users" silver:quality-gates → SB UAT audit → SB milestone audit

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 messageRouteWhat 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 silver:ship Phase-level merge: push branch, create PR
No active phase, end of milestone silver:release Milestone publish
These are different scopes. silver:ship runs inside workflows as the final phase-level step (push → PR). silver:release is a dedicated milestone-level workflow that runs quality gates, UAT audit, milestone audit, security review, fresh tests, archival, 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

← Previous Core Concepts Next → Verification Before Completion