product-shaping

Category: Development & Coding | Uploader: kiku-jw | Downloads: 0 | Version: v1.0（Latest）

Shape product work with the minimum useful framework after an idea clears basic validation. Use for assumptions, experiments, opportunity-solution trees, strategy, value proposition, or pre-mortems when the next product decision is still fuzzy.

Changelog: Source: GitHub https://github.com/kiku-jw/product-shaping-skill

Directory Structure

Current level: Root

📁 agents/
- 📄 openai.yaml 280 B
📁 references/
- 📄 patterns.md 2.1 KB
📄 LICENSE 33.3 KB
📄 README.md 1.4 KB
📄 SKILL.md 2.2 KB

SKILL.md

---
name: product-shaping
description: Shape product work with the minimum useful framework after an idea clears basic validation. Use for assumptions, experiments, opportunity-solution trees, strategy, value proposition, or pre-mortems when the next product decision is still fuzzy.
---

# 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 `/Users/nick/.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.

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

product-shaping

Directory Structure

SKILL.md

Report

Notice