Content
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but excessively verbose specification for DTO generation. Its greatest strength is the thorough decision-making framework and detailed anti-hallucination checklist, but these come at a severe token cost — the skill reads more like an internal design document than a concise instruction set. The heavy reliance on external reference and example files (none provided for evaluation) makes actionability hard to fully assess, and the lack of post-generation validation steps weakens the workflow.
Suggestions
Reduce the skill body by 50-60%: collapse the 'Decision-making principle' section into a compact priority list (5-10 lines max), remove repeated rules (e.g., 'never write manual mapping code' stated 3 times), and move the 'How to ask — prefer AskUserQuestion' section to a reference file since Claude understands tool usage patterns.
Move the anti-hallucination checklist, per-field options, and indentation detection rules into separate reference files (e.g., references/checklist.md, references/per-field.md, references/indentation.md) to reduce the main file size and improve progressive disclosure.
Add an explicit post-generation validation step (Step 6.5) that verifies the generated file exists, has correct package declaration, and imports compile — rather than relying solely on a pre-generation mental checklist.
Include at least one concrete, minimal end-to-end example showing input entity details → generated DTO output, so the skill is self-contained enough to verify correctness without needing all external reference files.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Extensively explains decision-making principles, context-reading strategies, and question-asking philosophy that Claude already understands. The defaults table, decision-making principle section, Step 0, and 'How to ask' subsection are heavily padded with meta-instructions about how to think rather than what to do. Many rules are repeated multiple times (e.g., 'never write manual mapping code' appears 3+ times, sub-DTO type restrictions are stated in multiple places). | 1 / 3 |
Actionability | The skill provides structured steps and references to example/fragment files for code generation, but contains no inline executable code examples. It relies entirely on external files (examples/_skeletons/, examples/_fragments/, references/*.md) that are not provided, making it impossible to verify executability. The MCP tool calls and variable substitution rules are concrete, but the actual code generation is delegated to unseen references. | 2 / 3 |
Workflow Clarity | The 7-step workflow is clearly sequenced (Steps 0-7) with logical progression from context gathering to code generation to mapper delegation. However, validation checkpoints are weak — the anti-hallucination checklist is a pre-generation mental check rather than an executable validation step. There's no explicit 'verify the generated file compiles' or 'validate the output' step after code generation. The name collision check via list_existing_classes is mentioned but buried in a checklist rather than being an explicit workflow step. | 2 / 3 |
Progressive Disclosure | The skill references multiple external files (references/sub-dto.md, references/java-plain.md, references/java-record.md, references/java-lombok.md, references/kotlin.md, references/validation.md, examples/_skeletons/, examples/_fragments/) which suggests good structural decomposition. However, no bundle files were provided to verify these exist, and the main SKILL.md itself is monolithic — it contains enormous amounts of inline detail (decision-making principles, per-field options, indentation rules, anti-hallucination checklist) that could be split into reference files. | 2 / 3 |
Total | 7 / 12 Passed |