Legacy code safety

Skill andresnator/agents-orchestrator/skills/legacy-code-safety

Install

npx -y skills add andresnator/agents-orchestrator --skill legacy-code-safety

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Trigger: legacy code safety, safe refactor. Make untested code safe to change.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.3 KB, as published. Nobody here has run it

Legacy Code Safety

Legacy code is code without a sufficient test safety net. The goal is not to make it beautiful first; the goal is to make it safe to change.

Principles

Capture current behavior before refactoring.
Treat current observable behavior as the contract until explicitly changed.
Search for seams before structural changes.
Break dependencies minimally to enable characterization tests.
Refactor incrementally in small, reversible steps.
Separate behavior-preserving refactor from functional change.
Validate after every step.
Protect public contracts.
Document rollback before implementation begins.

Legacy Code Change Algorithm

Every safe change to legacy code follows the same pipeline: (1) identify change points, (2) find test points, (3) break dependencies, (4) write characterization tests, (5) change and refactor. Plans over legacy code should make these five steps recognizable in their task ordering.

Cover & Modify

Cover & Modify, never Edit & Pray: no plan step modifies code that is not covered by tests (the "software vise"). If coverage is not affordable, the step shrinks until it is, or it moves behind a hardening task.

Cheap impact mapping

Lean on the compiler: in statically typed code, deliberately changing a signature or type makes the compiler enumerate every use site — a free impact map when call hierarchies are unclear.

Sprout and Wrap (routing note)

Sprout Method/Class (grow new, tested code called from the untested flow) and Wrap Method/Class (add behavior before or after the untested code) are mitigation routes for delivering NEW logic when putting the class under test is not affordable yet. They add behavior, so they never appear as tasks in a behavior-preserving refactor bundle: in refactor plans they are recorded only as follow-up/Scope Out routing hints toward /deep-plan or sdd execution. Decision rule where they do apply: sprout for new logic inside the flow, wrap for behavior before/after it; escalate to the class variant when the original cannot be instantiated.