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.From its SKILL.md
npx -y skills add bg-szy/TOP-SKILLS --skill design-sprintAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.7 KB, 684 tokens by cl100k_base, as published. Nobody here has run it
Design Sprint Framework
Core Framework
The Design Sprint compresses product development cycles into five days: Map (Monday), Sketch (Tuesday), Decide (Wednesday), Prototype (Thursday), and Test (Friday).
Prerequisites:
- Important problem worth dedicated focus
- Decision maker + 4-7 diverse team members
- Full 5 days (10am-5pm, uninterrupted)
- Dedicated workspace with whiteboards
Scoring: Rate 0-10 based on adherence to structure, time-boxing, prototyping, and user testing.
Daily Breakdown
Monday: Map
- Define 2-year goal and sprint questions
- Map customer journey (5-15 steps)
- Interview experts, capture "How Might We" opportunities
- Select target customer moment for focus
Tuesday: Sketch
- Lightning demos for inspiration
- Individual solution sketches (no group brainstorming)
- Four-step process: Notes → Ideas → Crazy 8s → Solution Sketch
- Anonymous 3-panel storyboards showing user experience
Wednesday: Decide
- Gallery critique with silent dot voting
- Decider uses supervote (3 dots override)
- Create 10-15 panel storyboard for prototype
- Combine best ideas into unified solution
Thursday: Prototype
- Assign roles: Makers, Stitcher, Writer, Collector, Interviewer
- Build realistic facade (not working code)
- Tools: Figma, Keynote, or prototyping platforms
- Trial run before Friday testing
Friday: Test
- Conduct 5 customer interviews (30 minutes each)
- Five-act structure: Welcome → Context → Introduce → Tasks → Debrief
- Team observes, records patterns
- Identify what worked, what failed, next steps
Key Principles
- Five customers reveal patterns after 3-5 interviews; diminishing returns after 5
- Prototype fidelity: Facade quality—realistic enough for honest reactions, not production-ready
- No explaining: Let users interpret and struggle; observe confusion
- Decider authority: Final call on Tuesday solutions and Wednesday decision
- Time protection: No interruptions; full commitment required
Common Mistakes to Avoid
| Error | Solution |
|---|---|
| Skip prototyping | Always build, even simply |
| Over-engineer prototype | Focus on facade only |
| Test wrong users | Screen for target customers |
| Explain to users | Let them struggle independently |
| No decision maker | Commitment required or postpone |
| Interruptions | Protect focus entirely |
Variations
- 4-Day Sprint: Compress Map + Sketch into Day 1
- Remote Sprint: Use Miro/FigJam, Zoom, same structure
- Multi-Sprint: Sequential sprints on broad → detailed → refined problems
Diagnostic Checklist
Confirm before sprinting:
- Decider committed for full week
- Problem important enough
- Prototype feasible in 1 day
- Can recruit 5 target users
- Team protected from interruptions
Source: Framework developed at Google Ventures by Jake Knapp; detailed in "Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days" by Knapp, Zeratsky, and Kowitz.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.