/silver:feature

Overview

/silver:feature is the Silver Bullet orchestrator for new feature development. It operates on composable flows architecture — rather than following a fixed pipeline, /silver classifies context, selects from the 18-flow catalog, and proposes a composition chain tailored to the request.

It never implements features directly — it orchestrates only. Implementation is delegated to GSD for lifecycle execution. SB owns gates and orchestration, and calls Superpowers or other helper plugins only at explicit boundaries selected by the active workflow. This separation keeps the orchestration layer clean and each specialist focused.

Invoked automatically by /silver when intent classification detects feature-development signals, or invoked directly as /silver:feature. See Composable Flows for the full 18-flow catalog.

Composable Flow Chain

Composition Proposal

When you invoke /silver:feature, the orchestrator classifies your context and proposes a path chain. For a typical feature request the proposed composition looks like:

• FLOW 0 (BOOTSTRAP) — orient in project state, resume from prior milestone if needed
• FLOW 1 (ORIENT) — codebase and project-state orientation
• FLOW 2 (CLARIFY) — scope clarification when intent is fuzzy
• FLOW 3 (DECIDE) — clarify, architecture decision, system design
• FLOW 4 (SPECIFY) — SPEC.md + REQUIREMENTS.md via silver:spec/silver:validate
• FLOW 5 (PLAN) — discuss phase, analyze dependencies, plan phase
• FLOW 7 (EXECUTE) — wave-based execution with atomic commits
• FLOW 9 (REVIEW) — multi-layer code review sequence
• FLOW 10 (SECURE) — security audit, threat mitigation verification
• FLOW 11 (VERIFY) — goal-backward verification, UAT
• FLOW 12 (QUALITY GATE) — 8 core quality dimensions plus conditional gates (pre-plan and pre-ship)
• FLOW 13 (SHIP) — PR creation, CI green
• FLOW 16 (DOCUMENT) — docs update, episodic memory

If the phase involves UI work, FLOW 6 (DESIGN CONTRACT) and FLOW 8 (UI QUALITY) are inserted automatically. If execution fails, FLOW 14 (DEBUG) is inserted dynamically.

Per-Phase Loop

For each phase, the orchestrator runs a tightly coupled loop: PLAN (FLOW 5) → EXECUTE (FLOW 7) → REVIEW (FLOW 9) → VERIFY (FLOW 11). This cycle repeats per phase until VERIFY passes two consecutive clean passes.

Supervision Loop

After each path completes, the supervision loop runs:

• Verify exit condition met (path contract satisfied)
• Evaluate whether the composition should change (dynamic insertions — e.g., add FLOW 14 if execution failed)
• Stall check — detect if the same path has been attempted 3+ times without progress
• Advance to next path in chain

When to use

Use /silver:feature when you want to add, build, implement, enhance, or extend any feature. Entry trigger signals:

• "add X" / "build X" / "implement X"
• "new feature" / "enhance X" / "extend X"
• Any description of new capability that touches business logic

If the request also touches UI, /silver:ui takes precedence — it is more specific. If something is broken, /silver:bugfix always takes precedence over this workflow.

Complexity triage

Before any workflow steps begin, /silver:feature classifies the request to prevent over-engineering trivial changes and under-engineering complex ones.

Workflow steps

Pre-flight

Silver Bullet reads silver-bullet.md §10 to load user workflow preferences before any step executes. Stored routing, skip, research-tool, and mode preferences are silently applied throughout the workflow.

Step 0 — Complexity triage

Classify the request (see table above). If trivial: invoke silver:fast and exit. If fuzzy: proceed to Step 1b. If simple or complex: proceed to Step 1a.

Step 1a — Codebase orientation

Invoke gsd-scan for rapid SB orientation. If this is a brownfield project or deeper structure mapping is needed, invoke /gsd:map-codebase for GSD-managed codebase mapping.

Step 1b — Fuzzy scope clarification (conditional)

Only if complexity triage found fuzzy intent or arguments are empty: invoke silver:clarify via the Skill tool for Socratic framing, option comparison, and decision-ready handoff before structured planning.

Step 1c — Optional research review (conditional)

Offered automatically when the change is architecturally significant (choosing between 2+ architectures, selecting a tech stack from scratch, domain is novel, change affects public API or data model). SB asks:

Note: this step informs the spec PRE-implementation. The optional cross-AI review inside Step 9 reviews completed code POST-execution. Both steps are independent.

Step 2 — Testing strategy

Invoke /testing-strategy. This MUST run after spec approval and before writing plans so test requirements are baked into the implementation plan.

Step 2.5 — Writing plans

Invoke the local /writing-plans helper only when SB needs a pre-GSD plan-shaping aid for complex scope. Otherwise, keep implementation planning inside gsd:plan-phase.

Step 3 — Pre-plan quality gates (8 core dimensions + conditional gates)

Invoke /silver:quality-gates. All applicable dimensions run, including the security dimension. If the feature touches infrastructure, route those infra concerns through the DevOps quality gate as well.

Step 4 — Discuss phase

Invoke gsd:discuss-phase. Adaptive questioning produces CONTEXT.md with locked decisions for the planner.

Step 5 — Analyze dependencies

Invoke gsd:analyze-dependencies. Maps phase dependencies before GSD creates the plan.

Step 6 — Plan phase

Invoke gsd:plan-phase. Produces PLAN.md with verification loop.

Step 7 — Execute phase

In Interactive mode (default): invoke gsd:execute-phase --tdd for implementation plans, or gsd:execute-phase without --tdd for config-only, docs-only, or infra-only plans. In Autonomous mode (§10e): invoke gsd:autonomous only when the underlying GSD TDD mode is already enabled. For behavior-changing code, the TDD boundary uses tdd before the execution wave starts.

Step 8 — Verify work

Invoke gsd:verify-work. UAT, must-haves, artifact checks. Phase is NOT complete until this passes. Non-skippable gate.

Step 8b — Test gap fill (conditional)

Only if gsd:verify-work surfaces coverage gaps: invoke gsd:add-tests to generate tests from UAT criteria.

Steps 9a–9d — Code review sequence

Run in order: /requesting-code-review → gsd:code-review → [if issues: gsd:code-review-fix] → [for arch-significant changes: gsd:review --all] → /receiving-code-review. The review-framing helpers run only because this SB review boundary selects them.

Step 10 — Secure phase

Invoke gsd:secure-phase. It verifies threat mitigations, secrets handling, and security-sensitive behavior for the completed phase. Non-skippable gate — cannot be bypassed via §10.

Steps 11–13 — Validate and pre-ship quality gates

Invoke gsd:validate-phase (Nyquist validation gap filling) → /silver:quality-gates again (8 core dimensions plus conditional gates). Pre-ship quality gates are non-skippable.

Steps 14–15 — Finishing branch and ship

Invoke /finishing-a-development-branch (superpowers:finishing-a-development-branch) → optionally gsd:pr-branch → gsd:ship. This is phase-level merge — not milestone-level publish (that is silver:release).

Step 16 — Episodic memory

Invoke episodic-memory:remembering-conversations to record key decisions and lessons from this feature.

Step 17 — Milestone completion (last phase only)

If this is the last phase of the milestone: run gsd:audit-uat → gsd:audit-milestone → gap-closure loop (max 2 iterations) → gsd:complete-milestone.

Non-skippable gates

Step-skip protocol

When you request skipping any workflow step, Silver Bullet follows this protocol:

1. Explains why the step exists (one sentence)
2. Offers: A. Accept skip   B. Lightweight alternative   C. Show me what you have
3. If you choose A permanently: records the decision in silver-bullet.md §10b and templates/silver-bullet.md.base §10b, then commits both files

Example invocation

Silver Bullet classifies this as Simple (clear scope, ≤1 phase), skips the extra clarification path, proceeds through orientation, quality gates, GSD discuss/plan/execute, TDD where applicable, review, verify, and ship.

Preferences

§10 routing preferences are loaded at pre-flight and silently applied throughout the workflow. Stored preferences include routing overrides, step skips, tool choices, research/review tool opt-in/out, and session mode (interactive vs autonomous).