workflow-foundation-sprint
The workflow-foundation-sprint slash command executes a structured two-day workshop that transforms early-stage product assumptions into a testable Founding Hypothesis and assumption scorecard. Use this command when an early-stage team needs strategic alignment before building, moving through seven sequential steps from readiness assessment through basics, differentiation, approach options, Magic Lenses evaluation, and final hypothesis formulation. Note that this is a workshop methodology distinct from agile sprint planning.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/product-on-purpose/pm-skills/HEAD/commands/workflow-foundation-sprint.md -o ~/.claude/commands/workflow-foundation-sprint.mdworkflow-foundation-sprint.md
Run the Foundation Sprint, a structured two-day workshop (Knapp/Zeratsky) that converts fuzzy early-stage product beliefs into a single, testable Founding Hypothesis plus an assumption scorecard. This workflow chains the 7 `tool-foundation-sprint-*` skills in their canonical sequence, with `tool-note-and-vote` invoked at decision moments throughout. For each step, read the skill instructions and follow them to produce the artifact. > Note: Foundation 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-foundation-sprint-readiness` skill from `skills/tool-foundation-sprint-readiness/SKILL.md` to diagnose whether the team should run a Foundation Sprint now, postpone, or do prerequisite work first. ### Step 2: Brief Use the `tool-foundation-sprint-brief` skill from `skills/tool-foundation-sprint-brief/SKILL.md` to lock scope, team, logistics, and success criteria before Day 1. ### Step 3: Basics (Day 1 morning) Use the `tool-foundation-sprint-basics` skill from `skills/tool-foundation-sprint-basics/SKILL.md` to produce the target customer, important problem, team advantage, and competitor map as one coherent strategic frame. ### Step 4: Differentiation (Day 1 afternoon) Use the `tool-foundation-sprint-differentiation` skill from `skills/tool-foundation-sprint-differentiation/SKILL.md` to produce scored differentiators, a 2x2 chart, decision principles, and a Mini Manifesto. ### Step 5: Approach Options (Day 2 morning) Use the `tool-foundation-sprint-approach-options` skill from `skills/tool-foundation-sprint-approach-options/SKILL.md` to generate 3-7 candidate approaches as one-page summaries for Magic Lenses evaluation. ### Step 6: Magic Lenses (Day 2 afternoon) Use the `tool-foundation-sprint-magic-lenses` skill from `skills/tool-foundation-sprint-magic-lenses/SKILL.md` to evaluate the approaches through the 4 classic plus at least 1 custom lens, then name the top bet and a backup. ### Step 7: Founding Hypothesis (Day 2 end) Use the `tool-foundation-sprint-founding-hypothesis` skill from `skills/tool-foundation-sprint-founding-hypothesis/SKILL.md` to produce the canonical hypothesis sentence, assumption scorecard, and recommended next test. 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 Founding Hypothesis (Step 7) is the final output and the input to a Design Sprint (`/workflow-design-sprint`), customer research, or a focused experiment. Reference the Foundation Sprint workflow at `_workflows/foundation-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.