Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars49
LicenseLICENSE
Default branchmain
Open issues2
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md2,662 B
docsSUMMARY.md2,622 B
History
First seen on skills.sh
First recorded snapshot · 336 installs
SKILL.md
Domain Context
This skill implements a proven product management framework. The approach combines best practices from industry leaders and is designed for practical application in day-to-day PM work.
Input Requirements
Context about your product, feature, or problem
Relevant data, research, or constraints (recommended but optional)
Clear articulation of what you're trying to achieve
Design Sprint
What It Is
A Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing with customers. Developed by Jake Knapp at Google Ventures (now GV), it has been used by teams at Slack, Uber, Airbnb, LEGO, the New York Times, and hundreds of startups.
The core insight: Instead of debating ideas for months then building for months, compress everything into one week. By Friday, you'll have tested a realistic prototype with real customers and know whether you're on the right track.
A Design Sprint changes the defaults of how teams work:
Instead of endless brainstorming: structured individual sketching
Instead of design by committee: one Decider with authority
Instead of building real products: realistic "fake" prototypes
Instead of launching and hoping: testing with 5 target customers
When to Use It
Use a Design Sprint when:
You're starting something new and need to validate direction before committing engineering resources
Stakes are high — the project will require significant investment
You're stuck — the team has been debating the same ideas for weeks or months
There's a big behavioral risk — the product requires customers to change how they work
You need alignment — stakeholders have different visions
Time pressure exists — you have a deadline or limited runway
When Not to Use It
You already have strong signal from existing customers (iterate instead)
The solution is obvious and low-risk (just build it)
Key stakeholders can't commit to the full week
You don't have access to target customers for testing
Resources
Books:
Sprint by Jake Knapp with John Zeratsky and Braden Kowitz