Fix Documentation
Every implemented fix must leave a short Markdown record in docs/fixes/.
docs/fixes/ already contains 90+ pre-existing records in an older, inconsistent format (some with a
# Fix: <title> heading, some without; some with a **Date:** line, some without; and 25+ different ad hoc
## section names across the set — ## Problem, ## Root Cause, ## Tests, ## Related, etc.). Do not
migrate those — they stay as-is. All new records use the merged format below, which keeps the old
convention's most useful, scannable elements (the # Fix: heading, the explicit **Date:** line) and adopts
a single, consistent five-section structure instead of ad hoc headers.
Workflow
- Before final ready status, create or update
docs/fixes/YYYY-MM-DD-<slug>.md.
- Use the current local date for
YYYY-MM-DD.
- Use a lowercase slug with letters, numbers, and hyphens.
- Record what changed, why it changed, validation that actually ran, and follow-ups.
- Do not invent validation. If a check was skipped or blocked, say why.
- If the fix leaves any follow-up work (anything under Follow-ups other than
None.), it must satisfy
CLAUDE.md's Follow-up Tracking (MANDATORY) section: open a GitHub issue and link it by number (e.g.
#1234) in the Follow-ups section. A Follow-ups entry like "a follow-up will..." with no issue number is
incomplete — the work will never be tracked.
Required Document Shape
# Fix: <Title>
**Date:** YYYY-MM-DD
## Summary
## Context
## Changes
## Validation
## Follow-ups
<Title> is a short human-readable description of the fix (inline code spans are fine, e.g.
# Fix: `describe affected` now checks `source` and `provision` sections).
**Date:** restates the filename's date for at-a-glance scanning; keep it in sync with the filename.
- Use
None. in Follow-ups only when no follow-up is known.
Validation
After creating or updating fix docs, run:
bash .claude/skills/fix-log/scripts/validate-fix-doc.sh docs/fixes/*.md
The validator only checks the five required ## sections and the filename shape — it doesn't (yet) enforce
the # Fix: heading or **Date:** line. Run it against the files you're adding, not the whole directory
indiscriminately (it will report errors against the old-format records, which is expected and not something
to fix).
1---2name: fix-log3description: Use when implementing, finishing, documenting, or reviewing a fix, repair, remediation, bug fix, debug-and-fix task, workflow fix, infrastructure fix, or any change that should leave a durable fix record under docs/fixes.4---56# Fix Documentation78Every implemented fix must leave a short Markdown record in `docs/fixes/`.910`docs/fixes/` already contains 90+ pre-existing records in an older, inconsistent format (some with a11`# Fix: <title>` heading, some without; some with a `**Date:**` line, some without; and 25+ different ad hoc12`## ` section names across the set — `## Problem`, `## Root Cause`, `## Tests`, `## Related`, etc.). **Do not13migrate those** — they stay as-is. All new records use the merged format below, which keeps the old14convention's most useful, scannable elements (the `# Fix:` heading, the explicit `**Date:**` line) and adopts15a single, consistent five-section structure instead of ad hoc headers.1617## Workflow18191. Before final ready status, create or update `docs/fixes/YYYY-MM-DD-<slug>.md`.202. Use the current local date for `YYYY-MM-DD`.213. Use a lowercase slug with letters, numbers, and hyphens.224. Record what changed, why it changed, validation that actually ran, and follow-ups.235. Do not invent validation. If a check was skipped or blocked, say why.246. If the fix leaves any follow-up work (anything under **Follow-ups** other than `None.`), it must satisfy25 `CLAUDE.md`'s **Follow-up Tracking (MANDATORY)** section: open a GitHub issue and link it by number (e.g.26 `#1234`) in the Follow-ups section. A Follow-ups entry like "a follow-up will..." with no issue number is27 incomplete — the work will never be tracked.2829## Required Document Shape3031```markdown32# Fix: <Title>3334**Date:** YYYY-MM-DD3536## Summary3738## Context3940## Changes4142## Validation4344## Follow-ups45```4647- `<Title>` is a short human-readable description of the fix (inline code spans are fine, e.g.48 `` # Fix: `describe affected` now checks `source` and `provision` sections ``).49- `**Date:**` restates the filename's date for at-a-glance scanning; keep it in sync with the filename.50- Use `None.` in `Follow-ups` only when no follow-up is known.5152## Validation5354After creating or updating fix docs, run:5556```bash57bash .claude/skills/fix-log/scripts/validate-fix-doc.sh docs/fixes/*.md58```5960The validator only checks the five required `## ` sections and the filename shape — it doesn't (yet) enforce61the `# Fix:` heading or `**Date:**` line. Run it against the files you're adding, not the whole directory62indiscriminately (it will report errors against the old-format records, which is expected and not something63to fix).