CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

product-discovery

Use when validating product opportunities, mapping assumptions, planning discovery sprints, or testing problem-solution fit before committing delivery resources.

61

Quality

77%

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 ./product-team/skills/product-discovery/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%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-structured, concise overview with a clearly sequenced workflow, real decision checkpoints, and a functioning one-level-deep reference bundle. The main gap is actionability: the central tool's input format (CSV schema, inline format, scoring method) is undocumented in SKILL.md, forcing the reader into the script source to use it correctly.

Suggestions

Document the assumptions.csv schema next to the command — required columns (assumption, category, risk, certainty), that risk/certainty are 0-1 floats, and an example row — so the script is usable without reading its source.

Add one example inline invocation, e.g. python3 scripts/assumption_mapper.py --assumption "Users will pay for this | viability | 0.8 | 0.3", to demonstrate the non-CSV path and the category vocabulary the tool understands.

State the prioritization rule the script implements (priority = risk x (1 - certainty)) or point to it explicitly, and drop the generic OST structure section from the body in favor of the already-existing version in references/discovery-frameworks.md to remove duplication.

DimensionReasoningScore

Conciseness

The body is lean and directive throughout ("Prototype before build", "Measure behavior, not only stated preference", "Reject weak opportunities early"), with only minor over-explanation: the OST section restates the generic Outcome/Opportunities/Solutions/Experiments structure that is duplicated in references/discovery-frameworks.md. This fits anchor 4 (efficient, minor instances that could be trimmed) rather than anchor 5's every-token-earns-its-place.

4 / 5

Actionability

Concrete guidance exists — the executable command "python3 scripts/assumption_mapper.py assumptions.csv", quantified checks ("At least 3 distinct opportunities", "At least 2 experiments per top opportunity"), and a day-by-day sprint plan — but key details are missing: the assumptions.csv schema (columns assumption, category, risk, certainty with [0,1] values) is documented nowhere in SKILL.md and is only discoverable by reading the script, no example invocation of the inline --assumption format is given, and "Score assumptions by risk and certainty" says nothing about how. This matches anchor 3 (some concrete guidance but incomplete, missing key details) rather than anchor 4, where gaps would be minor; not anchor 2 because there is genuinely usable concrete guidance.

3 / 5

Workflow Clarity

The six-step Core Discovery Workflow is clearly sequenced with real checkpoints: "Daily evidence reviews", "End with decision: proceed, pivot, or stop", "Reject weak opportunities early", plus explicit evidence thresholds. This is not a destructive/batch operation so no cap applies; it fits anchor 4 (clear sequence, most checkpoints, minor validation gaps) rather than anchor 5 because steps like "Conduct interviews and behavior analysis" lack explicit stopping criteria and error-recovery loops for contradictory evidence are thin.

4 / 5

Progressive Disclosure

Verified against the actual bundle: both scripts/assumption_mapper.py and references/discovery-frameworks.md exist and are referenced from the body ("See references/discovery-frameworks.md for framework details"), one level deep and clearly signaled, with the script documented in a dedicated Tooling section. Fits anchor 4 (good structure, references mostly clear, minor organization gaps) rather than anchor 5 because the generic OST structure is duplicated between the body and the reference file, and the detail sections (validation techniques, 10-day plan) could largely live in the reference.

4 / 5

Total

15

/

20

Passed

Description

75%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 solid, well-scoped description with explicit trigger guidance and natural domain keywords. Its main weakness is the absence of an explicit capability statement — the "what" is implied through the actions listed in the "Use when" clause rather than stated directly.

Suggestions

Add an explicit capability statement before the trigger clause, e.g. "Run structured product-discovery sprints: build opportunity solution trees, map and prioritize assumptions, and plan validation tests. Use when...".

Include "opportunity solution tree" and "customer discovery" among the trigger terms — the OST is the skill's core framework and a phrase users actively say.

Disambiguate "planning discovery sprints" from agile delivery sprint planning, e.g. "planning discovery sprints (pre-delivery learning cycles, not delivery sprint planning)".

DimensionReasoningScore

Specificity

The description lists four specific actions ("validating product opportunities, mapping assumptions, planning discovery sprints, or testing problem-solution fit") with only minor coverage gaps. It falls short of anchor 5 because the skill's concrete capabilities (OST facilitation, assumption scoring tooling, evidence synthesis) are never stated, but exceeds anchor 3's 1-2 action threshold.

4 / 5

Completeness

The "when" is explicit and concrete ("Use when validating... before committing delivery resources"), and the "what" is present but only implicitly, embedded as gerunds in the when-clause with no standalone capability statement. This matches anchor 4 (both present, one could be more explicit) rather than anchor 5, which requires both stated explicitly.

4 / 5

Trigger Term Quality

Natural phrases users would say ("product opportunities", "mapping assumptions", "discovery sprints", "problem-solution fit") give good keyword coverage. Not anchor 5 because a few natural terms are missing — notably "opportunity solution tree" (the skill's core framework), plus "customer discovery" and "user research"; not anchor 3 since the terms present are the natural ones rather than generic.

4 / 5

Distinctiveness Conflict Risk

The vocabulary anchors the description to a clear product-discovery niche, but "planning discovery sprints" carries minor collision risk with agile delivery sprint-planning skills and "validating opportunities" overlaps generic research skills. This fits anchor 4 (mostly distinct, minor overlap with closely related skills) rather than anchor 5's minimal conflict risk.

4 / 5

Total

16

/

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

alirezarezvani/claude-skills

Path

product-team/skills/product-discovery/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.