brainstorming
Coordinates collaborative design sessions that explore requirements, analyze codebase context, and produce an approved design document with trade-offs. Use when building a new feature, adding functionality, creating components, modifying behavior, starting a project, or planning any creative work. DO NOT TRIGGER when the user already has a concrete design and just wants implementation.
90
88%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%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 is a strong skill description that clearly communicates its purpose (collaborative design sessions producing design documents), provides comprehensive trigger terms covering multiple natural user phrasings, and includes an explicit negative trigger to prevent conflicts with implementation-focused skills. The description is well-structured, uses third person voice correctly, and balances conciseness with completeness.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'explore requirements', 'analyze codebase context', 'produce an approved design document with trade-offs'. These are clear, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (coordinates collaborative design sessions, explores requirements, analyzes codebase, produces design document) and 'when' (explicit 'Use when...' clause with multiple triggers plus a 'DO NOT TRIGGER' exclusion clause). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'building a new feature', 'adding functionality', 'creating components', 'modifying behavior', 'starting a project', 'planning'. The negative trigger ('already has a concrete design and just wants implementation') also helps with selection accuracy. | 3 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche around design/planning sessions distinct from implementation skills. The explicit 'DO NOT TRIGGER' clause for implementation requests further reduces conflict risk with coding/implementation skills. | 3 / 3 |
Total | 12 / 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 strong workflow-oriented skill with excellent actionability and workflow clarity. The multiple HARD-GATE blocks and explicit stop points make the process safe and well-bounded. The main weakness is moderate redundancy — the approval gates are stated three different ways, and the dot graph largely duplicates the checklist — which slightly inflates token usage without adding proportional value.
Suggestions
Remove the dot graph or the detailed checklist — having both is redundant. The checklist is more actionable, so consider keeping it and dropping the graph.
Consolidate the three HARD-GATE blocks into a single 'Gates' section referenced from the checklist, reducing repetition while preserving safety.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably efficient but has some redundancy — the HARD-GATE blocks repeat the same 'stop and wait for approval' instruction three times, and the anti-pattern section explains something that could be a single sentence. The dot graph duplicates the checklist. However, most content earns its place given the complexity of the workflow. | 2 / 3 |
Actionability | The skill provides concrete, specific guidance: exact file paths (docs/plans/YYYY-MM-DD-<topic>-design.md), bash commands for worktree detection, specific scout names and types, branch naming conventions, and clear invocation references to other skills (kit:git-worktrees, kit:team-orchestration, kit:writing-plans). Every step is actionable. | 3 / 3 |
Workflow Clarity | The workflow is exceptionally clear with a numbered checklist, explicit STOP gates for validation/approval, a process flow diagram, feedback loops (revise and re-present if not approved), and clear re-entry handling. The HARD-GATE blocks serve as explicit validation checkpoints for destructive/irreversible transitions. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's somewhat monolithic — the dot graph, the detailed scout phase, dialogue guidance, and post-design steps could potentially be split into referenced files. For its length (~150 lines of substantive content), it's borderline but the inline detail is manageable. References to external skills (kit:git-worktrees, kit:writing-plans) are well-signaled. | 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.
- Repository
- shousper/claude-kit
- Commit
a01bac9
- 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.