Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jabrena/051-design-two-steps-methods
Use when a complex or risky code change should be split into Kent Beck's two-step method by first making the change easy through behavior-preserving preparatory refactoring, then making the intended behavior change once the design supports it. This should trigger for requests such as Apply two-step change; Make this risky change safer; Refactor before changing behavior; Separate preparation from behavior change. Part of Plinth Toolkit
Passed 16 of 21 test cases with the skill, and 3 of 21 without it.
and 34 more in the full report
16 fixed1 passed either way3 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
I need to add support for a new third-party payment gateway in our legacy OrderProcessor.java class. Right now, all payment logic is hardcoded inside a 500-line method with high coupling. Can you walk me through planning and executing this modification safely so we don't break existing functionality while introducing the new gateway?
| Checked | Without skill | With skill |
|---|---|---|
| Explicitly defines the intended behavior change before describing any preparatory refactoring. | Missed | Passed |
| Isolates Step 1 as purely behavior-preserving refactoring. | Passed | Passed |
| Requires running existing tests after Step 1 before making Step 2 behavior changes. | Passed | Passed |
The instructions your model reads when the skill loads.
Guide Java developers through complex or risky changes by keeping design preparation separate from behavior modification. This is an interactive SKILL.
What is covered in this Skill?
Separate behavior-preserving preparation from behavior-changing work, and validate after each step.
Read references/051-design-two-steps-methods.md, inspect the relevant code and tests, and state the exact behavior or capability that must change. Identify why the current design makes the change complex, risky, or hard to verify.
test cases passed, vs 3 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.