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>

Más de este repositorio

mismo repositorio

research

KeiSeiLab/KeiSeiKit

Deep research on any topic using parallel agents, web search, and cross-referencing. Use when user asks to research, investigate, or deeply analyze a topic, technology, library, or concept. Triggers on keywords like "research", "investigate", "deep dive", "find out everything about". Supports `--angle` presets for common specializations (competitors, design-refs).

2026-06-017

animate

KeiSeiLab/KeiSeiKit

Gateway router for web animation work. Picks between /scroll-animation, /motion-design, or /ai-animation via one AskUserQuestion call, then hands off. Does NOT implement animation — the downstream skills remain the source of truth for their respective domains.

2026-05-307

batch-workflow

KeiSeiLab/KeiSeiKit

Use when running multi-skill pipelines — new-feature, marketing-launch, design-to-code, web-creation, full-audit, rag-setup workflows

2026-05-307

compose-solution

KeiSeiLab/KeiSeiKit

Meta-orchestrator — converts a free-text task description into the right artefact(s) (agent, skill, hook, rule, or block) by composing existing KeiSeiKit primitives. Pure-click decision chain except the single intake field. Enriches `_blocks/` over time via Phase 6 block-augmentation — the kit gets smarter with every invocation.

2026-05-307

design-inspiration

KeiSeiLab/KeiSeiKit

Deprecated alias for /research with the design-refs angle preset. Routes to /research focused on design patterns, visual archetype references, and award-winning site teardowns.

2026-05-307

dev-guard

KeiSeiLab/KeiSeiKit

Continuous parallel quality gate during development — 3 backend agents (security/perf/structure) check every significant code change in real-time. Run after writing code, before committing.

2026-05-307

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>