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`](../../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:

| Input | What the skill does with it |
|---|---|
| Challenge description | Determines whether the challenge is sprint-worthy (specific enough to prototype in 4 days; big enough to justify 5 team-days) |
| Existing hypothesis (from Foundation Sprint or elsewhere) | Confirms there is a testable bet, not exploratory discovery. Highest-risk assumption from the FS scorecard becomes a candidate sprint question |
| Customer access status | Critical. Without realistic Friday customer access, the sprint cannot test |
| Decider name and full-week availability | Confirms Decider can attend at least Monday morning, Wednesday morning (heat map + supervote), and Friday afternoon (Decider review); ideally all 5 days |
| Team composition draft | Checks roster against the 4-7 person band; flags missing roles (engineering for prototype build, design for sketching, researcher or PM for customer interviews) |
| Prototype medium feasibility | Confirms a 1-day prototype is achievable in the chosen medium (clickable, slideware, service role-play, paper, physical mock) |
| (Optional) Logistics constraints | Confirms five consecutive days can actually be cleared by all attendees |

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 land