workflow-foundation-to-design
This command runs a connected 7-8 day workflow combining a 2-day Foundation Sprint (establishing strategic alignment and a Founding Hypothesis) with a 5-day Design Sprint (validating that hypothesis through prototype testing). Use this when you need to move from strategic question to validated customer feedback in a single, narrative-connected arc, where the riskiest assumptions identified during foundation work become the Design Sprint's testing focus.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/product-on-purpose/pm-skills/HEAD/commands/workflow-foundation-to-design.md -o ~/.claude/commands/workflow-foundation-to-design.mdworkflow-foundation-to-design.md
Run the end-to-end arc that pairs a Foundation Sprint (2 days of strategic alignment) with a Design Sprint (5 days of prototype validation) as one connected 7-8 day flow. There is no bridge skill: canonical Knapp/Zeratsky methodology has no formal handoff move between the two sprints, and pm-skills does not invent one. The Founding Hypothesis from the Foundation Sprint is consumed directly as input context by the Design Sprint readiness and brief steps; the handoff is narrative only. ## Workflow Steps ### Step 1: Foundation Sprint (Days 1-2) Run the full Foundation Sprint using the `/workflow-foundation-sprint` command (or follow `skills/tool-foundation-sprint-readiness/SKILL.md` through `skills/tool-foundation-sprint-founding-hypothesis/SKILL.md` in sequence). Output: a canonical Founding Hypothesis sentence plus an assumption scorecard. ### Step 2: Narrative handoff Carry the Founding Hypothesis and its highest-risk assumptions forward as the framing context for the Design Sprint. No intermediate artifact is required: the riskiest assumption on the scorecard typically becomes the Design Sprint's challenge and sprint questions. See `docs/guides/using-foundation-sprint.md` and `docs/guides/using-design-sprint.md` for the handoff narrative. ### Step 3: Design Sprint (Days 3-8) Run the full Design Sprint using the `/workflow-design-sprint` command (or follow `skills/tool-design-sprint-readiness/SKILL.md` through `skills/tool-design-sprint-test-and-score/SKILL.md` in sequence), seeding the readiness and brief steps with the Founding Hypothesis from Step 1. Output: the Decider's build / iterate / pivot / stop call grounded in five customer interviews. ## Output A strategic frame (Founding Hypothesis) validated or invalidated end-to-end by a tested prototype and a Decider's call, in one connected arc. Reference the end-to-end workflow at `_workflows/foundation-to-design.md` for the full narrative, including the handoff 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.