What Efficiency Means in v0.48.3
Silver Bullet is an APO — an orchestration and enforcement engine with catalog-backed lifecycle workflows. Efficiency comes from routing work to the smallest safe WF-* composition, keeping state in .planning/workflows/<id>.md, and applying only the AF-* gates the task actually needs.
That matters because the expensive failure mode in agentic development is not only token cost. It is doing the wrong amount of process: under-reviewing a risky change, over-processing a typo, losing traceability between spec and PR, or discovering after implementation that the plan never covered an acceptance criterion.
Workflow Fit Table
/silver composes from lifecycle workflows and optional extension plugins instead of forcing every request through one fixed pipeline.
| Work Type | Likely Route | Efficiency Gain |
|---|---|---|
| Typo, copy, config, rename | /silver:fast Tier 1 |
Avoids full planning while still confirming that scope is genuinely trivial. |
| Bounded small change | /silver:fast Tier 2 with SB flags |
Uses lightweight discussion, research, or validation only when signals require it, then escalates if scope grows. |
| Clear feature | /silver:feature with SB context, plan, execute, verify |
Keeps execution inside SB while applying pre-plan gates, artifact review, traceability, and pre-ship checks. |
| Fuzzy feature or new product idea | /silver:clarify or /silver:spec before planning |
Prevents premature implementation by producing explicit scope, assumptions, and acceptance criteria first. |
| External PRD, ticket, Figma, or Google Doc | /silver:ingest → spec artifacts → artifact review |
Preserves source context and marks missing connector data instead of silently inventing requirements. |
| Plan/spec mismatch risk | /silver:validate |
Finds uncovered acceptance criteria, open assumptions, and orphan plan tasks before implementation begins. |
| Bugfix | /silver:bugfix with debug and regression verification |
Spends process on root cause and regression prevention instead of broad feature planning. |
| UI/frontend work | /silver:ui with UI design contract and UI review |
Adds interface-specific design and visual checks that generic execution would miss. |
| Infrastructure, CI/CD, deployment | /silver:devops with blast-radius and IaC quality gates |
Uses risk and environment-promotion controls instead of application-only gates. |
| Release preparation | /silver:release |
Concentrates finalization, docs, CI, artifact alignment, and ship checks at the point they matter. |
Fast Path Without Silent Scope Creep
/silver:fast exists for low-risk and bounded work, but it is not a blanket bypass. Tier 1 runs the SB fast path; Tier 2 runs bounded SB quick handling with the right checks. If scope expands beyond the fast-path limits, the workflow escalates to silver:feature.
- Good fits: typo fixes, small copy updates, simple config values, one-line renames.
- Medium fits: small logic updates, dependency bumps, or 4–10-file changes where the impact is local and clear.
- Bad fits: schema changes, auth, infrastructure, cross-module behavior, new capabilities, or anything that grows past the original scope.
- The legacy trivial marker is guarded by
trivial-file-guard.sh; current Codex-oriented flows should use/silver:fastinstead.
Dependency Handling
Silver Bullet distinguishes optional enrichment from required execution dependencies. Optional tools can degrade gracefully when unavailable. Required dependencies fail closed so a workflow does not pretend a gate ran when the underlying skill or connector is missing.
The dependency-skill-check.sh hook enforces dependency-skill availability before dependent chains proceed. The ingestion workflow follows the same principle for external connectors: unavailable sources are recorded as explicit missing-artifact blocks rather than converted into hallucinated content.
Project Configuration
Project-level knobs live in .silver-bullet.json and SB planning configuration. They let the workflow match the project instead of forcing one universal setup.
| Config Surface | What It Controls |
|---|---|
.silver-bullet.json | Project defaults such as verification commands, source file patterns, required planning behavior, deployment checks, and semantic compression settings. |
.planning/config.json | SB workflow settings, review depth, project preferences, and other planning/runtime options owned by the active SB project. |
silver-bullet.md §10 | User workflow preferences: routing preferences, step-skip decisions, lightweight alternatives, and mode preferences recorded after explicit approval. |
What Is Not Claimed
Silver Bullet v0.48.3 does not provide a generic automatic model-routing advantage over host-native model controls. The historical ensure-model-routing.sh hook is disabled and exits as a no-op. Optional external plugins may expose model profiles or model overrides in their own configuration, but that is not a core Silver Bullet benefit.
When you need different model behavior, configure it in the active host or in an explicitly selected optional plugin. Silver Bullet's job is to select, enforce, and trace the workflow path around that execution.