CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

oma-brainstorm

Explore goals, constraints, and alternative approaches before choosing a design. Use when the user requests ideation or design exploration.

53

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/oma-brainstorm/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

58%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.

The workflow logic is genuinely strong — clear sequencing, explicit validation gates, and thorough error-recovery paths — but the document pays for it in redundancy, restating the same rules across five different sections, and never concretizes its central artifacts. Consolidating the duplicate representations and adding one example brief or design-doc template would lift both conciseness and actionability.

Suggestions

Collapse the duplicated workflow representations (Scenes, Canonical workflow path, Execution Phases, Guardrails) into a single canonical sequence plus a short guardrails/pitfalls list; rules like "one question at a time" and the TRIZ-lite applicability condition currently appear 4-6 times each.

Add one compact example of a prose brief (scenario, mechanism, residual risk, effort) and a skeleton of the docs/decisions/{NNN}-{name}.md document so the primary outputs are concrete rather than described.

Move the TRIZ-lite applicability rules and principle-set limits (max 3-5 principles, no fake scores/full ARIZ) into resources/triz-lite.md and keep a one-line trigger in the body.

DimensionReasoningScore

Conciseness

The same rules are restated many times across sections: "one question at a time" appears in Control-flow features, ACQUIRE, the canonical path, Guardrail 2, Phase 2, and Pitfalls; TRIZ-lite applicability conditions repeat ~6 times; the blind-review-before-save rule and the docs/decisions/ save path each repeat 4-5 times. Noticeably verbose from duplication, though it never explains concepts Claude already knows (not 1).

2 / 5

Actionability

Concrete specifics exist (save to `docs/decisions/{NNN}-{name}.md`, update index, Tier 1/2/3 issue consolidation, record `brainstorm.option-selection` with matching `--instance`), but the skill's key artifacts are never shown: no example prose brief (scenario/mechanism/residual risk), no design-document section template, no sample question sequence. Some concrete guidance but incomplete — anchor 3, not 4 which requires mostly executable guidance.

3 / 5

Workflow Clarity

The process is clearly sequenced (Entry → PREPARE/ACQUIRE/REASON/VERIFY/FINALIZE, mirrored by Phases 1–7) with explicit validation gates ("blind review round ... before saving", "resolve Tier 1 issues") and genuine feedback loops (user rejects → revise; question unanswered → propose assumptions; approaches collapse → identify constraint, optionally TRIZ reseed; implementation pressure → defer). Matches the anchor-5 example of explicit validation steps with error-recovery loops.

5 / 5

Progressive Disclosure

No bundle files ship in this review copy, but the body's references (resources/triz-lite.md and five ../_shared/core/*.md files) are one level deep and clearly signaled in a dedicated References section. Minor gaps: three parallel inline representations of the same workflow (Scenes, Canonical workflow path, Execution Phases) keep content inline that is redundant rather than split out — good structure but not the clean overview/subfile split of anchor 5.

4 / 5

Total

14

/

20

Passed

Description

58%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.

The description is clear, correctly voiced in third person, and answers both what and when, but it stays at a high level of abstraction. Adding natural trigger phrases and naming the concrete output (an approved design document) would sharpen it considerably.

Suggestions

Add natural trigger phrases users would actually say, e.g. "Use when the user says 'I have an idea', wants to brainstorm, compare approaches, or explore a design before planning."

Name the concrete output to boost specificity and distinctiveness, e.g. "...before choosing a design, producing an approved design document for downstream planning."

Distinguish from adjacent skills, e.g. "Use before /plan when requirements are still ambiguous; not for implementation or review."

DimensionReasoningScore

Specificity

"Explore goals, constraints, and alternative approaches before choosing a design" names the domain (design/ideation) and 1-2 actions (explore constraints, compare approaches), but mentions no concrete outputs or artifacts. Not 4: it does not list several specific actions the way "Extracts text, fills forms, converts pages" does.

3 / 5

Completeness

Both what ("Explore goals, constraints, and alternative approaches before choosing a design") and when ("Use when the user requests ideation or design exploration") are explicitly present. Not 5: the when-clause lacks concrete trigger phrases and could be more specific about the request shapes that warrant this skill.

4 / 5

Trigger Term Quality

Triggers are limited to "ideation or design exploration"; the natural phrases users actually say ("brainstorm", "I have an idea", "compare approaches", "help me design") are missing even though the body's intent signature lists them. Some relevant keywords but missing common variations — anchor 3, not 4 which requires good keyword coverage.

3 / 5

Distinctiveness Conflict Risk

The pre-design exploration niche is somewhat specific, but "design" and "explore" are broad terms that could overlap with planning, architecture, or UI-design skills; the description does not state outputs that would disambiguate it. Not 4: overlap risk extends beyond closely related skills only.

3 / 5

Total

13

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

first-fluke/oh-my-agent

Path

skills/oma-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.