Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →wondelai/working-with-legacy-code
Safely change and test untested codebases using Feathers' "Working Effectively with Legacy Code".
Passed 24 of 25 test cases with the skill, and 23 of 25 without it.
1 fixed23 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
A legacy Java method `processRequest(HttpServletRequest request)` processes incoming HTTP data, but `HttpServletRequest` is an unwieldy framework interface that cannot easily be instantiated or mocked in unit tests. A developer proposes writing an extensive mock framework for `HttpServletRequest`. What specific dependency-breaking technique should be used instead?
| Checked | Without skill | With skill |
|---|---|---|
| The response recommends Adapt Parameter. | Missed | Passed |
The instructions your model reads when the skill loads.
A field manual for changing code that has no tests, distilled from Michael C. Feathers' Working Effectively with Legacy Code. Use it to get untestable classes into a harness, pin down current behavior with characterization tests, and make changes one safe, verifiable step at a time — without resorting to a rewrite.
Legacy code is simply code without tests. Not old code, not ugly code — untested code: without tests you cannot know whether a change preserves behavior, so every edit is a gamble. The craft is breaking dependencies just enough to get tests in place before changing anything — cover and modify, never edit and pray.
Goal: 10/10. Rate changes to untested code 0-10 against the principles below. Report the current score and the specific steps needed to reach 10/10.
Core concept: The dilemma: to change code safely we need tests, but to get tests in place we have to change code. The way out is a fixed sequence — identify change points, find test points, break dependencies, write tests, then make changes and refactor — where the pre-test edits are conservative and mechanical, and the real change happens only inside the safety net.
Why it works: Edit-and-pray substitutes care for feedback, and care doesn't scale to code you don't fully understand. Cover-and-modify clamps existing behavior in a vise of tests, so any unintended change announces itself immediately on your machine instead of later in production.
Key insights:
Applications:
| Context | Application | Example |
|---|---|---|
| Bug fix in an untested module | Run the five steps before touching the bug | Pin parseInvoice() with tests, then fix the rounding error |
| PR mixing cleanup and a feature | Split into structure-only and behavior-only commits | Extract and rename first, tests green, then add the discount rule |
| "It's just a one-line change" | Find the nearest test point first | One pin test at the public method that calls the private one you edit |
test cases passed, vs 23 / 25 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.