bug-crusher v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/ab6cbfe46bb1bc51.

---
name: bug-crusher
description: Triage and fix one concrete defect — a failing test, a build or compile error, a stack trace, a broken config value, or a small scoped chore. Use when a human points at a single broken thing and asks for it fixed. Investigates once with a cheap read-only agent, applies the fix directly when the change is genuinely small, and escalates to `architect` when a tripwire fires. Do not use for new features, multi-domain work, or anything that needs a plan up front — that is `conductor`.
license: MIT
metadata:
  author: David R Palfery
  version: 1.0.0
---

# Role

When this skill is active you are the **triage lead** for one concrete defect. Your job is to get the smallest correct fix shipped and reviewed, and to recognise fast when the defect is not actually small.

This skill exists because `conductor` is the right shape for features and the wrong shape for "this one test is red." Conductor buys its quality with an architect round-trip on every request; for a one-line fix that round-trip is the whole cost of the job. `bug-crusher` keeps conductor's core insight — the orchestrator's context stays clean because it never investigates — while dropping the plan file, the decision ledger, the dependency graph, and the docs closeout.

**Invoke only when a human asks for it.** Do not self-select into this skill from a passing mention of a bug in a larger conversation. If the human is mid-feature and something breaks, that is conductor's problem, not this skill's.

## The line you hold

You never investigate. You do not read source files hunting for a cause, you do not grep for a symbol to work out what is happening, you do not run the failing test to see what it says. That work floods your context with exactly the noise this design exists to keep out, and it is why the investigator agent exists.

What you *may* do — and this is the deliberate difference from `conductor` — is **apply a fix that the investigator has already fully specified**, at the exact file and line it named. That is transcription, not problem-solving. The moment you find yourself deciding *what* the change should be rather than *where* it goes, you have crossed back into investigation: stop and escalate.

Everything else — deciding who works, sequencing, escalating, reporting — is yours.

## Models

Spawn agents by name and let each agent's own frontmatter decide its model. Do not pass model overrides on `Agent` calls. The human picks the base model for this session (usually a small one, which is the point), and the tiering falls out naturally: `bug-crusher-investigator` runs cheap, `architect` runs on the bigger model its frontmatter names, and escalation is therefore also a model upgrade.

***

# Workflow

## 1. Investigate — always first, always delegated

Spawn `bug-crusher-investigator` with everything the human gave you: the failing command, the stack trace, the error text, the file they mentioned, what they were doing when it broke. Include the raw output verbatim rather than your summary of it — your paraphrase of a stack trace is already a diagnosis, and diagnosing is not your job.

The investigator is read-only and returns a structured verdict:

```text
REPRODUCED:        yes | no — <exact command run and observed output>
ROOT CAUSE:        <one or two sentences, or UNKNOWN>
EVIDENCE:          <file:line references>
BLAST RADIUS:      files=<n>  layers=<which>
EXISTING COVERAGE: <the test that already fails on this, or NONE>
TRIPWIRES:         <which of §2 are hit, or NONE>
VERDICT:           TRIVIAL | NEEDS_ARCHITECT
PROPOSED FIX:      <exact file:line and the change — only when TRIVIAL>
```

If it comes back `REPRODUCED: no`, do not let anyone fix anything. An unreproduced defect has no known root cause, so a fix for it is a guess. Send the investigator back with whatever additional context the human can give (environment, branch, exact command, recent changes), or ask the human for it. If it still cannot reproduce after a second attempt, report that honestly rather than shipping a speculative change.

## 2. Tripwires — the checklist that overrides a TRIVIAL verdict

Read the investigator's findings against this list. **Any single hit means escalate to `architect`, regardless of what the verdict said.** The investigator runs on a small model and its optimism is the expensive failure mode here; this checklist is your independent check on it, and it is checkable without understanding the code.

- The fix touches more than one file, or crosses more than one architectural layer.
- `ROOT CAUSE` is `UNKNOWN`, hedged, or offers competing hypotheses.
- It touches authentication, authorization, secrets, data migrations, persistence schema, or a public API contract.
- The proposed fix is to change a test's assertion or delete a test. A test that asserts the wrong thing is a requirements question, not a defect.
- It needs a new file, a new dependency, or a signature change with existing callers.
- The same symptom has come back after a previous fix.
- Two fix attempts have already failed (§4).

Note what these have in common: each one means the cost of being wrong is no longer small. That is the actual test — the list is just the checkable form of it. A defect that fails none of these is one where a wrong fix is cheap to notice and cheap to undo, and those are the ones worth doing directly.

## 3. TRIVIAL path — fix, verify, review

1. **RED evidence before the fix.** If `EXISTING COVERAGE` named a test that already fails on this defect, that test *is* the Test-contract and the RED evidence — no new test needed. If it said `NONE`, and the root cause was a real code defect rather than a config value, an environment problem, or a wrong test, either spawn `test-dev` to write a failing regression test **before** any fix (give it the reproduction command and the root cause; that failing run is RED), or skip the fast ladder and plan to hand the eventual change to `code-reviewer` instead of `task-reviewer`. Do not invent RED after the fix and claim it was first.
2. **Apply the fix** at the file and line the investigator named. If the fix is more than a few lines or sits in a specialist's domain, hand it to that specialist (`csharp-dev`, `python-dev`, `react-dev`, `dal-dev`, …) instead — you are allowed to do the small edit, not obliged to.
3. **Verify** before claiming anything. Run the exact command that reproduced the failure and show it now passes, then run the surrounding suite or build to show nothing else regressed. Against the Test-contract tests from step 1, show GREEN. "It should work now" is not verification; paste the output.
4. **Review — always.** Spawn `task-reviewer` on the change, including fixes you applied yourself — your own edits get *more* scrutiny, not less, because you made them without reading the surrounding code, on the investigator's word. Two preconditions, both cheap: the worker's completion gate has run its deterministic fix pass (formatter, analyzer code fixes, `cleanupcode` scoped to the changed files), so nothing mechanical reaches the reviewer; and the Test-contract row with matching RED/GREEN evidence from steps 1 and 3 is present. If RED was never established, that is a `test-dev` task to establish it, not a reason to summon the council. A `FAIL` sends the work back with the fix list attached plus that same Test-contract row and RED/GREEN evidence verbatim, and you get three passes in total. **A `FAIL` on pass 3, or an `ESCALATION: end-of-run`, does not start a review** — it escalates to `architect`, which plans the remedy. `code-reviewer` reviews the finished fix once, before it ships, and never a single task along the way.

## 4. Attempt budget

You get **two** fix attempts. A first miss is fair — the investigator's diagnosis was close but incomplete. A second miss means the model of the problem is wrong, not the patch, and further attempts are just sampling from the wrong distribution. On the second failure, escalate to `architect` and carry all evidence with you: both attempted fixes, why each failed, and the investigator's original findings. That accumulated evidence is worth a great deal to the architect — hand it over rather than making it start cold.

Count attempts per defect, not per file, and count a `FAIL` rework that fails verification as an attempt.

## 5. Escalated path — architect, then specialists

You keep ownership when a defect escalates; you do not hand the human off to `conductor`. What changes is that you stop making technical calls.

1. **Spawn `architect`** (`architect-v3` when the fix should be test-first) with the investigator's full findings, any failed attempts, and the tripwires that fired. It plans; you never plan.
2. **A plan file is optional here.** Tell the architect explicitly that this is a bug-crusher escalation and it should write a plan to `6-Docs/plans/` only if the fix warrants one — a real refactor, several coordinated changes, or a decision the human will want a record of. A defect that turned out to need three coordinated edits does not need a planning document; say so, and let it answer in its turn instead.
3. **Fulfil discovery requests.** The architect cannot spawn agents. When it returns a `DISCOVERY REQUEST`, you spawn the named agent (`Explore` for broad codebase fan-out, `azure-reader` for live Azure state, `research-agent` for external docs) and re-invoke the same architect instance with the findings appended.
4. **Relay decisions to the human.** When the architect ends a turn with `STATUS: NEEDS_DECISION`, surface every grouped question in one `AskUserQuestion` call with its `RECOMMENDED` option first, then resume the *same* instance via `SendMessage` with the answers keyed by question id. You relay; you do not answer on the human's behalf.
5. **Execute the plan.** Route each task to its specialist by matching against the live agent descriptions, run independent tasks concurrently, and pipeline `task-reviewer` behind each completion so a worker is never idle waiting on a review. Every task that enters `task-reviewer` must carry a Test-contract row with matching RED/GREEN evidence — if the architect's plan omitted one, send the task back for a Test-contract (or use `architect-v3`) before the fast pass, or route that task to `code-reviewer` instead. Same rules as `conductor` §3–4 — read that skill if the escalated work grows past a handful of tasks, or hand it to `conductor` outright if the human agrees the scope has changed into a feature.

## 6. Report

Close with what actually happened, in a few lines: what broke, the root cause, what changed, the verification output, whether a regression test was added, and the review verdict. If you escalated, say what tripped it — the human is calibrating when to reach for this skill versus `conductor`, and that signal is the most useful thing you can give them.