Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when Java design, refactoring, or implementation tradeoffs should be evaluated with Kent Beck's simple design rules, including passes the tests, reveals intention, has no duplication, and has the fewest elements. This should trigger for requests such as Apply simple design rules; Review this design with Beck's rules; Choose between these refactoring options; Keep this Java design simple. Part of Plinth Toolkit
.claude/skills/jabrena-053-design-simple-rules/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-20 | ✗→✓ | ▲ Improved | 168% | 0% |
| case-18 | ✗→✓ | ▲ Improved | -4% | 0% |
| case-02 | ✓→✗ | ▼ Worse | -57% | 0% |
| case-04 | ✓→✗ | ▼ Worse | -47% | 0% |
| case-05 | ✓→✗ | ▼ Worse | -57% | 0% |
Guide Java developers through Kent Beck's simple design rules when evaluating design and refactoring choices. This is an interactive SKILL.
What is covered in this Skill?
Apply simple design rules in priority order, and do not optimize later rules by weakening earlier rules.
references/053-design-simple-rules.md before applying the rulesRead references/053-design-simple-rules.md, then identify the behavior under discussion and the tests, characterization checks, build checks, or manual evidence that define whether the code works.
Evaluate whether names, types, responsibilities, control flow, API shape, and test descriptions make the domain decision clear to a future maintainer.
Find repeated knowledge, policy, mappings, validation, queries, or workflow decisions. Remove duplication only when the abstraction keeps the intent easier to understand.
After correctness, clarity, and duplication are handled, remove unnecessary classes, methods, parameters, branches, layers, configuration, or indirection that no longer pay for themselves.
Compare available design or refactoring options against the ordered rules. Recommend the option that satisfies the earlier rules best, describe rejected tradeoffs, and name the verification signal.
For detailed guidance, examples, and constraints, see references/053-design-simple-rules.md.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-03 | pass→pass | 16,551 | 7,023 | -58% | 1 | 1 | 0% | 2,308 | 1,602 | -31% | 0 | 0 | — |
case-09 | pass→pass | 14,963 | 18,673 | +25% | 1 | 1 | 0% | 2,419 | 3,238 | +34% | 0 | 0 | — |
case-01 | pass→pass | 16,087 | 13,345 | -17% | 1 | 1 | 0% | 2,157 | 2,446 | +13% | 0 | 0 | — |
case-02 | pass→fail | 13,577 | 5,492 | -60% | 1 | 1 | 0% | 2,067 | 894 | -57% | 0 | 0 | — |
case-04 | pass→fail | 10,422 | 5,404 | -48% | 1 | 1 | 0% | 1,526 | 802 | -47% | 0 | 0 | — |
case-05 | pass→fail | 11,595 | 4,526 | -61% | 1 | 1 | 0% | 1,790 | 761 | -57% | 0 | 0 | — |
case-06 | pass→fail | 5,457 | 5,075 | -7% | 1 | 1 | 0% | 975 | 876 | -10% | 0 | 0 | — |
case-07 | pass→fail | 17,441 | 4,784 | -73% | 1 | 1 | 0% | 2,377 | 857 | -64% | 0 | 0 | — |
case-08 | pass→pass | 12,016 | 14,380 | +20% | 1 | 1 | 0% | 1,794 | 2,275 | +27% | 0 | 0 | — |
case-10 | pass→pass | 5,498 | 4,671 | -15% | 1 | 1 | 0% | 868 | 1,249 | +44% | 0 | 0 | — |
case-11 | pass→fail | 13,563 | 3,031 | -78% | 1 | 1 | 0% | 1,989 | 900 | -55% | 0 | 0 | — |
case-12 | pass→pass | 12,055 | 9,603 | -20% | 1 | 1 | 0% | 1,631 | 1,892 | +16% | 0 | 0 | — |
case-13 | pass→fail | 11,080 | 4,893 | -56% | 1 | 1 | 0% | 1,774 | 846 | -52% | 0 | 0 | — |
case-14 | pass→pass | 10,591 | 10,237 | -3% | 1 | 1 | 0% | 1,747 | 2,150 | +23% | 0 | 0 | — |
case-20 | fail→pass | 7,051 | 20,198 | +186% | 1 | 1 | 0% | 1,137 | 3,049 | +168% | 0 | 0 | — |
case-15 | pass→fail | 14,812 | 5,564 | -62% | 1 | 1 | 0% | 2,125 | 866 | -59% | 0 | 0 | — |
case-16 | pass→pass | 14,768 | 10,200 | -31% | 1 | 1 | 0% | 2,009 | 2,199 | +9% | 0 | 0 | — |
case-17 | pass→fail | 11,109 | 4,825 | -57% | 1 | 1 | 0% | 1,752 | 772 | -56% | 0 | 0 | — |
case-18 | fail→pass | 18,027 | 12,272 | -32% | 1 | 1 | 0% | 2,567 | 2,465 | -4% | 0 | 0 | — |
case-19 | fail→fail | 15,320 | 9,125 | -40% | 1 | 1 | 0% | 2,356 | 1,748 | -26% | 0 | 0 | — |
case-21 | fail→fail | 20,119 | 18,807 | -7% | 1 | 1 | 0% | 3,429 | 3,722 | +9% | 0 | 0 | — |
case-22 | fail→fail | 13,823 | 11,091 | -20% | 1 | 1 | 0% | 2,174 | 2,390 | +10% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 14 counted toward the lift figure. The other 8 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of -32 percentage points is the difference between those two pass rates over the 14 comparable cases. 9 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.