Extremely lean and efficient. No explanation of what patterns are conceptually (Claude knows). Every section earns its place with actionable tables, anti-patterns, and the critical 'or maybe just' column that prevents over-engineering.

Highly actionable with concrete symptom→pattern mapping table, specific code examples (Java Strategy interface), and a worked example showing the full reasoning process. The output format template is copy-paste ready.

Clear workflow: identify symptom → match pattern → check 'or maybe just' → apply or reject. The worked example demonstrates this sequence explicitly, and the output format enforces validation via 'When NOT to' section.

Well-organized single file appropriate for this scope. Clear sections (problem→pattern, anti-patterns, worked example, do not, output format) with logical flow. No need for external references given the focused nature of the skill.

Names the domain (design patterns) and describes actions (recognizes, recommends, explains), but lacks specific concrete examples of which patterns or what types of structural situations it handles.

Clearly answers both what (recognizes structural situations, recommends patterns, explains fit) AND when with explicit 'Use when...' clause covering three distinct trigger scenarios.

Includes 'design patterns' and 'pattern' as keywords, but misses common variations users might say like 'factory pattern', 'singleton', 'refactoring', 'architecture', or specific pattern names that would naturally trigger this skill.

Clear niche focused specifically on design pattern recognition and recommendation; the explicit focus on 'structural situations' and 'pattern fit' creates distinct triggers unlikely to conflict with general code review or architecture skills.