053 design simple rules
Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers.
npx -y skills add jabrena/plinth --skill 053-design-simple-rulesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
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
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
3.3 KB, as published. Nobody here has run it
Simple Design Rules
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?
- Using tests as the first correctness boundary before design cleanup
- Revealing intention and maximizing clarity before abstraction pressure
- Reducing duplication without hiding domain meaning or worsening readability
- Treating fewer elements as the final simplification pressure after correctness, clarity, and duplication
- Comparing Java design and refactoring options with the ordered rules
- Reporting the chosen option, tradeoffs, validation signal, and remaining risk
Constraints
Apply simple design rules in priority order, and do not optimize later rules by weakening earlier rules.
- MUST read
references/053-design-simple-rules.mdbefore applying the rules - MUST evaluate the rules in this order: passes the tests, reveals intention, has no duplication, has the fewest elements
- MUST treat passing tests as the correctness boundary before design cleanup
- MUST prefer clear intention over abstraction for its own sake
- MUST reduce duplication only when the result preserves or improves clarity
- MUST consider fewer elements only after correctness, clarity, and duplication have been addressed
When to use this skill
- Apply simple design rules
- Use Beck's simple design rules
- Review this design with simple design rules
- Choose between these refactoring options
- Keep this Java design simple
- Does this design pass the simple design rules?
Workflow
- Anchor Correctness
Read 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.
- Reveal Intention
Evaluate whether names, types, responsibilities, control flow, API shape, and test descriptions make the domain decision clear to a future maintainer.
- Reduce Duplication Carefully
Find repeated knowledge, policy, mappings, validation, queries, or workflow decisions. Remove duplication only when the abstraction keeps the intent easier to understand.
- Minimize Elements Last
After correctness, clarity, and duplication are handled, remove unnecessary classes, methods, parameters, branches, layers, configuration, or indirection that no longer pay for themselves.
- Compare Options and Report
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.
Reference
For detailed guidance, examples, and constraints, see references/053-design-simple-rules.md.