Group G — markdown tech-debt cleanup (post-audit 2026-05-02).
- 36 SKILL.md files: added "## When to use" section. Was missing across the
catalog; orchestrator routing by keyword could not auto-dispatch.
- 20 code-implementer agent .md files: added Output Footer block prescribing
RULE 0.16 STATUS-TRUTH MARKER schema in agent's final report. Previously only
code-implementer-rust.md had it; other 27 language/role variants were silent
about the marker, breaking RULE 0.16 §3 status-truth aggregation for non-Rust
batches.
- skills/site-create/: added phase-5-preview.md and phase-6-deploy.md skeleton
files. SKILL.md table-of-contents referenced 7 phases; only 5 existed on disk.
- skills/{ai-animation,rag-pipeline}/skill.md: added migration banner comment
noting they should be SKILL.md (canonical filename). Case-rename via git is a
separate orchestrator task (macOS APFS is case-insensitive; Linux deploy needs
explicit rename).
- 3 deprecated skills (site-builder, competitor-analysis, design-inspiration):
added concrete removed-after dates (was vague "before v2").
- docs/CONVERGENCE-PLAN.md:129: TBD on _blocks/evidence-grading.md duplicate
resolved (file exists, not duplicated).
- docs/DNA-INDEX.md: count edits made then overwritten by auto-encyclopedia-refresh
hook during agent run. The .kei-registry-ignore files in test fixtures (Group F)
are the structural fix; kei-registry walker implementation is the follow-up.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
52 lines
1.8 KiB
Markdown
52 lines
1.8 KiB
Markdown
---
|
|
name: fix-issue
|
|
description: Use when fixing a GitHub issue — reproduce, trace root cause, fix, add regression test
|
|
disable-model-invocation: true
|
|
arguments:
|
|
- name: issue
|
|
description: GitHub issue number or URL
|
|
required: true
|
|
---
|
|
|
|
# Fix Issue Workflow
|
|
|
|
## When to use
|
|
|
|
- Fixing a tracked GitHub issue: reproduce → trace root cause → fix → add regression test.
|
|
- Any bug fix that needs a failing test written first (TDD approach).
|
|
- Investigating an issue report where the reproduction steps or root cause are unclear.
|
|
|
|
## Step 1: Load Issue Context
|
|
- Fetch issue details: `gh issue view $issue --json title,body,labels,comments`
|
|
- Read all comments for additional context
|
|
- Identify: expected behavior, actual behavior, reproduction steps
|
|
|
|
## Step 2: Reproduce
|
|
- Set up reproduction environment based on issue description
|
|
- Write a failing test that captures the bug (TDD approach)
|
|
- If cannot reproduce — ask user for more context, do NOT guess
|
|
|
|
## Step 3: Trace Root Cause
|
|
- Use Grep/Glob to find relevant code paths
|
|
- Trace execution flow from entry point to failure
|
|
- Identify the ROOT CAUSE, not symptoms
|
|
- Check DECISIONS.md for related past decisions
|
|
|
|
## Step 4: Checkpoint
|
|
- `git commit` current state: `checkpoint: before fix-issue #$issue`
|
|
|
|
## Step 5: Fix
|
|
- Fix at the root cause level, NOT overlay/patch
|
|
- Follow Constructor Pattern: if fix grows file >200 lines, decompose
|
|
- Ensure fix doesn't break other functionality
|
|
|
|
## Step 6: Verify
|
|
- Run the failing test — must pass now
|
|
- Run full test suite — no regressions
|
|
- If test suite doesn't exist, create at minimum:
|
|
- Test for the specific bug (regression test)
|
|
- Test for the happy path of affected function
|
|
|
|
## Step 7: Commit
|
|
- `fix: <description of what was fixed> (closes #$issue)`
|
|
- Update TODO.md if issue was tracked there
|