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
denis 0b901cf2f9 feat: KeiSeiKit v0.1.0 — initial public release 
Generic Constructor-Pattern agent kit for Claude Code. Zero personal data,
fully English, MIT-licensed.

Contents:
- 34 reusable blocks (baseline, rules, stack/deploy/domain/api/scraper)
- 14 cross-project agent manifests (code/ml/infra/researcher/critic/...)
- 6 portable skills (/new-agent, /research, /test-gen, /debug-deep, /pr-review, /refactor)
- Rust assembler (single binary, ~500 KB)
- 3 hooks (auto-reassemble, pre-commit validate, no-hand-edit)
- install.sh (idempotent, cargo-builds on first run)
- MIT LICENSE

All 6 sanity greps pass: 0 Russian text, 0 specific project names,
0 incident numbers, 0 user paths, 0 hardcoded IPs, 0 API keys.

cargo check + assemble --validate: both pass on 14 manifests.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-20 23:58:34 +08:00

1.5 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

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>