Silver:Fast

---
name: silver:fast
description: >
  This skill should be used for 3-tier complexity triage: trivial → direct SB edit, medium → SB context/plan/execute/verify, complex → silver:feature escalation.
argument-hint: "<description of change>"
version: 0.1.0
---

# /silver:fast — Complexity Triage (composition spec)

SB triage spec for parent orchestrator. **Tier 1** still routes to a FAST worker (not parent edits). Tier 2+ escalates to fuller composer queues.

| Tier | Criteria | Routes to |
|------|----------|-----------|
| **Tier 1 (Trivial)** | ≤3 files AND no logic changes AND no `src/`/app code paths | parent spawns FAST worker |
| **Tier 2 (Medium)** | 4-10 files OR logic change in ≤3 files OR dependency update | `silver:quality-gates` (pre-plan), `silver:plan`, `silver:validate`, `silver:execute`, `silver:verify`; optional `silver:context` / `silver:deep-research` when signals match |
| **Tier 3 (Complex)** | >10 files OR cross-cutting OR schema change OR new capability | silver:feature |

> **Note:** Tier 2+ fast-path work starts a lightweight workflow tracker (`scripts/workflows.sh start /silver:fast ...`) so `workflow-chain-guard` and delivery gates can observe the path. Tier 1 remains direct edit with verification only.

## Pre-flight: Banner

Display banner:

```
SILVER BULLET ► FAST PATH

Change: {$ARGUMENTS or "(not specified)"}
```

## Step 0: Complexity Triage

Analyze $ARGUMENTS to classify into one of three tiers. Classification is **autonomous** — no interactive user prompt.

**Tier 1 (Trivial):**
- ≤3 files AND no logic changes AND no edits under configured `src_pattern` paths (typically `src/`, `hooks/`, `scripts/`, `lib/`, `app/`)
- Indicators: typo, config value in non-code files, rename, comment-only update, one-line text fix in docs
- **Never Tier 1:** any `.py`, `.ts`, `.js`, `.go`, `.rs`, `.sh`, `.rb`, `.java`, `.kt`, `.swift`, `.tf`, `.hcl` logic change
- Proceed to Step 1

**Tier 2 (Medium):**
- 4-10 files OR logic change in ≤3 files OR dependency update
- Indicators: small feature addition, refactor, bug fix with tests, dependency bump, multi-file rename
- Proceed to Step 2

**Tier 3 (Complex):**
- >10 files OR cross-cutting concern OR schema change OR new capability
- Indicators: new feature, architecture change, database migration, API redesign, multi-component work
- Proceed to Step 3

**Ambiguity rules (always bias toward the safer/more thorough tier):**
- Ambiguous between Tier 1 and Tier 2 → classify as Tier 2
- Ambiguous between Tier 2 and Tier 3 → classify as Tier 3
- Cannot determine scope from description alone → classify as Tier 3

Display classification:

```
Classification: Tier {N} ({Trivial|Medium|Complex})
  Routing to: {direct SB edit|SB lifecycle slice|silver:feature}
```

## Step 1: Tier 1 — Execute Directly

**Only reached when Step 0 classifies as Tier 1 (Trivial).**

Make the small edit directly in the current session. Keep the change to the classified trivial scope and run the smallest relevant verification.

After the trivial edit and verification complete, run scope expansion check (Step 4).

**Tier 1 discipline:** Do not misclassify logic changes as trivial to bypass workflow tracking. The `$HOME/.claude/.silver-bullet/trivial` marker only applies to genuine typo/config-only sessions; any src logic change requires Tier 2+ or `silver:feature`.

**Trivial bypass mid-session:** SessionStart clears any stale `$HOME/.claude/.silver-bullet/trivial` marker; the first Write/Edit removes it if recreated (`PostToolUse` hook). If you start Tier 1 then expand scope into logic changes, workflow-chain-guard and delivery gates apply normally. Re-classify as Tier 2+ and start `scripts/workflows.sh start /silver:fast` before further implementation edits.

If scope remained ≤3 files, display completion banner:

```
SILVER BULLET ► FAST PATH COMPLETE

Change: {$ARGUMENTS}
Files modified: {count} (confirmed ≤3)
Status: verified
```

## Step 2: Tier 2 — Detect gates and route to SB lifecycle slice

**Only reached when Step 0 classifies as Tier 2 (Medium).**

Before invoking SB lifecycle skills, detect which gates to apply by scanning $ARGUMENTS for signals:

**Signal detection:**

| Gate | Signal words in $ARGUMENTS |
|------|---------------------------|
| `silver:context` | "not sure", "unclear", "multiple approaches", "options", "decide", "which", "should we", "trade-off", "either...or" |
| `silver:deep-research` | "new library", "unfamiliar", "investigate", "evaluate", "compare", "never used", "first time", "unknown", "explore options" |

**Gate composition rules:**
- Any combination is valid.
- Always invoke `silver:plan`, `silver:validate`, `silver:execute`, and `silver:verify` for Tier 2.
- Invoke `silver:quality-gates` (pre-plan design-time) before planning when starting the Tier 2 tracker — `workflow-chain-guard` enforces this marker.
- When `.planning/SPEC.md` is absent, `silver:validate` runs in **plan-only mode** (PLAN.md completeness — see `skills/silver-validate/SKILL.md` Step 0). Do not run `/silver:spec` unless product requirements need a formal SPEC.
- Invoke `silver:context` or `silver:deep-research` only when triggered by the signal table above.
- `workflow-chain-guard` for Tier 2 requires `silver-quality-gates` (design marker), `silver-plan`, and `silver-validate` before implementation edits — not `silver-context`.

Display detected signals:

```
Detected signals:
  Ambiguity: {yes/no} {reason if yes}
  Novel domain: {yes/no} {reason if yes}
Gates: {silver:context silver:deep-research | (none)} + silver:plan silver:validate silver:execute silver:verify (always)
```

Invoke the selected SB lifecycle slice with $ARGUMENTS.

**Workflow tracker (Tier 2 — mandatory):** Before the first implementation edit, start the fast-path workflow tracker:

```bash
if [[ -x scripts/workflows.sh ]]; then
  SB_WORKFLOWS_BIN="scripts/workflows.sh"
else
  SB_WORKFLOWS_BIN="$(
    for root in \
      "$HOME/.claude/plugins/cache/alo-labs/silver-bullet/current" \
      "$HOME/.claude/plugins/cache/alo-labs/silver-bullet/current"; do
      if [[ -x "$root/scripts/workflows.sh" ]]; then
        printf "%s\n" "$root/scripts/workflows.sh"
        break
      fi
    done
  )"
fi
if [[ -n "${SB_WORKFLOWS_BIN:-}" ]]; then
  SB_WORKFLOW_ID=$("$SB_WORKFLOWS_BIN" start /silver:fast "$ARGUMENTS" "QUALITY GATE,plan,validate,execute,verify")
  export SB_WORKFLOW_ID
fi
```

After each invoked lifecycle skill completes, run `"$SB_WORKFLOWS_BIN" complete-flow "$SB_WORKFLOW_ID" "<skill-name>"`.

After the SB lifecycle slice completes, run scope expansion check (Step 4).

### Tier 2 delivery (deploy gap — important)

The Tier 2 slice (`quality-gates → plan → validate → execute → verify`) intentionally stops at
verification. It does **not** record the post-execution deploy chain
(`silver:review-request`, `silver:review`, `silver:review-triage`, `silver:secure`,
`silver:validate`, `silver:branch-finish`, `silver:ship`).

Consequences and routing:

- **Local / no-delivery work:** if the Tier 2 change is not being pushed to a PR,
  release, or deploy, stop at `silver:verify` — the Stop gate only requires the
  planning floor, so this completes cleanly.
- **Delivery required (PR / release / deploy):** the completion-audit deploy gate
  enforces the full `required_deploy` list. A bare Tier 2 slice will be **blocked**
  at `gh pr create` / `gh release create` / `deploy` because the review, security,
  validate, branch-finish, and ship markers are missing. Before raising a PR you
  MUST either:
  - **(a)** complete the remaining deploy chain in order (canonical post-execution
    sequence — same as `silver:feature`) —
    `silver:review-request → silver:review → silver:review-triage → silver:verify →
    security → silver:secure → silver:validate → silver:quality-gates →
    silver:branch-finish → silver:completion-audit → silver:ship` — then deliver, or
  - **(b)** escalate to `silver:feature` (Step 3), which owns the full lifecycle and
    deploy chain end-to-end.

Do not attempt to bypass the deploy gate by editing state files or skipping skills.

### Deferred-Item Capture (Tier 2 only)

After Tier 2 execution, any item scoped out during execution MUST be filed via `/silver:add`:

```
Skill(skill="silver:add", args="<description of deferred item>")
```

**Note:** Tier 1 (trivial changes) → no capture needed. Tier 3 → escalates to `/silver:feature`, which handles its own deferred-item capture.

## Step 3: Tier 3 — Escalate to silver:feature

**Only reached when Step 0 classifies as Tier 3 (Complex).**

Display:

```
Change exceeds fast-path complexity. Routing to silver:feature.
Reason: {specific reason — e.g., "touches >10 files", "cross-cutting concern", "schema change", "new capability"}
```

Invoke `silver:feature` through the active runtime's SB-recognized skill invocation channel with $ARGUMENTS. Exit silver:fast.

## Step 4: Scope Expansion Check

After Tier 1 or Tier 2 execution completes, check if scope expanded beyond the current tier.

**During Tier 1:** If files modified > 3:
- If 4-10 files → escalate to Tier 2 (SB lifecycle slice, Step 2)
- If > 10 files → escalate to Tier 3 (silver:feature, Step 3)

**During Tier 2:** If files modified > 10:
- Escalate to Tier 3 (silver:feature, Step 3)

Escalation is **autonomous** — no interactive user prompt needed. Display escalation banner:

```
FAST PATH ESCALATION

Reason: Scope expanded from {original tier} to {new tier}
Files affected: {count}
Routing to: {SB lifecycle slice|silver:feature}
```

Then invoke the target workflow. On escalation to silver:feature, pass the updated scope description so /silver can classify appropriately.