brainstorm

Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes

Quality

60%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./plugins/sdd/skills/brainstorm/SKILL.md

Quality

Content

62%

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 well-structured collaborative brainstorming workflow with clear sequencing and validation checkpoints. Its main weaknesses are the lack of concrete examples (what does a good design section or question look like?) and some redundancy between the process description and key principles. The probability-based approach generation is an interesting idea but would benefit from a concrete example to make it actionable.

Suggestions

Add a concrete example of a design section (200-300 words) and the kind of follow-up question asked after presenting it, to make the process more actionable.

Provide a template or example of the .specs/plans/<topic>.design.md output format so Claude knows exactly what to produce.

Remove or consolidate the 'Key Principles' section since most points duplicate guidance already given in 'The Process' section.

Clarify the probability-based approach generation with a brief concrete example showing what '6 approaches with probabilities' looks like in practice.

Dimension	Reasoning	Score
Conciseness	Generally efficient but includes some unnecessary elaboration. The 'Key Principles' section largely restates what was already covered in 'The Process' section, and some phrasing could be tightened (e.g., 'Help turn ideas into fully formed designs and specs through natural collaborative dialogue' is somewhat fluffy).	2 / 3
Actionability	Provides a clear process with specific steps (one question at a time, 200-300 word sections, 6 approaches with probabilities), but lacks concrete examples of what a good question looks like, what a design section looks like, or what the output .design.md format should contain. The probability sampling instruction is unusual and somewhat vague in practice. No executable code or copy-paste ready templates.	2 / 3
Workflow Clarity	The multi-step process is clearly sequenced: understand → explore approaches → present design incrementally → document → optionally implement. Each phase has explicit checkpoints (validate each section, ask before proceeding to implementation). The incremental validation loop (present section → check → continue or go back) is well-defined.	3 / 3
Progressive Disclosure	References external tools (/worktrees, /add-task, write-concisely skill) and an output path (.specs/plans/<topic>.design.md) but provides no bundle files or linked documents. The content is reasonably organized with clear sections, but the 'Key Principles' section is redundant with the process description and could be removed or restructured. For a skill of this complexity, a template or example design document would improve navigation.	2 / 3
	Total	9 / 12 Passed

Description

57%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has good structural completeness with explicit 'use when' and 'don't use' guidance, but suffers from vague capability descriptions that read more like process philosophy than concrete actions. The trigger terms are moderately useful but could be expanded with more natural user language. The skill's broad scope ('creating or developing') creates potential overlap with many other skills.

Suggestions

Replace abstract process descriptions ('collaborative questioning, alternative exploration, incremental validation') with concrete actions like 'asks clarifying questions about requirements, proposes alternative architectures, validates design decisions before implementation'.

Add more natural trigger terms users would say, such as 'brainstorm', 'architect', 'plan a feature', 'design system', 'think through', 'spec out', 'requirements gathering'.

Sharpen the distinctiveness by specifying what kind of designs (software architecture? API design? system design?) to reduce conflict risk with other planning or coding skills.

Dimension	Reasoning	Score
Specificity	The description uses vague, abstract language like 'refines rough ideas into fully-formed designs' and 'collaborative questioning, alternative exploration, and incremental validation.' These are process-level abstractions, not concrete actions like 'generates architecture diagrams' or 'produces API specifications.'	1 / 3
Completeness	It explicitly addresses both 'what' (refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation) and 'when' (before writing code or implementation plans, not during mechanical processes). The 'Use when' and 'Don't use' clauses are both present.	3 / 3
Trigger Term Quality	It includes some relevant terms like 'creating', 'developing', 'writing code', 'implementation plans', and 'design' that users might naturally say. However, it lacks specific variations like 'brainstorm', 'architect', 'plan', 'prototype', 'spec', 'requirements' that would improve coverage.	2 / 3
Distinctiveness Conflict Risk	The scope of 'creating or developing' and 'before writing code' is quite broad and could overlap with skills related to code generation, project planning, architecture design, or general brainstorming. The 'Don't use during mechanical processes' exclusion helps somewhat but is itself vague.	2 / 3
	Total	8 / 12 Passed

Validation

90%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 10 / 11 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	10 / 11 Passed

Repository: NeoLabHQ/context-engineering-kit
Commit: 3711edf

Reviewed: 20 days ago

Table of Contents

Discovery Implementation Validation

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.