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.
60
41%
Does it follow best practices?
Impact
89%
1.12xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/data/01-productmanager-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 breadth and vagueness. It attempts to position itself as a mandatory pre-implementation planning/discovery skill but fails to describe concrete actions it performs and uses triggers so broad they would conflict with nearly every development-related skill. The imperative 'You MUST use this' tone is also unusual and doesn't help with skill selection clarity.
Suggestions
Narrow the scope by listing specific 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 trigger clause with specific, distinguishable triggers, e.g., 'Use when the user asks to plan a feature, write a spec, gather requirements, create a design document, or discuss architecture before coding.'
Reduce conflict risk by clearly defining the skill's niche — is it for requirements gathering, design exploration, or project planning? Pick a focused domain rather than claiming all pre-implementation work.
| 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, adding functionality, or modifying behavior'), and the 'what' is weakly stated ('Explores user intent, requirements and design before implementation'). However, the 'what' is too vague to be truly complete, and the 'when' clause 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', 'architecture'. | 2 / 3 |
Distinctiveness Conflict Risk | The description is extremely broad — 'creating features, building components, adding functionality, or modifying behavior' covers nearly all development tasks. 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
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable framework for collaborative brainstorming and design, with a clear sequential process and good principles. However, it lacks concrete examples (e.g., sample questions, sample design section output, document templates), has some redundancy between the process description and key principles, and mixes languages without clear justification. The workflow would benefit from explicit validation checkpoints and error recovery paths.
Suggestions
Add a concrete example showing a sample brainstorming question (multiple choice format) and a sample 200-300 word design section output to make the guidance more actionable.
Provide a template or skeleton for the design document (`docs/plans/YYYY-MM-DD-<topic>-design.md`) so Claude knows the expected output format.
Remove the Key Principles section or merge it into the process steps to eliminate redundancy — 'one question at a time' and 'multiple choice preferred' are already stated above.
Either consistently use English or clearly justify the Chinese documentation types with templates/examples; currently the mixed language feels inconsistent.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary padding ('Help turn ideas into fully formed designs and specs through natural collaborative dialogue') and mixed-language content (Chinese sections) that could be more streamlined. The key principles section partially repeats what was already stated in the process section. | 2 / 3 |
Actionability | Provides a clear process with specific steps (ask one question at a time, present in 200-300 word sections, write to specific file path), but lacks concrete examples of what good questions look like, what a design section output should look like, or a template for the design document. References to other skills (e.g., superpowers:using-git-worktrees) add some concreteness but the core brainstorming guidance remains somewhat abstract. | 2 / 3 |
Workflow Clarity | The multi-step process is sequenced (understand → document → explore → present → after design), but validation checkpoints are only implicit ('ask after each section whether it looks right'). There's no explicit error recovery or feedback loop for when the user rejects a design section or when the brainstorming process stalls. | 2 / 3 |
Progressive Disclosure | References to other skills (elements-of-style, superpowers:using-git-worktrees, superpowers:writing-plans) provide some progressive disclosure, but there are no bundle files to support the content. The Chinese documentation types (PRD, 项目介绍, 特性说明) appear inline without templates or references to example files, and would benefit from being linked to separate template files. | 2 / 3 |
Total | 8 / 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
- majiayu000/claude-skill-registry
- Commit
eb39638
- 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.