| name | product-and-scope-review |
| description | Reframes solution-framed requests into product-aware planning inputs. Use when the user presents a feature idea, the real problem is fuzzy, or scope/ambition needs to be deliberately held, expanded, or reduced before drafting the spec. |
Product and Scope Review
Planning-front-door skill for clarifying the problem before formal spec work begins.
When to Use
- The request jumps straight to a solution without clearly stating the problem.
- Scope feels too vague, too small, or suspiciously overbuilt.
- You need to choose whether to hold, expand, or reduce scope before planning.
Modes
hold default: keep scope close to the ask, but challenge hidden assumptions.expand: broaden scope only when it creates a meaningfully better product outcome.reduce: cut to the smallest wedge that can still validate the real user need.
Load / Do Not Load
- Load this skill before
spec-driven-development when product framing is still unstable.
- Do not use it for already-approved specs, tiny mechanical tasks, or pure implementation follow-through.
Core Workflow
- Name the User Problem: Restate the request in terms of user pain, outcome, or operational need.
- Challenge the Framing: Surface the assumptions hidden inside the proposed solution.
- Choose a Scope Mode: Use
hold, expand, or reduce deliberately and state the choice.
- Write the Planning Handoff: Produce the framing, chosen scope mode, key tradeoffs, and success criteria that the spec must inherit.
Ask / Escalate
- Ask when the right scope depends on business priorities, rollout appetite, or audience differences that are not discoverable from the repo.
- Escalate if changing scope would alter security boundaries, pricing, external contracts, or persistent data commitments.
References
- Detailed guidance:
references/guidance.md
