brainstorming
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.
68
58%
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 extreme vagueness and over-broad scope. It attempts to claim priority over nearly all creative/development work ('You MUST use this before any creative work') without specifying what concrete actions the skill actually performs. The imperative tone ('You MUST') and lack of specific capabilities make it poorly suited for skill selection among multiple options.
Suggestions
Replace vague 'explores user intent, requirements and design' with specific concrete actions like 'Generates requirement checklists, creates design documents, asks clarifying questions about scope and constraints'.
Narrow the trigger scope significantly - instead of 'any creative work', specify the particular types of tasks where pre-implementation exploration is needed, e.g., 'Use when starting a new feature from scratch or when requirements are ambiguous'.
Add distinct trigger terms that differentiate this from implementation skills, such as 'requirements gathering', 'design exploration', 'scope definition', 'pre-implementation planning'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague language like 'creative work', 'creating features', 'building components', 'adding functionality', and 'modifying behavior' without specifying concrete actions the skill performs. 'Explores user intent, requirements and design' is abstract and doesn't list specific capabilities. | 1 / 3 |
Completeness | The 'when' is addressed ('before any creative work - creating features, building components, adding functionality, or modifying behavior') and the 'what' is loosely stated ('Explores user intent, requirements and design before implementation'). However, the 'what' is vague and the 'when' is overly broad rather than providing explicit, well-scoped triggers. | 2 / 3 |
Trigger Term Quality | Terms like 'creating features', 'building components', 'adding functionality', and 'modifying behavior' are somewhat relevant keywords a user might use, but they are extremely broad and could apply to almost any development task. Missing more specific natural language triggers. | 2 / 3 |
Distinctiveness Conflict Risk | This description is extremely generic and would conflict with virtually any development or design skill. 'Creating features', 'building components', 'adding functionality', and 'modifying behavior' cover nearly all software development tasks, making it impossible to distinguish from other skills. | 1 / 3 |
Total | 6 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong process-oriented skill with excellent workflow clarity, explicit validation gates, and highly actionable guidance. Its main weakness is moderate verbosity — some sections explain reasoning and principles that Claude already understands (design isolation, YAGNI, when visual > text), and the dot graph duplicates the checklist. Overall it's well-crafted and would guide Claude effectively through a brainstorming-to-design workflow.
Suggestions
Trim the 'Design for isolation and clarity' section — Claude already understands modularity, single responsibility, and interface design. A single sentence reminder is sufficient.
Remove the dot graph since it duplicates the checklist; or remove the checklist and keep only the graph. Having both is redundant.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary elaboration. The anti-pattern section, the detailed explanation of when to use browser vs terminal, and some of the 'Design for isolation and clarity' guidance explain concepts Claude already understands well. The dot graph is a nice touch but duplicates the checklist. Could be tightened by ~30%. | 2 / 3 |
Actionability | Highly actionable with a concrete checklist, specific file paths for output (docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md), exact message templates to use (the visual companion offer, the user review gate message), clear decision criteria, and explicit terminal states. Every step tells Claude exactly what to do. | 3 / 3 |
Workflow Clarity | Excellent multi-step workflow with explicit sequencing (numbered checklist), validation checkpoints (spec self-review with 4-point checklist, user review gate), feedback loops (user approves design? → revise; user reviews spec? → changes requested → rewrite), and a clear terminal state. The hard gate at the top prevents premature implementation. | 3 / 3 |
Progressive Disclosure | Well-structured with a concise checklist overview followed by detailed sections. References external files appropriately (skills/brainstorming/visual-companion.md, elements-of-style skill) at one level deep. Content is organized into logical sections (Process, After the Design, Key Principles, Visual Companion) that are easy to navigate. | 3 / 3 |
Total | 11 / 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.
- Repository
- obra/superpowers
- Commit
6efe32c
- 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.