chain
The chain command executes a sequence of pm-skills in specified order with shared context, parsing skill names from separators (commas or arrows) and treating everything after as context. Use it for ad-hoc, temporary workflows where you need multiple skills to run sequentially while passing information between steps, then convert to durable chains via the pm-workflow-builder when the sequence proves valuable.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/product-on-purpose/pm-skills/HEAD/commands/chain.md -o ~/.claude/commands/chain.mdchain.md
Run an ad-hoc chain of pm-skills in the order given, passing the shared context to every step. ## Parse the input `$ARGUMENTS` carries a chain expression followed by free-form context. 1. Extract flags first, wherever they appear: `--auto`, `--force-auto`, `--dry-run`, `--thread`. 2. The chain expression is exactly the leading separator-joined list of skill names (`,` and `->` equivalent; mixing allowed). It ends after the first name that is NOT followed by a separator; everything after that is the context, even when the context words look like skill names. A trailing separator with nothing after it is an error to surface, not to guess around. 3. Everything after the chain expression is the context. This command parses the BOUNDARY only; all skill-name validation belongs to the engine. Examples: `/chain define-problem-statement -> define-hypothesis --thread Mobile checkout drop-off` runs two steps with `--thread`, context "Mobile checkout drop-off". Lowercase context is fine: `/chain deliver-prd, deliver-user-stories mobile checkout redesign` is two steps with context "mobile checkout redesign" (the boundary is the missing separator after `deliver-user-stories`, not the letter case). ## Confirm and dispatch 1. Restate in one line: the parsed steps in order, the flags, and the context. 2. Invoke the `utility-pm-workflow-orchestrator` skill from `skills/utility-pm-workflow-orchestrator/SKILL.md` with that chain, context, and flags (a Mode B run). The engine validates every name pre-flight and owns all run rules; this command adds none. The grammar lives in `skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md` (Mode B Chain Expression Contract). 3. Relay the engine's per-step blocks and terminal output, including the promotion suggestion for reusable chains. Nothing is persisted beyond the engine's own gitignored run artifacts. To make a chain durable, follow the completion suggestion to `utility-pm-workflow-builder`. While the native engine path is EXPERIMENTAL, recommend `--dry-run` first. Context from user: $ARGUMENTS
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.
Creates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.