Overview
/silver:fast is Silver Bullet's entry point for changes that don't need the full composable flows chain. It uses a 3-tier complexity triage to route each request to the right execution path — preventing both over-engineering trivial changes and under-engineering medium-complexity ones.
Invoked directly as /silver:fast, or by /silver when the request is clearly low-risk enough for fast-path triage. See Workflow catalog and Composable Flows.
Catalog entity WF-SILVER-FAST composes bounded Tier 2 work as:
Tier 3 escalations route to /silver:feature (WF-SILVER-FEATURE) for the full composition chain.
3-Tier Complexity Triage
| Tier | Signals | Route |
|---|---|---|
| Tier 1 — Trivial | ≤3 files, typo, config value, symbol rename, one-liner, comment update | Route directly through SB fast execution — one-shot handling, no planning overhead |
| Tier 2 — Medium | 4–10 files, clear scope, limited logic change, no cross-cutting concerns | Route through SB quick handling with flag composition: --discuss, --research, --validate, --full as needed |
| Tier 3 — Complex | Multi-file logic, architecture impact, cross-cutting concerns, or scope expands during execution | Autonomous escalation to /silver:feature via /silver reclassification — full WF-SILVER-FEATURE chain |
/silver:fast stops immediately, reports the expansion, and routes to /silver for full reclassification. No silent scope creep.
When to Use
Entry trigger signals for /silver:fast:
- "trivial" / "quick fix" / "typo" / "one-liner" / "config value"
- Small copy, config, rename, comment, dependency, or bounded logic updates
- Automatically invoked by
/silverwhen the request is clearly safe for fast-path triage
Scope Limit
/silver:fast is not a bypass for complex work. Tier 1 is limited to ≤3 files with no logic change. Tier 2 can handle 4–10 files, small logic changes, or dependency updates. Anything cross-cutting, schema-affecting, capability-creating, or larger than 10 files escalates to /silver:feature.
Workflow Steps
Pre-flight: banner only
Displays a fast-path banner. No preference loading (intentional).
Tier triage (autonomous)
SB classifies the request before choosing an execution engine:
Ambiguity always moves to the safer higher tier. There is no manual step-skip preference loading in this workflow.
Step 1 — Tier 1 execution
If the request is truly trivial, invoke SB fast execution with the change description. After execution, run the scope expansion check.
Step 2 — Tier 2 execution
If the request is bounded but no longer trivial, detect the required SB quick-handling flags:
--discussfor ambiguity, tradeoffs, or multiple approaches--researchfor new libraries, unfamiliar domains, or investigation-heavy work--validatefor production code changes that need explicit validation--fullwhen all three signals apply
Any deferred items discovered during Tier 2 execution are filed through /silver:add.
Step 3 — Scope expansion check
After Tier 1 or Tier 2 execution, SB checks the actual modified scope. Tier 1 expands to Tier 2 when it touches 4–10 files, and Tier 1 or Tier 2 escalates to /silver:feature when it exceeds 10 files or becomes cross-cutting.
Step 4 — Verify and confirm
Run the verification command surfaced by the selected SB path. SB then displays the classification, execution route, files modified, verification result, and commit status.
When NOT to use
Do not use /silver:fast for:
- Anything expected to touch more than 10 files
- Cross-cutting business logic or multi-module behavior
- Dependency changes with broad runtime, security, or compatibility impact
- Schema changes (database, API, config format)
- Changes with downstream impact on other systems
- Security-related changes
If in doubt, use /silver instead — it will run complexity triage and choose the right workflow.
Example Invocation
Silver Bullet classifies this as Tier 1, uses SB fast execution, verifies the README update, confirms the file count stayed inside the trivial boundary, and commits the change.