claude/agents/bugfixer.md
bastien 6e322db968 feat(capitalize): add CAPITALIZE step across completion skills
Registries only get filled if something actively writes to them.
Without integration, the 3-question ritual is aspirational text.
Adds a CAPITALIZE step at the end of every completion skill so work
milestones automatically propose BDR/LRN/BLK entries from context.

- ship-feature STEP 9 — decision/learning/blocker candidates per feature
- bugfix STEP 7 — always propose BLK with root cause; LRN if pattern reusable
- hotfix STEP 5 — default skip; only prompt when non-obvious lesson surfaces
- feat STEP 6 — propose BDR for design choice, LRN for pattern
- commit-change Phase 4 — analyze the commit batch, propose grouped entries

Every variant also appends a one-liner to .claude/memory/journal.md under
today's date heading.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-23 16:06:24 +02:00

165 lines
4.9 KiB
Markdown

---
name: bugfixer
description: Structured bug fix with root cause investigation. Hypothesis-driven investigation, diagnosis, fix plan, and minimal scoped fix with regression test.
tools: Read, Edit, Write, Bash, Grep, Glob, Agent
---
# BUGFIX — Structured Bug Fix
Investigate, understand, plan, fix. No guessing. The iron law:
understand the root cause before writing a single fix.
## REQUEST
$ARGUMENTS
---
## STEP 1 — GATHER CONTEXT
Understand the current state:
```bash
git status
git log --oneline -5
```
Read the error message, stack trace, or bug description.
Identify:
- **What** is broken (symptom)
- **Where** it manifests (file, line, endpoint, UI element)
- **When** it started (recent commit? always? after a deploy?)
```bash
# If the user mentions "it was working before":
git log --oneline -20 --all -- <suspected files>
```
## STEP 1.5 — DESIGN GATE
Follow `$HOME/.claude/lib/design-gate.md`:
- Scan $ARGUMENTS and target files for design/UI/style signals (CSS, component, layout, animation).
- If signals found and `ui-ux-pro-max` inactive → ask user to activate.
- If no signals → skip (zero overhead).
## STEP 2 — INVESTIGATE
Trace the bug from symptom to root cause:
1. Read the code path involved (follow the data flow).
2. Check recent changes to the affected files:
```bash
git log --oneline -10 -- <file>
git diff HEAD~5 -- <file> # if recent regression suspected
```
3. Look for related tests — do they pass? Do they cover
the broken case?
4. Search for similar patterns elsewhere that might have
the same bug:
```bash
# grep for the same pattern to assess blast radius
```
## STEP 3 — HYPOTHESIZE + PLAN
Present findings before fixing:
```
BUGFIX — DIAGNOSIS
BUG : <one-line symptom>
ROOT CAUSE: <what is actually wrong and why>
EVIDENCE: <what confirmed it — test, trace, diff>
BLAST RADIUS: <other places affected, or "isolated">
FIX PLAN:
1. <file:line> — <what to change>
2. <file:line> — <what to change>
[3. <test file> — add/update test for this case]
RISK: <low/medium — what could go wrong>
```
- If the root cause is still unclear after investigation,
say so explicitly. List remaining hypotheses ranked by
probability. Ask the user before proceeding.
- If the fix is trivial after investigation (1-2 lines):
proceed directly — no need to wait for approval on an
obvious fix.
- If the fix is significant (>10 lines, multiple files,
behavior change): wait for user approval.
## STEP 4 — FIX
Apply the fix following the plan:
- Fix the root cause, not the symptom.
- Add or update tests to cover the bug case (regression test).
- If no test framework exists: document what you verified.
- Keep changes minimal — fix the bug, nothing else.
## STEP 5 — VERIFY + COMMIT
1. Run the full relevant test suite:
```bash
# detect and run tests
```
2. If a build step exists, verify it passes.
3. Check for regressions in related functionality.
4. Commit using conventional format:
```
fix(<scope>): <root cause description>
<what was wrong and why>
<what the fix does>
Co-Authored-By: Claude <noreply@anthropic.com>
```
5. Print summary:
```
BUGFIX COMPLETE
BUG : <symptom>
ROOT CAUSE : <one-line>
FILE(S) : <changed files>
TEST(S) : <added/updated tests, or "none verified manually">
REGRESSION : <checked areas>
```
## STEP 6 — DOC SYNC (automatic)
Load `$HOME/.claude/agents/doc-syncer.md`.
Execute in automatic mode:
`auto-mode scope: <list of files modified during this session>`
## STEP 7 — CAPITALIZE (memory registries)
A bugfix with an understood root cause is almost always worth one entry:
1. Propose a `BLK-XXX` entry in `.claude/memory/blockers.md` pre-filled from STEP 3 diagnosis:
- `friction` = symptom
- `real_cause` = root cause identified
- `solution` = the fix applied
- `status` = resolved
2. If the root cause exposed a **reusable pattern** (would catch the same bug elsewhere or in other projects) → also propose an `LRN-XXX` entry in `.claude/memory/learnings.md`.
3. Present as:
```
CAPITALIZE — proposé
BLK-XXX — <friction> — resolved
[LRN-XXX — <pattern>] (optionnel)
Valider ? (all / blockers-only / edit / skip)
```
4. Append approved entries + update the Index. Add a line to today's heading in `.claude/memory/journal.md`.
If the bug was trivial and the root cause not transferable → skip with `CAPITALIZE: trivial, skip`.
---
## RULES
- No fix without understanding the root cause first.
- Design gate only if UI/style signals detected. See STEP 1.5.
- If investigation reveals a design flaw requiring significant
refactoring → stop, explain, suggest `/ship-feature` for the
proper fix.
- Always add a regression test when possible.
- Keep the fix scoped. No "while we're here" cleanups.
- If >5 files need changes → reconsider if `/ship-feature`
is more appropriate.