caveman--safe-refactor

Restructure code while preserving behavior through verification-bracketed structural edits.

Updated Dec 3, 2025
One-click install
npx skills add https://github.com/hhenrichsen/dots --skill caveman-safe-refactor-hhenrichsen
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: caveman--safe-refactor
Source: https://github.com/hhenrichsen/dots/tree/main/dot_skills/caveman/safe-refactor
Command: npx skills add https://github.com/hhenrichsen/dots --skill caveman-safe-refactor-hhenrichsen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Structural code changes like extractions, consolidations, and ownership moves often introduce subtle regressions because behavior verification is skipped or done inconsistently. This Skill enforces a disciplined workflow where verification brackets every structural edit, keeping behavior intact. ## Core Features & Use Cases - Behavior-Preservation Boundary: Defines the scope of what must not change—public interfaces, failure behavior, ordering, and compatibility—before edits begin. - Incremental Ownership Moves: Moves one ownership boundary at a time so intermediate states stay buildable and testable. - Verification Bracketing: Runs the same proof before and after the change, stopping only when behavior matches and the requested structure is achieved. - Use Case: When extracting a shared module from two duplicated implementations, use this Skill to keep feature changes out of the refactor and confirm identical behavior at each step. ## Quick Start Use $safe-refactor to restructure this code while preserving behavior.

Frequently Asked Questions about caveman--safe-refactor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor code without changing its behavior?▼

Define a behavior-preservation boundary first, then establish verification before making structural edits. Run the same proof after the change and stop only when behavior matches and the requested structure is achieved.

What is a safe refactoring workflow for large codebases?▼

Move one ownership boundary at a time and keep every intermediate state buildable and testable. Keep feature changes outside the refactor so structural edits can be verified independently.

Can I combine feature changes with a refactor?▼

No, feature changes should stay outside the refactor. Mixing them makes it impossible to attribute regressions to either the structural edit or the new behavior, breaking the verification bracket.

What must be preserved during a behavior-preserving refactor?▼

Preserve public interfaces, failure behavior, ordering, and compatibility unless explicitly scoped otherwise. Also avoid dependency or configuration growth without a correctness need.

When should I not use a behavior-preserving refactor approach?▼

Avoid it when the goal is intentionally changing behavior, such as fixing a bug in failure handling or altering public APIs. Those changes belong in a separately scoped feature or fix, not inside the structural edit.