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.
66
51%
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 vagueness in what the skill actually does ('explores user intent, requirements and design') and overly broad trigger conditions that would match almost any development-related request. The use of 'You MUST' in second person also violates the third-person voice guideline. It reads more like a process mandate than a skill description.
Suggestions
Replace vague 'explores user intent, requirements and design' with specific concrete actions the skill performs, e.g., 'Generates requirements documents, creates design specifications, produces user story breakdowns'.
Narrow the trigger conditions significantly - instead of 'any creative work', specify the particular scenarios where this pre-implementation exploration is needed, e.g., 'Use when starting a new feature from scratch, when requirements are ambiguous, or when the user asks for help planning an implementation'.
Rewrite in third person voice ('Explores user intent...' is fine, but remove 'You MUST use this' and replace with something like 'Pre-implementation planning skill that...').
| 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'), but the 'what' is vague and the 'when' is overly broad. It does have explicit trigger guidance, but the what is weak. | 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 skill related to development, design, or planning. 'Creating features', 'building components', 'adding functionality', and 'modifying behavior' cover nearly all software development tasks, making it indistinguishable from many other potential skills. | 1 / 3 |
Total | 6 / 12 Passed |
Implementation
70%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-structured process skill with clear workflow sequencing and good progressive disclosure. Its main weaknesses are moderate redundancy (Key Principles repeating earlier content) and a lack of concrete examples—such as sample questions, a design document template, or an example output—that would make it more actionable. The unexplained switch to Chinese for documentation types is jarring and may not serve all users.
Suggestions
Add a concrete example of a design section output (200-300 words) showing what a good incremental design presentation looks like.
Provide a template or skeleton for the `docs/plans/YYYY-MM-DD-<topic>-design.md` output file so Claude knows the expected structure.
Remove or consolidate the 'Key Principles' section since most points are already stated in the process steps, reducing redundancy.
Either fully commit to bilingual content with clear rationale, or keep the documentation types section in one language for consistency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient but has some unnecessary padding. The mixed Chinese/English documentation section feels abrupt and could be tighter. The 'Key Principles' section largely repeats what was already stated in the process steps above, adding redundancy. | 2 / 3 |
Actionability | Provides a clear process flow and specific guidance (e.g., 200-300 word sections, one question at a time, file path pattern for design docs), but lacks concrete examples of what questions to ask, what a design section looks like, or what the output document structure should contain. No executable code or copy-paste ready templates. | 2 / 3 |
Workflow Clarity | The multi-step process is clearly sequenced: understand context → ask questions → explore approaches → present design incrementally → document → optionally implement. Validation checkpoints are explicit (check after each section, validate each part). The feedback loop of 'go back and clarify if something doesn't make sense' is present. | 3 / 3 |
Progressive Disclosure | Content is well-organized into clear sections (Overview, Process, After the Design, Key Principles). References to other skills (elements-of-style, using-git-worktrees, writing-plans) are one level deep and clearly signaled. The skill is under 50 lines and appropriately self-contained. | 3 / 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.
d156cd1
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.