/fix

name: fix
model: inherit
effort: high
agents: [explorer]
description: >
  Use to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's
  acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix through the
  same per-task gate implement uses, then patch the spec so the bug class can't silently return.
  Triggers on "fix {bug}", "fix the bug in {slug}", "bug in {feature}", "/sdd:fix {slug}",
  "regression in {slug}", "полагодь баг", "виправ багу", "регресія в {slug}", "чому зламалось".
  Triage is three-way: AC exists and is violated (regression) / AC is ambiguous (spec-bug —
  patch the wording) / no AC covers it (gap — add one, marked added-by-fix). Works on a repo
  with no specs at all (soft mode — code-first, recommends survey after). Writes a fix record
  under docs/features/{slug}/_fixes/ and commits the fix (SDD-Fix trailer), the record and any
  spec patch as separate commits.

Skill: fix

The **bugfix entry point** — the backbone in miniature, sized for «it's broken», not «build a feature». A bug is treated as **evidence about the spec**, not only about the code: either an acceptance criterion is violated (the code regressed), the AC was ambiguous enough to permit the behaviour (the spec is the root cause), or nothing covers it (a gap). So the fix always lands in two places — the **code** (RED → GREEN through the same gate `implement` runs) and the **spec** (a surgical AC patch) — tied together by a small fix record.

This skill keeps only its own machinery. Question phrasing → [`../_shared/ask-style.md`](../_shared/ask-style.md); RED-classification semantics → [`../implement/references/tdd-loop.md`](../implement/references/tdd-loop.md) (reused, never duplicated); dispatch policy → [`../_shared/agent-roster.md`](../_shared/agent-roster.md).

Fix-record prose follows `artifact_language` — but a **spec patch matches the existing spec's language** (the file wins over the setting); code, tests and commits stay English → [`../_shared/artifact-language.md`](../_shared/artifact-language.md).

Owner

The engineer on the bug (drives). PM / Tech Lead is consulted only when triage lands on «spec-bug» or «gap» — changing an AC is a product decision, not a code one.

Inputs

• `<slug>` — optional; pass it when you know which feature owns the bug, otherwise step 2 finds it from the symptom.
• The bug report, in any form — a sentence, a stack trace, a failing request, a screenshot description.
• **Soft gate (never hard-refuse):** `docs/features/` with ≥1 `spec.md`. Absent (a brownfield repo that never ran the backbone) → still run, in **no-spec mode**: steps 1 → 3 → 4 → record, skip the spec patch, and recommend `/sdd:survey` in the handoff.
• (Optional) `.claude/sdd.local.md` — gate command overrides; otherwise the commands are detected per `implement`'s cascade.

No depth dial and no `.size` here — a fix is one size, and the interview is the bug report itself.

Protocol

1. **Intake — reproduce before touching anything.** At most 1–2 `AskUserQuestion` (phrasing per [`../_shared/ask-style.md`](../_shared/ask-style.md)), only for what the report doesn't already say: expected vs actual, the steps, the scope (one user? all? since when?). Outcome: a one-line reproduction statement — «doing X, expected Y, got Z». A bug you can't state this way isn't ready to fix. 2. **Trace to spec (triage).** Grep `docs/features/*/spec.md` (+ the candidate slug's `_fixes/` for a recurrence) for the reproduction's domain terms; locate the owning slug and the closest §5 AC. In parallel, dispatch [`explorer`](../../agents/explorer.md) — `subagent_type: "sdd:explorer"` (fallback `Explore` / inline per [`../_shared/agent-roster.md`](../_shared/agent-roster.md)) — to localize the code path. Three outcomes (decision table → [`./references/triage.md`](./references/triage.md)):

• **(a) Regression** — an AC describes the expected behaviour and the code violates it. The spec is right; only the code changes.
• **(b) Spec-bug** — the AC exists but a reasonable implementer could read it and produce the observed behaviour. The wording is the root cause — the AC gets patched (with the user, step 5).
• **(c) Gap** — no AC covers the behaviour. A new AC is added to §5, marked `<!-- added-by-fix: <date> -->`.
• **No-spec mode** — no `docs/features/` (or no spec plausibly owns the symptom): skip the spec patch, say so in the record, recommend `survey`.

3. **RED — pin the bug with a failing test.** Write the **minimal** test that reproduces the bug at the level the behaviour implies (unit for a rule, integration for a dependency behaviour, e2e for a flow). Run it and classify the first run per [`../implement/references/tdd-loop.md`](../implement/references/tdd-loop.md) — it must be a **GOOD red** (fails on the assertion that encodes the *expected* behaviour); quote the failing line. A bug that can't be pinned by a test → STOP and say so — an unverifiable fix is a guess. 4. **GREEN + GATE — minimal fix.** Make the RED test pass with the smallest change; **no drive-by refactors** (anything the fix exposes goes to the record's follow-ups). Then the same per-task gate `implement` runs: unit + lint + vet (+ integration when available), via the detected commands (detection cascade → [`../implement/references/command-detection.md`](../implement/references/command-detection.md)). Red gate → fix it, never commit around it. 5. **Spec patch + fix record.** Apply the step-2 branch — (a) nothing to patch, re-verify the AC; (b) patch the AC wording; (c) add the new AC with the marker. **Any spec change is confirmed with the user** in one `AskUserQuestion` (before/after wording shown). Then write `docs/features/<slug>/_fixes/<date>-<short-slug>.md` from [`./templates/fix-record.md`](./templates/fix-record.md): symptom → root cause → the pinning test → the spec patch (or why there is none). 6. **Commit + handoff.** With the GATE green (this skill's structural s