git:20261023.8d2dc7f to git:20261028.823358d

4 added, 4 removed. Audit A to A.

---

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

---

# 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 (in autonomous mode, retry once with evidence the first run lacked: the failing CI run logs, the exact branch and command, and the recent-change diff; if none of that exists, stop and report what is missing). If it still cannot reproduce after a second attempt, report that honestly rather than shipping a speculative change; in autonomous mode that report is the end of the run, not a question.

## 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 RED step and record why in the report. 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. **Gate, then review once.** Run the `task-gate` before declaring the fix done, including for 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. The gate runs the repository's declared deterministic checks; a `FAIL` goes back to the fix with the failing gate ids attached. The Test-contract row with matching RED/GREEN evidence from steps 1 and 3 must be present; if RED was never established, that is a `test-dev` task to establish it. `code-reviewer` reviews the finished fix once, before it ships, and never a single task along the way.

+ 4. **Run record, docs-dev review, gate, then review once.** Keep a run record of asked/decided+why/files changed; no transcripts. After verification and before review, dispatch a docs-dev review and require its outcome in the closeout evidence. Run the `task-gate` before declaring the fix done, including for 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. The gate runs the repository's declared deterministic checks; a `FAIL` goes back to the fix with the failing gate ids attached. The Test-contract row with matching RED/GREEN evidence from steps 1 and 3 must be present; if RED was never established, that is a `test-dev` task to establish it. `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`** with the investigator's full findings, any failed attempts, and the tripwires that fired. It plans; you never plan. The plan defaults to `development-mode: test-first`; pass `standard` only when the human explicitly opts out.

2. **Persist the plan.** The architect writes beneath the directory declared by **<plan-index>** in the repository root Config Reg. Relay its decision digests and final **approve and execute** gate; do not implement while the artifact is Draft. Resolve `autonomy` as `conductor` does (a prompt `autonomy: supervised|autonomous`, then the value declared as **<autonomy>** in the repository root `AGENTS.md` Config Reg, then `supervised`) and pass it to `architect`. In autonomous mode record each accepted recommendation and the final **approve and execute** in the plan's `## Decisions` table as `autonomous: recommendation accepted`, and relay only an `ESCALATION: hard_block` item.

3. **Relay blockers.** The architect owns discovery and its discovery delegates. If it returns `STATUS: BLOCKED` or `STATUS: PLAN_WRITE_ERROR`, relay the exact evidence and stop rather than filling the gap yourself.

- 4. **Relay decisions to the human.** When the architect ends a turn with `STATUS: NEEDS_DECISION`, surface every grouped question with its `RECOMMENDED` option first, then re-invoke it with the answers keyed by question id. You relay; you do not answer on the human's behalf. In autonomous mode accept the `RECOMMENDED` option, including on an `ESCALATION: hard_block` that carries one (only `RECOMMENDED: none` reaches the human), and reject a hard-block escalation missing `SOURCES_SEARCHED`, `COST_OF_WRONG`, or a `RECOMMENDED` option, sending it back to `architect` ONCE to be REPAIRED (supply the missing fields, same question, same ids). If the repaired block is still incomplete or `architect` cannot name sources and the cost of being wrong, it is not a hard-block escalation: `architect` decides it as `autonomous: low-confidence, no authoritative source`. Never ask the human for a malformed block. A hard stop stays human: an unresolvable `STATUS: BLOCKED` or `PLAN_WRITE_ERROR`, and merge, publish, delete, or spend. In autonomous mode, deliver only as the autonomy contract directs (on `APPROVE`, or a parked `NEEDS_HUMAN` or parked exhausted-`REQUEST_CHANGES` per the autonomy contract; never with open `REQUEST_CHANGES`): commit to a feature branch, push it, and open a draft pull request assigned to the invoking user (and request reviewers when the repository names them), listing in the description every `autonomous: low-confidence` decision, the count of auto-approved gates, and any parked change (`NEEDS_HUMAN` or exhausted `REQUEST_CHANGES`); never merge.

- 5. **Execute the Ready plan.** Route each task to its specialist by matching against the live agent descriptions, run independent tasks concurrently, and require each worker's `TASK_GATE:` line in its digest. Pass the plan's development mode and matching Test or verification contract. A failing gate returns to the same worker; a tripped circuit-breaker enters the findings collection. Judgement about overall code quality belongs to one `code-reviewer` run over the accumulated change. If the escalated work grows into a feature, hand the Ready artifact to `conductor` when the human agrees the scope has changed.

+ 4. **Relay decisions to the human.** When the architect ends a turn with `STATUS: NEEDS_DECISION`, surface every grouped question with its `RECOMMENDED` option first, then re-invoke it with the answers keyed by question id. You relay; you do not answer on the human's behalf. In autonomous mode accept the `RECOMMENDED` option, including on an `ESCALATION: hard_block` that carries one (only `RECOMMENDED: none` reaches the human), and reject a hard-block escalation missing `SOURCES_SEARCHED`, `COST_OF_WRONG`, or a `RECOMMENDED` option, sending it back to `architect` ONCE to be REPAIRED (supply the missing fields, same question, same ids). If the repaired block is still incomplete or `architect` cannot name sources and the cost of being wrong, it is not a hard-block escalation: `architect` decides it as `autonomous: low-confidence, no authoritative source`. Never ask the human for a malformed block. A hard stop stays human: an unresolvable `STATUS: BLOCKED` or `PLAN_WRITE_ERROR`, and merge, publish, delete, or spend. In autonomous mode, deliver as the autonomy contract directs: commit to a feature branch, push it, and open a draft pull request assigned to the invoking user (and request reviewers when the repository names them). The draft is marked ready once required CI passes. List in the PR description every `autonomous: low-confidence` decision, the count of auto-approved gates, and every `NEEDS_HUMAN` or open circuit-breaker item as pending human review; none of these blocks delivery. Never merge.

+ 5. **Execute the Ready plan.** Route each task to its specialist by matching against the live agent descriptions, run independent tasks concurrently, and require each worker's `TASK_GATE:` line in its digest. Pass the plan's development mode and matching Test or verification contract. A failing gate returns to the same worker; a tripped circuit-breaker enters the findings collection. Keep a run record of asked/decided+why/files changed; no transcripts. After verification and before delivery, dispatch a docs-dev review and require its outcome. Judgement about overall code quality belongs to one `code-reviewer` run over the accumulated change. If the escalated work grows into a feature, hand the Ready artifact to `conductor` when the human agrees the scope has changed.

## 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.

+ 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. Include the run record and the docs-dev review outcome in the report and the pull request description. 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.