CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

121-java-object-oriented-design

Use when reviewing, improving, or refactoring Java object-oriented design, including applying SOLID, DRY, or YAGNI; improving classes and interfaces; correcting encapsulation, inheritance, or polymorphism; resolving God Class, Feature Envy, or Data Clumps; and improving object creation, methods, or exception contracts. Triggers include review Java OOD, refactor Java OOD, improve Java OOD, fix OOP misuse, and identify Java code smells. Part of Plinth Toolkit

68

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured skill with an exemplary progressive-disclosure design and a clearly validated workflow. Its main weakness is token redundancy — the coverage list, when-to-use list, and workflow classification duplicate each other, and the compile/verify constraints are stated three times.

Suggestions

Collapse the 'What is covered in this Skill?' list and Workflow step 2's concern taxonomy into a single concern classification — they enumerate the same eight concerns twice.

Remove the 'When to use this skill' section; its eight bullets restate the description's 'Use when' triggers without adding new information.

State the compile-before/verify-after safety constraints once (in the Constraints section or the workflow steps) instead of repeating them in both plus the workflow narrative.

DimensionReasoningScore

Conciseness

The body is mostly efficient but systematically redundant: the 'What is covered' list, the 'When to use this skill' list, and Workflow step 2's concern taxonomy repeat nearly identical material, and the compile-before/verify-after constraints appear three times (Constraints section, Workflow steps 1 and 5). This could be tightened considerably.

3 / 5

Actionability

Concrete executable commands ('./mvnw compile', 'mvn clean verify'), an explicit concern-to-reference file mapping, and named refactoring techniques give mostly actionable guidance; the refactoring step itself ('Introduce or refine abstractions', 'Hide exposed state') remains somewhat abstract compared to the rest.

4 / 5

Workflow Clarity

A clearly sequenced six-step workflow with explicit validation checkpoints: mandatory pre-compile with stop-on-failure, per-refactoring compilation, post-change full verification, behavior-preservation requirements, and edge-case escalation (ask a clarifying question when scope is ambiguous).

5 / 5

Progressive Disclosure

The SKILL.md body is a genuine overview: eight one-level-deep reference files (all verified to exist), clearly signaled and mapped concern-by-concern in Workflow step 3 and the Reference section, with explicit instructions to load only what the classified concerns require.

5 / 5

Total

17

/

20

Passed

Description

88%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with comprehensive, specific capability coverage and an explicit 'Use when' trigger clause. The main weaknesses are slightly unnatural trigger phrasing and minor overlap with adjacent type-design and exception-handling skills.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — applying SOLID, DRY, YAGNI; improving classes and interfaces; correcting encapsulation, inheritance, polymorphism; resolving named code smells (God Class, Feature Envy, Data Clumps); improving object creation, methods, exception contracts — giving comprehensive coverage of the skill's capabilities.

5 / 5

Completeness

It explicitly answers 'what' through the enumerated actions and 'when' through both the 'Use when reviewing, improving, or refactoring...' clause and a dedicated 'Triggers include...' sentence, matching the anchor example structure.

5 / 5

Trigger Term Quality

Strong natural keywords are present (SOLID, DRY, YAGNI, God Class, Feature Envy, Data Clumps, encapsulation, code smells), but the explicit trigger phrases are stilted ('review Java OOD') and common variations users might say, such as 'design patterns' or 'clean code', are missing.

4 / 5

Distinctiveness Conflict Risk

The Java-OOD niche is clear with distinct trigger terms, but 'improving object creation, methods, or exception contracts' overlaps with adjacent dedicated skills (122 and 126) that the body itself defers to, creating minor mis-trigger risk.

4 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

jabrena/plinth

Path

skills/121-java-object-oriented-design/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.