Lists multiple specific concrete actions: 'Detect, suggest, and evaluate GoF design patterns' along with specific pattern names (singleton/factory/observer/strategy) and specific frameworks (React, Angular, NestJS, Vue). Also mentions 'reviewing pattern quality' and 'finding stack-native alternatives'.

Clearly answers both 'what' (detect, suggest, and evaluate GoF design patterns in TS/JS codebases) and 'when' (explicit 'Use when' clause covering refactoring, applying specific patterns, reviewing pattern quality, or finding stack-native alternatives).

Includes strong natural keywords users would say: 'design patterns', 'refactoring', 'singleton', 'factory', 'observer', 'strategy', 'TypeScript', 'JavaScript', 'React', 'Angular', 'NestJS', 'Vue', and 'GoF'. These cover a wide range of terms a developer would naturally use when seeking pattern guidance.

Highly distinctive niche: GoF design patterns specifically in TypeScript/JavaScript with named frameworks. Unlikely to conflict with general code review, refactoring, or framework-specific skills because the focus on design pattern detection/evaluation is very specific.

Extremely verbose at ~400+ lines. Includes extensive JSON output examples, full markdown report templates, detailed tables, and exhaustive enumeration of all 23 GoF patterns, code smells, detection heuristics, and scoring guidelines. Much of this (what GoF patterns are, how to detect them, scoring rubrics) is knowledge Claude already possesses. The output format examples alone consume hundreds of tokens that could be summarized or referenced externally.

Provides concrete output format examples and some detection heuristics (grep patterns, file naming conventions), but the actual execution guidance is pseudocode-level (numbered workflow steps like 'Stack Detection → Pattern Search → Classification'). The CLI-style invocations (`/design-patterns detect src/`) suggest a slash command interface but don't specify how to actually implement the analysis using available tools (Bash, file reading, etc.). The skill describes what to do conceptually but lacks executable tool-use sequences.

Each mode has a numbered workflow, but these are high-level descriptions rather than actionable step sequences with validation checkpoints. There are no explicit validation or error-handling steps (e.g., what happens if package.json is missing, if no patterns are found, or if confidence is ambiguous). The adaptation logic pseudocode (IF/ELSE) provides some decision structure but lacks feedback loops.

References external files well (signatures/*.yaml, checklists/*.md, reference/*.md) and has a clear Reference Files section. However, the SKILL.md itself is monolithic — the full output format examples, the complete code smell list, the entire adaptation table, and detailed scoring guidelines are all inline when they should be in the referenced files. The skill would benefit greatly from moving the bulk content to reference files and keeping only the overview here.