brainstorming
tessl i github:obra/superpowers --skill brainstormingYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Review Score
67%
Validation Score
10/16
Implementation Score
85%
Activation Score
32%
Generated
Validation
Total
10/16Score
Passed| Criteria | Score |
|---|---|
description_trigger_hint | Description may be missing an explicit 'when to use' trigger hint (e.g., 'Use when...') |
metadata_version | 'metadata' field is not a dictionary |
license_field | 'license' field is missing |
body_examples | No examples detected (no code fences and no 'Example' wording) |
body_output_format | No obvious output/return/format terms detected; consider specifying expected outputs |
body_steps | No step-by-step structure detected (no ordered list); consider adding a simple workflow |
Implementation
Suggestions 2
Score
85%Overall Assessment
This is a well-structured skill with excellent workflow clarity and appropriate progressive disclosure. The content is concise and respects Claude's intelligence. The main weakness is the lack of concrete examples - showing a sample question sequence or a snippet of what a design section should look like would make it more immediately actionable.
Suggestions
- Add 2-3 example questions demonstrating the 'one question at a time' and 'multiple choice preferred' principles
- Include a brief example of what a 200-300 word design section looks like in practice
| Dimension | Score | Reasoning |
|---|---|---|
Conciseness | 3/3 | The content is lean and efficient, with no unnecessary explanations of concepts Claude already knows. Every section serves a clear purpose and the bullet points are tight and actionable. |
Actionability | 2/3 | Provides clear process guidance and principles, but lacks concrete examples of questions to ask, sample design section outputs, or specific file path patterns. The guidance is more procedural than executable. |
Workflow Clarity | 3/3 | Clear multi-step workflow with explicit phases (understanding → exploring → presenting → documentation → implementation). Includes validation checkpoints ('ask after each section whether it looks right') and feedback loops ('go back and clarify'). |
Progressive Disclosure | 3/3 | Well-organized with clear sections and appropriate references to other skills (elements-of-style, superpowers:using-git-worktrees, superpowers:writing-plans). Content is appropriately scoped for a SKILL.md overview. |
Activation
Suggestions 3
Score
32%Overall Assessment
This description suffers from being overly broad and vague. While it attempts to establish when to use the skill, the triggers are so generic ('any creative work', 'creating features') that it would conflict with most development-related skills. The actual capabilities ('explores user intent, requirements and design') are abstract and don't convey concrete actions.
Suggestions
- Replace vague capability statement with specific actions (e.g., 'Conducts requirements gathering sessions, creates user stories, drafts technical specifications, identifies edge cases')
- Narrow the trigger scope to specific scenarios rather than 'any creative work' (e.g., 'Use when starting a new feature, when requirements are unclear, or when the user asks for help planning implementation')
- Add distinctive terminology that separates this from general coding skills (e.g., 'requirements analysis', 'design exploration', 'specification drafting')
| Dimension | Score | Reasoning |
|---|---|---|
Specificity | 1/3 | Uses vague, abstract language like 'creative work', 'features', 'components', 'functionality' without describing concrete actions. 'Explores user intent, requirements and design' is generic and doesn't specify what the skill actually does. |
Completeness | 2/3 | Has a 'when' clause ('before any creative work - creating features, building components...') but the 'what' is weak ('Explores user intent, requirements and design'). The when clause is overly broad rather than providing explicit, useful triggers. |
Trigger Term Quality | 2/3 | Contains some relevant terms like 'features', 'building components', 'adding functionality', 'modifying behavior' that users might say, but these are very broad and could apply to almost any development task. Missing specific natural language triggers. |
Distinctiveness Conflict Risk | 1/3 | Extremely generic scope - 'creative work', 'features', 'components', 'functionality', 'modifying behavior' would conflict with virtually any development or coding skill. No clear niche or distinct triggers. |