CtrlK
BlogDocsLog inGet started
Tessl Logo

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

Quality

68%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

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.md
SKILL.md
Quality
Evals
Security

Quality

Content

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. Its main weakness is moderate redundancy across Use/When to use/Constraints/Anti-patterns sections and the lack of a concrete artifact example (even a minimal template) that would make the outputs section truly actionable rather than descriptive.

Suggestions

Add a minimal concrete example of a requirements artifact (even 10-15 lines) showing the frontmatter fields, R-IDs, success criteria, and the Resolve Before Planning / Deferred split to boost actionability.

Consolidate the 'Use' and 'When to use' sections into a single section to reduce redundancy and improve conciseness.

DimensionReasoningScore

Conciseness

The skill is reasonably efficient but contains notable redundancy—'When to use' largely repeats 'Use', several output bullet points restate validation checks, and anti-patterns mirror constraints. Some sections could be tightened without losing information.

2 / 3

Actionability

The procedure provides a clear 13-step sequence with concrete decision points (e.g., derive spec_required/risk_level/complexity, check Resolve Before Planning blockers), but there are no executable code snippets, template examples, or concrete artifact samples showing what a requirements artifact actually looks like. 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 dedicated Validation section with fail-fast policy, and clear decision branching (step 1 assesses need, step 8 handles single vs. multiple paths, step 13 recommends next stage). Feedback loops are present for blocking questions.

3 / 3

Progressive Disclosure

The skill is structured as a concise entrypoint with a well-organized 'Full Context' section providing clearly signaled, one-level-deep references to the full guide, requirements artifact contract, workflow details, discovery interview, and other supporting files. Navigation is easy and references are specific.

3 / 3

Total

10

/

12

Passed

Description

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 is structurally sound with a clear 'what' and 'when' clause, which is its strongest aspect. However, the actions described are somewhat abstract (define scope, requirements, decisions) and could benefit from more concrete, specific sub-tasks. The trigger terms cover the core concept but miss natural language variations users might employ when they're in an early, ambiguous phase of a project.

Suggestions

Add more concrete actions to improve specificity, e.g., 'Clarify goals, identify constraints, map stakeholders, evaluate trade-offs between approaches, and document decision rationale before spec or plan stages.'

Expand trigger terms in the 'Use when' clause with natural language variations like 'unsure what to build', 'exploring options', 'brainstorming', 'discovery phase', 'trade-off analysis', or 'not sure which approach to take'.

DimensionReasoningScore

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 tasks 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 'problem scope', 'requirements', 'decision options', and 'ambiguity', but misses common natural language variations users might say such as 'what should I build', 'brainstorm', 'explore options', 'clarify goals', 'trade-offs', or 'discovery phase'.

2 / 3

Distinctiveness Conflict Risk

The positioning 'before spec or plan stages' helps distinguish it from planning or spec-writing skills, but terms like 'requirements' and 'decision options' could overlap with project planning, architecture, or spec-writing skills in a large skill library.

2 / 3

Total

9

/

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

10

/

11

Passed

Repository
jscraik/Agent-Skills
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.