Tool Design Sprint Readiness

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 2abfbb961d31 · 19 Oct 2026Report an issue or request a re-scan

• Publisherproduct-on-purpose GitHub organizationOwner of the repository this skill is read from
• Source folderproduct-on-purpose/pm-skills/skills/tool-design-sprint-readinessThe exact folder we audited
• LicenceApache-2.0As the repository states it
• Commit pinned for this verdict2abfbb961d31A new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Pre-sprint diagnostic that determines whether a team should run a Design Sprint now, postpone it, or do prerequisite work first. Produces a Go / Conditional Go / Wait verdict with diagnosis, recommended preconditions,…

---
name: tool-design-sprint-readiness
description: Pre-sprint diagnostic that determines whether a team should run a Design Sprint now, postpone it, or do prerequisite work first. Produces a Go / Conditional Go / Wait verdict with diagnosis, recommended preconditions, attendee list, customer recruiting plan, and pre-sprint activities. Use when a team is considering starting a Design Sprint and wants a fast yes/no diagnosis before committing five days of team time and customer recruiting cost.
license: Apache-2.0
metadata:
  classification: tool
  version: "1.0.0"
  updated: 2026-07-04
  tool: design-sprint
  move: readiness
  category: coordination
  frameworks:
    - design-sprint
    - sprint
    - character-note-and-vote
  timebox_minutes: 45
  roles:
    - facilitator
    - pm
    - decider
  prerequisites: []
  inputs:
    - challenge description
    - existing hypothesis (from Foundation Sprint or other source)
    - customer access status
    - decider availability
    - team composition draft
  outputs:
    - readiness verdict
    - diagnosis
    - recommended preconditions
    - recommended attendee list
    - customer recruiting plan
    - pre-sprint activities
  author: product-on-purpose
---

<!-- 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. **Chal

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/product-on-purpose/pm-skills
git -C pm-skills checkout 2abfbb961d31

Works in

1. 2026-10-19
   ✓SAFE B 89 / 100

   first audit · source 2abfbb961d31

Questions about Tool Design Sprint Readiness

• github.com/product-on-purpose/pm-skills/tree/main/skills/tool-de — the audited source at commit 2abfbb961d31 and every finding aboveObserved · 19 Oct 2026

Spotted something wrong? Report a correction · Methodology