CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ce-brainstorm

Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-engineered orchestration body: it routes each phase to the right reference file, fixes exact artifact and config contracts, and gates completion on an explicit check. The main costs are maximal-density sentences that re-read heavily, and lateral cross-references among the 21 reference files that make full protocol runs pull in several hops beyond the body's one-level map.

Suggestions

Split the compound sentences (especially "Done, on the brainstorm path" and the tiering paragraph) into shorter rule statements — the same content in fewer, simpler clauses would reduce re-reading without losing any rule.

Name the rendering reference explicitly (e.g., "references/markdown-rendering.md or references/html-rendering.md per the resolved OUTPUT_FORMAT") instead of "the rendering reference".

Deduplicate the lightweight-tier rules stated in both the Outcome paragraph and the "Lightweight work ends in chat" paragraph, and consider replacing the hard-coded "current year is 2026" with a resolution rule that does not age.

DimensionReasoningScore

Conciseness

The body is dense and assumes Claude's competence — it explains no general concepts and every sentence carries a skill-specific rule (e.g., "Resolve `<root>` the first time you compose or read a `<root>/` path, never earlier"). It falls short of anchor 5 because of over-stuffed sentences (the ~70-word "Done, on the brainstorm path" sentence), repetition of the lightweight/tier rules between the Outcome and "Lightweight work ends in chat" paragraphs, and the hard-coded "The current year is 2026" date, which is time-sensitive and could be stated more compactly. Not 3 — there is no padded or unnecessary explanation anywhere.

4 / 5

Actionability

For an instruction-only skill the guidance is fully concrete: an exact artifact path pattern (`<root>/plans/YYYY-MM-DD-HHMM-<type>-<topic>-plan.<md|html>`), specific frontmatter keys (`artifact_contract: ce-unified-plan/v1`, `product_contract_source: ce-brainstorm`), executable config-resolution steps including the command `git rev-parse --show-toplevel`, and per-phase read-first file assignments. This matches anchor 5's concrete, specific, executable guidance; the minor indirection of "the rendering reference" is resolvable via the stated OUTPUT_FORMAT precedence and output-mode.md.

5 / 5

Workflow Clarity

The phase table gives a clear ordered sequence (0.0 output mode through 4 handoff) with an explicit validation gate — "do not declare it written or enter Phase 4 while any check fails" — plus a stop-and-route classification and a tier tie-break rule ("when the tier is uncertain, take the heavier one"). It stays at anchor 4 rather than 5 because the Ready for Planning Check's actual contents and any fix-and-revalidate feedback loop are deferred to references/plan-write.md rather than stated here, so checkpoints are named but not detailed in the body.

4 / 5

Progressive Disclosure

The body is a genuine overview: the Execution Flow table maps each phase to exactly which reference file to read first and what only that file carries, and every referenced file (phase-0.md, dialogue.md, approaches.md, plan-write.md, handoff.md, model-tiers.md, etc.) was verified to exist in references/. Scored against the actual bundle: it is not anchor 5 because reference files cross-reference each other laterally (phase-0.md → visual-probes.md → interaction-rules.md; plan-write.md → brainstorm-sections.md → markdown-rendering.md), creating multi-hop read chains, and one pointer ("the rendering reference") is indirect rather than naming the file.

4 / 5

Total

17

/

20

Passed

Description

82%Weight 40%Scale 1-5

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

A strong description with explicit what/when trigger guidance and unusually good boundary routing that names when to use other skills instead. The only real gap is capability coverage — it states one composite outcome action rather than enumerating what the skill concretely does (dialogue, tier classification, artifact writing).

Suggestions

Enumerate 2-3 concrete actions the skill performs (e.g., "runs a one-question-at-a-time dialogue, classifies work size, and writes a requirements-only plan under <root>/plans/") to lift specificity beyond a single composite action.

Add one or two natural trigger synonyms such as "explore an idea" or "flesh out a feature" to broaden the when-clause's keyword coverage.

DimensionReasoningScore

Specificity

"Explore vague or ambitious ideas into a right-sized requirements-only unified plan" names the domain and a single concrete outcome, but the description lists only that one composite action rather than several distinct capabilities. It matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) — not 4 because there is no list of multiple specific actions, and not 2 because the stated action is concrete rather than generic.

3 / 5

Completeness

Both questions are answered explicitly: the what is "Explore vague or ambitious ideas into a right-sized requirements-only unified plan" and the when is "Use when the user wants to brainstorm or scope what to build" with concrete trigger phrases. It cannot be 4 because the when-clause is already explicit and specific, matching anchor 5's model.

5 / 5

Trigger Term Quality

"Use when the user wants to brainstorm or scope what to build" covers the natural phrases users would say (brainstorm, scope, what to build). A few natural variants are missing (e.g., "explore an idea", "flesh out", "requirements"), fitting anchor 4 rather than 5's comprehensive synonym coverage, but well above anchor 3's partial keyword set.

4 / 5

Distinctiveness Conflict Risk

The description actively disambiguates from adjacent skills: "Not for executing already-specified work" and "Use ce-pov for a verdict on adopting a named external technology" draw explicit boundaries. This is a clear niche with minimal conflict risk, matching anchor 5; no neighboring anchor includes negative-boundary routing of this kind.

5 / 5

Total

17

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

EveryInc/compound-engineering-plugin

Path

skills/ce-brainstorm/SKILL.md

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.