keisei/KeiSeiKit-1.0
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
KeiSeiKit-1.0/skills/refactor/SKILL.md
Parfii-bot ddd13e6422 docs: SKILL.md triggers + STATUS-TRUTH footer + phase placeholders 
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>
2026-05-02 21:41:41 +08:00

1.8 KiB
Raw Blame History

name description arguments
refactor Use when refactoring code while preserving behavior — checkpoint, extract, test, audit
name description required
target File or module to refactor true
name description required
goal What the refactoring should achieve 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>