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>
57 lines
1.8 KiB
Markdown
57 lines
1.8 KiB
Markdown
---
|
|
name: refactor
|
|
description: Use when refactoring code while preserving behavior — checkpoint, extract, test, audit
|
|
arguments:
|
|
- name: target
|
|
description: File or module to refactor
|
|
required: true
|
|
- name: goal
|
|
description: "What the refactoring should achieve"
|
|
required: false
|
|
---
|
|
|
|
# Refactor Workflow
|
|
|
|
## When to use
|
|
|
|
- Restructuring code that violates the Constructor Pattern (file >200 LOC, function >30 LOC, multiple responsibilities, duplicated code).
|
|
- Safe refactoring that must preserve existing behaviour — checkpoint, tests baseline, extract, verify.
|
|
- When `wave-audit` or `/dev-guard` flags a structural issue that requires decomposition.
|
|
|
|
## Step 1: Understand Current State
|
|
- Read target file(s) completely
|
|
- Identify existing tests for the target
|
|
- Run existing tests — baseline must pass
|
|
- Document current behavior (inputs → outputs)
|
|
|
|
## Step 2: Plan Refactoring
|
|
- Identify what violates Constructor Pattern:
|
|
- File >200 lines → decompose
|
|
- Function >30 lines → extract
|
|
- Multiple responsibilities → split
|
|
- Duplicated code → single source
|
|
- Overlay/patches → root formula
|
|
- List concrete changes BEFORE making them
|
|
|
|
## Step 3: Checkpoint
|
|
- `checkpoint: before refactor $target`
|
|
|
|
## Step 4: Refactor (Incremental)
|
|
- ONE structural change at a time
|
|
- After each change: run tests
|
|
- If test breaks → fix immediately or revert
|
|
- Preserve all public interfaces unless explicitly changing them
|
|
|
|
## Step 5: Audit
|
|
- Check: does refactored code follow Constructor Pattern?
|
|
- Check: no overlay, no dead code, no orphaned imports
|
|
- Check: SSOT — no duplicated logic
|
|
- Check: file sizes within limits
|
|
|
|
## Step 6: Final Verification
|
|
- Run full test suite — all pass
|
|
- Diff review: no accidental behavior changes
|
|
- No new dependencies added without reason
|
|
|
|
## Step 7: Commit
|
|
- `refactor: <what was restructured and why>`
|