Product Shaping

Metadata

• Trigger when: validation exists, but the next product decision still needs structure before implementation or spec work.
• Do not use when: the work still needs basic validation or already has a clear implementation-ready direction.

Skill Purpose

Choose one compact product-thinking frame that reduces ambiguity without drifting into PM theater or bloated process.

Instructions

1. Gate the lane first. If the real question is still build or not, route back to $idea-validation. If the spec is already clear and the next blocker is implementation, route to $spec-bundle or execution instead.
2. Choose the smallest framework that fits the actual uncertainty: assumptions, experiment design, opportunity-solution tree, product strategy, value proposition, or pre-mortem. Use ~/.codex/skills/product-shaping/references/patterns.md when you need the compact templates.
3. Produce one decision-ready output tied to the current task and end with an explicit next lane: stay in product shaping, return to validation, move to a short execution brief, or move to the appropriate level of $spec-bundle. If another skill is needed, name it explicitly with a one-line reason.

Non-Negotiable Acceptance Criteria

• One framework by default; chain only when one output clearly feeds the next.
• Trade-offs, risky assumptions, and the next concrete move are explicit.
• No generic PM ceremony, roadmap theater, or silent handoff vagueness.
• The output names the next lane instead of leaving routing implicit.

Output

• A compact framework result anchored to the current product question.
• An explicit next lane.
• The smallest next action or experiment that would reduce uncertainty fastest.
• Next skill options (only if needed): $idea-validation — go back and validate buyer/pain/signal; $spec-bundle — convert the chosen direction into contracts, schema, and gates; $product-council — run a multi-lens check on a fuzzy or risky decision.