Overview
/silver:research is the Silver Bullet orchestrator for technology decisions, architecture spikes, tech comparisons, and competitive intelligence. Research always precedes implementation — findings are written to .planning/research/ and referenced by the receiving workflow.
It never treats ad hoc reasoning as the workflow. It clarifies the decision, selects a research path, invokes the configured research provider when available, produces a traceable artifact, and then hands off to the appropriate implementation workflow.
silver:research uses composable flows architecture — it composes only the flows needed for pre-implementation discovery. Typical path: FLOW 2 (CLARIFY) → FLOW 3 (DECIDE) → FLOW 4 (SPECIFY) when the research should become a spec. After research completes, it can hand off to silver:feature, silver:ui, silver:devops, or gsd:do. See Composable Flows for the full catalog.
silver:research takes precedence over any other matched workflow — research informs the implementation workflow. If an instruction matches both research and implementation, run research first, then hand off.
When to use
Entry trigger signals for /silver:research:
- "how should we" / "which technology" / "compare X vs Y"
- "spike" / "investigate" / "architecture decision"
- "should we use" / "what's the best approach for"
- Any request where you need information before you can plan an implementation
When Research Tools Are Auto-Offered
Silver Bullet proactively offers deeper research or multi-perspective review when:
- Choosing between 2 or more fundamentally different architectures
- Selecting a technology stack from scratch (no prior art in
.planning/) - Domain is novel — no prior intel in
.planning/and no comparable existing code - Change affects a public API or data model fundamentally
Workflow steps
Pre-flight
Silver Bullet reads silver-bullet.md §10 to load user workflow preferences before any step executes.
Step 1 — Clarify research question
Invoke /silver:clarify. Purpose: Socratic clarification — precisely define the research question before choosing the research mode. This prevents running the wrong research path on an ambiguous question.
Step 2 — Choose research path
SB asks which type of research question this is (or infers from context):
- A. Market/landscape — "What tools/solutions exist for X?", "What's the state of the art?"
- B. Tech selection — "Should we use X or Y?", "Which library/framework is best for our case?"
- C. Competitive/product intelligence — "How do competitors solve X?", "What can we learn from product Y?"
Research paths
Path 2a — Market/landscape research
Run the configured landscape research provider, then consolidate the findings into a decision-ready artifact. Output is written to .planning/research/<date>-<topic>/landscape-report.md.
Path 2b — Tech selection research
Run the configured comparison path: gather multiple perspectives, evaluate the options against weighted criteria, and consolidate a recommendation. Output is written to .planning/research/<date>-<topic>/comparison-report.md.
Path 2c — Competitive/product intelligence
Run the configured product or competitive-intelligence path to identify how other products solve the problem, what gaps exist, and what can be adapted. Output is written to .planning/research/<date>-<topic>/competitive-intelligence-report.md.
Step 3 — Apply research to engineering design
Invoke /silver:clarify again with the research artifact as primary context. Purpose: turn findings into a decision-ready handoff that the implementation workflow can absorb.
Step 4 — Handoff to implementation workflow
After research completes, SB asks which workflow should receive the findings:
- A. silver:feature — build a new feature based on research findings
- B. silver:ui — product or interface work based on research findings
- C. silver:devops — infrastructure/deployment change based on research findings
- D. gsd:do — delegate to GSD for lifecycle-owned project work
- E. Done — research-only engagement, no implementation needed
If the research continues into implementation, the artifact path (.planning/research/<date>-<topic>/) is passed as context so downstream GSD discussion, planning, and verification can reference it. Research lineage is always preserved.
Example invocation
Silver Bullet routes to research. /silver:clarify clarifies the question. Path 2b is selected. The configured research path produces perspectives, comparison criteria, and a recommendation artifact. /silver:clarify synthesizes the artifact into a decision-ready handoff. The result can then be routed to /silver:feature, /silver:ui, /silver:devops, or /gsd:do.