You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
65
54%
Does it follow best practices?
Impact
74%
1.17xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/brainstorming/SKILL.mdQuality
Discovery
32%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description suffers from being overly broad and vague. It attempts to position itself as a mandatory pre-implementation planning/discovery skill but fails to describe specific concrete actions it performs. The extremely wide trigger scope ('any creative work') would cause frequent conflicts with other skills and provides poor signal for skill selection.
Suggestions
Narrow the scope by specifying concrete actions the skill performs, e.g., 'Generates requirements documents, creates design specifications, produces architecture diagrams, and writes user stories before implementation begins.'
Replace the overly broad 'any creative work' trigger with specific, distinguishable triggers, e.g., 'Use when the user asks to plan a feature, write a spec, gather requirements, or design a solution before coding.'
Remove the imperative 'You MUST use this' phrasing and use third person voice describing capabilities, e.g., 'Facilitates requirements discovery and design exploration...'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language like 'creative work', 'creating features', 'building components', 'adding functionality', and 'modifying behavior' without listing concrete actions the skill performs. 'Explores user intent, requirements and design' is similarly abstract. | 1 / 3 |
Completeness | The 'when' is addressed ('before any creative work - creating features, building components...'), and the 'what' is weakly stated ('Explores user intent, requirements and design before implementation'). However, the 'what' is vague and the 'when' is overly broad rather than providing explicit, useful triggers. | 2 / 3 |
Trigger Term Quality | It includes some relevant terms like 'features', 'components', 'functionality', 'requirements', and 'design' that users might mention, but these are extremely broad and not distinctive trigger terms. Missing natural phrases users would say like 'plan', 'spec', 'requirements gathering', 'design doc'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is extremely broad - 'creating features, building components, adding functionality, or modifying behavior' covers nearly all development work. This would conflict with virtually any coding or development skill, making it very difficult to distinguish from other skills. | 1 / 3 |
Total | 6 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-crafted brainstorming skill with excellent workflow clarity, strong actionability, and good safety gates preventing premature implementation. Its main weakness is moderate verbosity — several sections explain design principles and heuristics that Claude already knows (isolation, YAGNI, following existing patterns), and the visual companion section is detailed but lengthy. The process flow diagram and explicit checklist are standout strengths.
Suggestions
Trim the 'Design for isolation and clarity' and 'Working in existing codebases' sections to 1-2 sentences each — these are general software engineering principles Claude already knows well.
Consider moving the Visual Companion section to a separate referenced file since it's a conditional feature with its own detailed rules, reducing the main skill's token footprint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but includes some verbose sections that could be tightened. The anti-pattern section, the detailed 'Design for isolation and clarity' guidance, and the 'Working in existing codebases' section explain concepts Claude already understands well. The visual companion section is thorough but could be more concise. | 2 / 3 |
Actionability | The skill provides highly concrete, actionable guidance: a numbered checklist, specific file paths for output (docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md), exact phrasing for user prompts, clear decision criteria for visual vs terminal, and explicit transition rules. Every step tells Claude exactly what to do. | 3 / 3 |
Workflow Clarity | The workflow is exceptionally clear with a numbered checklist, a graphviz process flow diagram, explicit validation gates (user approval after design sections, spec self-review with 4-point checklist, user review gate before proceeding), and feedback loops for revisions. The hard gate preventing premature implementation is a strong safety checkpoint. | 3 / 3 |
Progressive Disclosure | The skill references one external file (skills/brainstorming/visual-companion.md) and mentions other skills (writing-plans, elements-of-style), which is good. However, the main file is quite long (~200 lines of content) and some sections like 'Design for isolation and clarity' and 'Working in existing codebases' could potentially be split into referenced files. No bundle files were provided to verify the referenced paths exist. | 2 / 3 |
Total | 10 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
f2cbfbe
Table of Contents
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.