workflow-design-sprint
The workflow-design-sprint slash command orchestrates a complete Design Sprint, a structured five-day workshop that moves from challenge definition on Monday through customer validation on Friday. It sequences seven specialized skills in canonical order, incorporating decision-making votes at critical junctures, and culminates in a Decider's build/iterate/pivot/stop recommendation based on five customer interviews conducted against a one-day prototype. Use this when your team needs to rapidly validate or invalidate a specific product challenge within a fixed timeframe.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/product-on-purpose/pm-skills/HEAD/commands/workflow-design-sprint.md -o ~/.claude/commands/workflow-design-sprint.mdworkflow-design-sprint.md
Run the Design Sprint, a structured five-day workshop (Knapp/Zeratsky/Kowitz) that takes a single challenge from blank-page Monday to a validated-or-invalidated Friday, grounded in five customer interviews against a one-day prototype. This workflow chains the 7 `tool-design-sprint-*` skills in their canonical sequence, with `tool-note-and-vote` invoked at decision moments (the Monday HMW heat-map and optional target supervote, and the Wednesday heat-map plus straw poll). For each step, read the skill instructions and follow them. > Note: Design Sprint is a workshop methodology, NOT an agile / Scrum sprint. For pm-skills' agile sprint planning, use `/workflow-sprint-planning`. ## Workflow Steps ### Step 1: Readiness Use the `tool-design-sprint-readiness` skill from `skills/tool-design-sprint-readiness/SKILL.md` to diagnose whether the team should run a Design Sprint now, postpone, or do prerequisite work first. ### Step 2: Brief Use the `tool-design-sprint-brief` skill from `skills/tool-design-sprint-brief/SKILL.md` to lock the challenge, sprint questions, team, customer recruiting plan, prototype medium, interview format, and success criteria before Monday. ### Step 3: Map and Target (Monday) Use the `tool-design-sprint-map-and-target` skill from `skills/tool-design-sprint-map-and-target/SKILL.md` to produce the long-term goal, sprint questions, customer/system map, HMW cluster board, and the Decider's target moment. ### Step 4: Sketch (Tuesday) Use the `tool-design-sprint-sketch` skill from `skills/tool-design-sprint-sketch/SKILL.md` to structure lightning demos and the four-step independent solution sketch protocol. ### Step 5: Decide and Storyboard (Wednesday) Use the `tool-design-sprint-decide-and-storyboard` skill from `skills/tool-design-sprint-decide-and-storyboard/SKILL.md` to run the art-museum layout, heat map, speed critique, straw poll, Decider supervote, and storyboard. ### Step 6: Prototype Plan (Thursday morning) Use the `tool-design-sprint-prototype-plan` skill from `skills/tool-design-sprint-prototype-plan/SKILL.md` to produce the role plan, Five-Act interview script, trial-run checklist, and participant confirmation tracker. ### Step 7: Test and Score (Friday) Use the `tool-design-sprint-test-and-score` skill from `skills/tool-design-sprint-test-and-score/SKILL.md` to run the 5 customer interviews, score the sprint questions, capture hot takes, and produce the Decider's build / iterate / pivot / stop call. Throughout, use the `tool-note-and-vote` skill from `skills/tool-note-and-vote/SKILL.md` to run structured group decisions at each decision moment. ## Output Produce each artifact in sequence. The Decider's call (Step 7) is the final output, grounded in the five customer interviews against the prototype. Reference the Design Sprint workflow at `_workflows/design-sprint.md` for additional guidance. Context from user: $ARGUMENTS
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.