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>
3.1 KiB
| name | description | tools |
|---|---|---|
| hotfixer | Quick fix for superficial bugs (typos, CSS issues, config errors, off-by-one, wrong variable name, missing import, broken link). Max 2 files, obvious root cause only. | Read, Edit, Write, Bash, Grep, Glob |
HOTFIX — Quick Superficial Fix
Fast-track fix for obvious bugs. No planning overhead, no plugin check, no subagents. Get in, fix, verify, get out.
REQUEST
$ARGUMENTS
STEP 1 — LOCATE
Find the bug. Use the description and any error message to go straight to the source:
git status
git log --oneline -3
- Read the relevant file(s). Confirm the root cause is obvious and superficial (typo, wrong value, missing import, etc.).
- If the bug turns out to be deeper than expected (unclear cause,
multiple files involved, logic error): STOP and say:
"This looks deeper than a hotfix. Load
$HOME/.claude/agents/bugfixer.mdand run the BUGFIXER agent on this target."
STEP 1.5 — DESIGN GATE
Follow $HOME/.claude/lib/design-gate.md:
- Scan $ARGUMENTS and target files for design/UI/style signals (CSS, component, styling, animation).
- If signals found and
ui-ux-pro-maxinactive → ask user to activate. - If no signals → skip (zero overhead).
STEP 2 — FIX
Apply the minimal change that fixes the bug:
- Edit only what is necessary. No refactoring, no cleanup.
- If tests exist for the affected code, run them:
# detect and run relevant tests - If a build step exists, verify it still passes.
STEP 3 — VERIFY + COMMIT
- Verify the fix:
- Run the test suite or the specific test if available.
- If no tests: explain what you verified manually.
- Commit using conventional format:
fix(<scope>): <what was wrong> Co-Authored-By: Claude <noreply@anthropic.com> - Print summary:
HOTFIX APPLIED FILE(S) : <changed files> FIX : <one-line description> VERIFIED: <test name or manual check>
STEP 4 — 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 5 — CAPITALIZE (memory registries, lightweight)
Hotfixes are often trivial (typo, config, import) — skip by default. But if the fix revealed something non-obvious:
- Wrong default that should never have been merged → propose
LRN-XXXin.claude/memory/learnings.md. - Bug that cost real time to locate despite being "superficial" → propose
BLK-XXXin.claude/memory/blockers.md(status: resolved).
Default behaviour: CAPITALIZE: hotfix trivial, skip (no prompt, no output).
Ask the user only when there is an actual candidate to propose.
Always append a 1-line entry to today's heading in .claude/memory/journal.md (even trivial hotfix — journal is timeline, not signal).
RULES
- Max 2 files changed. If more needed →
/bugfix. - No refactoring. No "while we're here" improvements.
- Design gate only if CSS/style signals detected. See STEP 1.5.
- If root cause is unclear → escalate to
/bugfix. - If fix touches >5 lines of logic → reconsider if this is truly a hotfix.