he-brainstorm
Define problem scope, requirements, and decision options before spec or plan stages. Use when the user has ambiguity in what to build, why it matters, or which direction to choose.
59
68%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./Plugins/harness-engineering/fixtures/budget-archive/2026-04-21/deferred-store/skills/team_automation/he-brainstorm/SKILL.mdQuality
Discovery
67%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 a solid structure with both 'what' and 'when' clauses clearly articulated, which is its strongest aspect. However, the capabilities described are somewhat abstract (define scope, requirements, options) rather than listing concrete actions, and the trigger terms could better cover the natural language users would employ when they need this kind of help. The positioning as a pre-spec stage is useful for distinctiveness but could be sharper.
Suggestions
Add more concrete actions like 'identify stakeholders, map constraints, evaluate trade-offs, create decision matrices' to increase specificity.
Expand trigger terms to include natural user phrases like 'not sure what to build', 'unclear requirements', 'need to decide between options', 'scoping a project', or 'exploring approaches'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (problem scoping, requirements, decision options) and some actions (define), but the actions are somewhat abstract rather than listing multiple concrete, specific operations like 'gather stakeholder requirements, create decision matrices, document trade-offs'. | 2 / 3 |
Completeness | Clearly answers both 'what' (define problem scope, requirements, and decision options before spec or plan stages) and 'when' (use when the user has ambiguity in what to build, why it matters, or which direction to choose) with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'ambiguity', 'what to build', 'requirements', and 'direction to choose', but misses common natural user phrases like 'not sure what to build', 'brainstorm options', 'clarify requirements', 'scoping', or 'trade-offs'. | 2 / 3 |
Distinctiveness Conflict Risk | The description positions itself as a pre-spec/pre-plan stage skill, which helps distinguish it, but terms like 'requirements' and 'problem scope' could overlap with specification-writing or planning skills. The 'before spec or plan stages' qualifier helps but the boundary could be clearer. | 2 / 3 |
Total | 9 / 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 strong workflow clarity and excellent progressive disclosure design. Its main weaknesses are moderate redundancy across sections (Use/When to use, Outputs/Validation, Constraints/Anti-patterns) and a lack of concrete executable examples such as a sample requirements artifact template or a worked interaction example. The procedural steps are clear and include appropriate validation gates and fail-fast behavior.
Suggestions
Add a concrete example of a minimal requirements artifact with frontmatter (schema_version, spec_required, risk_level, complexity) and R-ID format to make the output specification actionable and copy-paste ready.
Consolidate 'Use' and 'When to use' into a single section, and merge overlapping content between Outputs/Validation and Constraints/Anti-patterns to reduce redundancy and improve token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but contains significant redundancy—'When to use' largely repeats 'Use', outputs and procedure overlap with validation, and anti-patterns partially restate constraints. Several sections could be tightened without losing information. | 2 / 3 |
Actionability | The procedure provides a clear 13-step sequence with specific decision points and concrete output fields (spec_required, risk_level, complexity), but lacks executable examples—no sample requirements artifact, no template showing the frontmatter schema, no concrete question-asking demonstration. Guidance is specific but not copy-paste ready. | 2 / 3 |
Workflow Clarity | The 13-step procedure is clearly sequenced with explicit validation gates (step 12 blocks handoff on unresolved items), a fail-fast rule, pressure-test checkpoint (step 6), and clear decision branches (step 1 skips brainstorm if unnecessary, step 8 handles single vs. multiple paths). The validation section adds additional checkpoints for completeness. | 3 / 3 |
Progressive Disclosure | The skill is explicitly designed as a progressive disclosure entry point, with a concise overview body and well-organized 'Full Context' section providing one-level-deep references to the full guide, requirements artifact contract, workflow details, discovery interview, and other supporting files. Navigation is clear and well-signaled. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
90%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 |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
- Repository
- jscraik/Agent-Skills
- Commit
4c78f98
- 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.