CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

design-sprint

Run a structured 5-day process to prototype, test, and validate product ideas with real users. Use when the user mentions "design sprint", "validate in a week", "rapid prototype", "test with users", "de-risk before building", "GV sprint", "prototype testing", or "design workshop". Also trigger when a team needs to make a critical product decision quickly, resolve stakeholder disagreements, or test risky ideas before investing in development. Covers mapping, sketching, deciding, prototyping, and testing. For ongoing experimentation, see lean-startup. For customer job analysis, see jobs-to-be-done.

Quality

94%

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

SKILL.md
Quality
Evals
Security

Quality

Content

85%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 body is a highly actionable, well-sequenced facilitation guide with concrete time-boxes, scripts, checklists, and validation checkpoints, and it uses progressive disclosure cleanly with nine real one-level-deep reference files. Its main weakness is token efficiency: an author biography, a motivational narrative section, and re-teaching of the widely known GV methodology add tokens without operational value.

Suggestions

Remove the "About the Author" section and compress the "Core Principle" narrative to one line — the Jake Knapp biography and motivational framing add ~10 lines of tokens with no operational value for running a sprint.

Trim re-explanations of well-known Design Sprint mechanics (e.g., why 5 customers, the rationale for anonymous sketches) down to the operational instruction itself, moving rationale into references/ if it's worth keeping at all.

Consolidate the duplicate reference listings — each day's inline "See:" pointer is repeated by the "Reference Files" section; keep the inline pointers for in-flow navigation and reduce the index section to files not already linked inline (facilitation, recruiting, case-studies, remote-sprints).

DimensionReasoningScore

Conciseness

The operational core is dense (time-boxed exercises, checklists, tables), but the body pads with an "About the Author" bio of Jake Knapp, a narrative "Core Principle" section ("Traditional product development wastes months building the wrong thing"), and re-explanation of the well-known GV sprint methodology Claude already knows. Anchor 3 fits: mostly efficient with some unnecessary explanation; not 2 because padding is confined to a few sections rather than spread throughout, and not 4 because the bio and narrative sections are more than minor trimmings.

3 / 5

Actionability

Exercise-level instructions carry concrete timings ("Sketch 8 variations in 8 minutes", "30-90 minutes"), role assignments, sample interview questions ("What's this? What do you think it's for?"), incentive ranges, recruiting math ("Schedule 6 (expect 1 no-show)"), and a prototype checklist — fully executable guidance for an instruction skill. Not 4: specific examples cover all common cases across each sprint day plus variations (4-day, remote, multi-sprint).

5 / 5

Workflow Clarity

The Monday→Friday sequence is explicit with per-day goals and outputs, and validation checkpoints appear throughout: Thursday "Trial run (test with someone not on sprint team)", the prototype checklist, between-interview breaks to "Update questions if needed", and a Quick Diagnostic table with If-No→Action feedback rules. Not 4: checkpoints and feedback loops are explicit at multiple stages rather than having only minor gaps.

5 / 5

Progressive Disclosure

The body is a clear operating overview; each day ends with a signaled pointer ("See: [references/monday.md] for detailed Monday exercises") and a consolidated Reference Files index with one-line descriptions. All 9 referenced files exist and are exactly one level deep with no nested references. Not 4: navigation is easy and the split between overview and detail files is clean and complete.

5 / 5

Total

18

/

20

Passed

Description

100%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 exemplary: it states concrete actions, enumerates the five process phases, provides eight natural trigger phrases plus scenario-based triggers, and explicitly disambiguates from adjacent skills (lean-startup, jobs-to-be-done). Both "what" and "when" are answered explicitly with no vagueness or over-claiming.

DimensionReasoningScore

Specificity

"Run a structured 5-day process to prototype, test, and validate product ideas with real users" plus "Covers mapping, sketching, deciding, prototyping, and testing" lists multiple explicit concrete actions with comprehensive phase coverage. Not 4: the five phases are fully enumerated, leaving no minor coverage gaps within the skill's scope.

5 / 5

Completeness

Explicitly answers "what" (run a 5-day prototype/test/validate process covering the five phases) and "when" ("Use when the user mentions..." with concrete trigger phrases, plus "Also trigger when a team needs to make a critical product decision quickly"). Not 4: the "when" clause is fully explicit with concrete trigger phrases, matching the anchor-5 example structure exactly.

5 / 5

Trigger Term Quality

Eight quoted natural phrases ("design sprint", "validate in a week", "rapid prototype", "test with users", "de-risk before building", "GV sprint", "prototype testing", "design workshop") plus three scenario triggers, covering synonyms users would actually say. Not 4: synonym coverage (GV sprint, design workshop, rapid prototype) is comprehensive, with no common variation missing.

5 / 5

Distinctiveness Conflict Risk

Clear niche (design sprint / GV sprint) with distinct triggers and explicit disambiguation from adjacent skills ("For ongoing experimentation, see lean-startup. For customer job analysis, see jobs-to-be-done."). Not 4: it actively redirects near-miss cases to neighboring skills, minimizing even minor overlap risk.

5 / 5

Total

20

/

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

valeriibeck-star/claude-skills

Path

skills/design-sprint/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.