bastien 617865cb07 feat(capitalize): enforce English in all memory registry entries

Registries are re-read at every session start; consistency pays back
each time. Adding a single rule in CLAUDE.md § Memory registries
(authoritative) + a short reminder at the end of each CAPITALIZE
block (ship-feature, bugfix, hotfix, feat, commit-change, close).

Rationale: (1) model re-reads the registries more efficiently in a
single language, (2) lower token cost for English (model's primary
training language), (3) easier cross-project reuse. Interactive gates
may still mirror the user's language — only the written entry is
constrained.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-23 16:24:04 +02:00

3.2 KiB

Raw Blame History

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.md and 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-max inactive → 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-XXX in .claude/memory/learnings.md.
Bug that cost real time to locate despite being "superficial" → propose BLK-XXX in .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).

Language rule: the journal line and any proposed BLK/LRN entries are ALWAYS written in English (see CLAUDE.md "Memory registries" § Language).

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.

3.2 KiB Raw Blame History