Tool Design Sprint Readiness

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Design Sprint Readiness

Assess whether a Design Sprint fits the team's current situation. Design Sprint failure modes are expensive: five consecutive days of a 4-7 person team, plus customer recruiting cost (typically 5 strangers paid honoraria), plus the prototype build. A 30-45 minute readiness diagnostic catches the failure modes before that commitment is made.

Family contract: docs/reference/skill-families/design-sprint-skills-contract.md. This skill is a member of design-sprint-skills and conforms to the family frontmatter and Decider Checkpoint requirements.

When to Use

• A team is considering starting a Design Sprint and needs a fast diagnosis before committing five days plus customer recruiting effort.
• A team has just completed a Foundation Sprint and is deciding whether the next test should be a Design Sprint, a smaller experiment, or direct build. The Founding Hypothesis is consumed as optional input context (no separate bridge skill artifact is required).
• An existing sprint commitment is on the calendar and the team wants to validate that prerequisites (Decider, customers, prototype medium) are in place.
• Re-running a Design Sprint after an inconclusive first sprint: use to confirm the new challenge framing and customer access are ready.

When NOT to Use

• The team has already decided to run the sprint and just needs the brief. Use tool-design-sprint-brief instead.
• The team has no clear challenge and is still in discovery. Run problem framing or a Foundation Sprint first; a Design Sprint depends on a sprint-worthy challenge.
• Low-stakes tweaks where five days of team time would be disproportionate. Use a lighter experiment design instead.
• No customer access for Friday testing and no realistic recruiting plan. A Design Sprint that cannot test on Friday is just a four-day workshop with no learning event.
• No Decider available and one cannot be appointed. Design Sprint requires fast decisions Wednesday and pre-test Thursday; without authority the sprint produces options without commitment.

What This Skill Produces

A single bundled artifact with six sections:

1. Readiness verdict: Go / Conditional Go / Wait
2. Diagnosis: what is in place, what is missing, what is uncertain
3. Recommended preconditions (when verdict is Wait or Conditional Go): the prerequisite work the team should do before the sprint
4. Recommended attendee list (when verdict is Go or Conditional Go): the 4-7 people who should be in the room, with role expectations
5. Customer recruiting plan (when verdict is Go or Conditional Go): target profile, source, count, incentive, recruiter owner, recruiting deadline (typically 7-10 days before Friday)
6. Pre-sprint activities (when verdict is Go): the prep work to complete in the days before Monday

See references/TEMPLATE.md for the canonical structure and references/EXAMPLE.md for a worked example using the Brainshelf book-catalog thread.

Inference Inputs

The skill runs an inference pass over these inputs to produce the verdict:

If a load-bearing input is missing or low-confidence, the skill flags it explicitly and proposes how to close the gap before Monday.

Readiness Criteria (8 Canonical Checks)

The skill evaluates the team against these eight criteria, drawn from Sprint (Knapp, Zeratsky, Kowitz), GV "Is Your Idea Sprint-Worthy?", and Character Capital's Design Sprint guide:

1. Challenge is named and sprint-worthy. Specific enough to prototype in 4 days; big enough that a wrong direction would be costly.
2. Stakes are meaningful. The team would otherwise hesitate, debate, or default to building blindly. The sprint is justified by what it replaces.
3. Decider is available for the load-bearing moments. Minimum: Monday morning (framing), Wednesday morning (heat map + supervote), Friday afternoon (Decider review). Ideally all 5 days.
4. Team size is appropriate (4-7). Smaller than 4 weakens skill coverage; larger than 7 slows decision-making.
5. Team can clear 5 consecutive days. No partial attendance for core participants; cameo experts may attend specific sessions.
6. Customer access for Friday testing is secured (or recruitable in 7-10 days). 5 target-profile customers, paid honoraria, scheduled for Friday morning to early afternoon.
7. Prototype medium is feasible in 1 day. Clickable (Figma), slideware (Keynote), service role-play, paper, physical mock, or other medium that can be built Thursday by 2 people.
8. Sprint output has a path forward. The team is ready to act on validation (build, iterate, pivot to backup, or stop) when Friday's scorecard lands. Sprints without a downstream commitment become orphaned learnings.

Treat the criteria as load-bearing, not a checklist to game. A team that papers over no-customer-access with "we'll figure it out by Thursday" should get a Wait, not a Conditional Go.