workflow-feature-kickoff
The workflow-feature-kickoff slash command executes a structured four-step feature development process that transforms a problem statement into sprint-ready user stories. It sequentially applies skills to define the problem, establish a testable hypothesis, create a detailed product requirements document, and generate implementation-ready user stories with acceptance criteria in Given/When/Then format. Use this command when initiating a new feature to ensure comprehensive planning before development begins.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/product-on-purpose/pm-skills/HEAD/commands/workflow-feature-kickoff.md -o ~/.claude/commands/workflow-feature-kickoff.mdworkflow-feature-kickoff.md
Run the Feature Kickoff workflow to go from problem to implementation-ready user stories. This workflow uses multiple skills in sequence. For each step, read the skill instructions and follow them to create the artifact. ## Workflow Steps ### Step 1: Problem Statement Use the `define-problem-statement` skill from `skills/define-problem-statement/SKILL.md`. Create a clear problem framing document that defines: - What problem are we solving? - Who is affected? - What does success look like? ### Step 2: Hypothesis Use the `define-hypothesis` skill from `skills/define-hypothesis/SKILL.md`. Based on the problem statement, create a testable hypothesis: - What do we believe will solve the problem? - How will we measure success? ### Step 3: PRD Use the `deliver-prd` skill from `skills/deliver-prd/SKILL.md`. Create a Product Requirements Document that specifies: - What we're building - What's in scope and out of scope - Success metrics - Technical considerations ### Step 4: User Stories Use the `deliver-user-stories` skill from `skills/deliver-user-stories/SKILL.md`. Break the PRD into implementable user stories: - Each story follows INVEST criteria - Include acceptance criteria in Given/When/Then format - Ready for sprint planning ## Output Create all four artifacts in sequence, ensuring each builds on the previous. Reference the Feature Kickoff workflow at `_workflows/feature-kickoff.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.