Silver Bullet learns your preferences over time and records them in silver-bullet.md §10. Every preference requires your explicit confirmation before it is written.
Section §10 of silver-bullet.md is the preferences registry. It starts empty — all workflow defaults apply. Silver Bullet reads it at every relevant decision point and writes to it whenever you express a durable workflow preference.
silver-bullet.md and templates/silver-bullet.md.base in a single commit. This keeps project instances and the base template in sync.Routing preferences override the default workflow selection for a given work type. When you ask Silver Bullet to handle a request, it normally chooses the best workflow based on your description. A routing preference pins a specific workflow for a domain.
| Column | What it means |
|---|---|
| Work type | The category of request (e.g., "all UI tasks", "backend API work") |
| Override route | Which workflow to always use (e.g., silver:feature, silver:ui) |
| Since | Date the preference was recorded |
Example: if you always want UI changes to go through silver:ui even when your description sounds like a feature, you can record that preference once and Silver Bullet will route accordingly from then on.
When you ask to skip a workflow step, Silver Bullet does not skip silently. It follows the step-skip protocol every time:
Silver Bullet explains in one sentence why the step exists — what problem it solves and what risk skipping it creates.
You are presented with three lettered choices: A. Accept skip (once, permanently, or conditionally) B. Lightweight alternative (abbreviated version of the step) C. Show me what you have (proceed with the step as-is).
If you choose A and want it recorded permanently, Silver Bullet writes the preference to §10b — but only after showing you the exact diff and receiving your confirmation. See Recording a Preference below.
The §10b table captures each recorded skip:
| Column | What it means |
|---|---|
| Workflow | Which workflow the skip applies to (e.g., silver:fast, all workflows) |
| Step skipped | The step name or skill (e.g., /brainstorming) |
| Condition | When the skip applies (e.g., "always", "when no UI changes") |
| Since | Date recorded |
At certain decision points, Silver Bullet selects a research or analysis tool. Tool preferences let you pin your preferred tool for a given decision point instead of relying on automatic selection.
| Column | What it means |
|---|---|
| Decision point | Where the tool choice occurs (e.g., "technology research", "dependency comparison") |
| Preferred tool | The tool or skill to always use at that point |
| Since | Date recorded |
Example: you may prefer /silver:research over /brainstorming for technology spikes. Recording this preference means Silver Bullet routes all research decision points to silver:research automatically.
Some workflows can call optional research or review providers, including multi-AI research tools when installed. §10d records when those tools should be offered, auto-run, or skipped for a given trigger.
| Column | What it means |
|---|---|
| Trigger | The scenario that would invoke an optional research/review tool (e.g., architecturally significant changes, cross-AI review, technology selection) |
| Disposition | auto-offer (prompt the user) | auto-run (run without prompting) | skip (never offer) |
| Since | Date recorded |
For example, you can keep a multi-AI architecture review as auto-offer, set it to auto-run for high-risk architecture choices, or set skip for low-risk triggers where the extra review is not useful.
Mode preferences capture session-level defaults so you do not have to re-answer the same questions each session.
| Setting | Values | Default |
|---|---|---|
| Default session mode | interactive | autonomous | interactive |
| PR branch | ask | a branch name prefix | ask |
| TDD enforcement | per-plan-type | always | never | per-plan-type |
Default session mode is set during /silver:init and can be updated at any time. PR branch is captured the first time you create a PR — you can record your preferred prefix (e.g., feat/) so Silver Bullet never has to ask again. TDD enforcement controls whether test-driven development applies: the default is per-plan-type, meaning TDD runs for implementation plans but not config, infra, or doc plans.
Before any preference is written to §10, Silver Bullet must show you exactly what will change and receive your explicit confirmation. The display shows a diff of both files that will be updated:
The following text will be written to silver-bullet.md and templates/silver-bullet.md.base:
Type yes to confirm, or no to cancel.
You must type yes (or an equivalent affirmative). Silver Bullet does not accept vague approval — the confirmation must be explicit. Both files are updated in the same commit so the project and base template never diverge.
git log silver-bullet.md shows exactly when each preference was set and what it contains. You can revert any preference by editing §10 and committing.Three workflow gates are permanently enforced and cannot be added to §10b under any circumstances:
Security review is mandatory for every non-trivial change through gsd:secure-phase and the Security dimension inside /silver:quality-gates. It cannot be skipped, deferred, or treated as implicitly covered.
/silver:quality-gates pre-ship Cannot skipQuality gates must pass before shipping. The pre-ship quality gate run is separate from the pre-planning run and cannot be bypassed.
gsd:verify-work Cannot skipWork verification is required before completion can be declared. The completion audit hook blocks if this step is missing.
Attempting to add any of these to §10b will be rejected with an error. These gates exist because their failure modes are irreversible — skipping security review risks shipping vulnerabilities, and skipping verification risks incomplete or broken releases.