version: "1.0.0" name: product-vision description: Define a product vision around a specific person, their problem, the promised outcome, priorities, and boundaries. Use for product-direction work, not routine bug fixes.

Product Vision

The user's current instructions take precedence. Preserve existing authorization, scope, and prior decisions; this skill does not authorize additional publishing, deployment, spending, or messages.

Make the user's judgment concrete enough that a builder can reject a plausible feature because it serves the wrong person or violates a priority.

Read supplied briefs, current product evidence, and prior decisions. Separate approved choices, observations, hypotheses, and unknowns. Preserve agreed direction; ask only about missing decisions that materially change it.

Draft the smallest useful brief:

• Person and situation: who is trying to achieve what, and when? For a new product, name the first audience that needs the outcome most in the initial scope and what changes for them. Distinguish that audience from possible later audiences; do not use an eventual broad market to conceal an unresolved starting segment.
• Present difficulty: what do they currently do, where does it fail, and what is the consequence? A missing dashboard or manual workflow is not by itself evidence of human pain.
• Promise: what will the person be able to do, decide, or understand? Describe a meaningful outcome, not just a screen or API.
• Decisive insight and choice: what insight or contextual change makes the promise plausible, what is the relevant current alternative, and what choice gives this approach an advantage? Label unsupported differentiation as a hypothesis and explain one meaningful tradeoff the priorities resolve. A contained feature may need only a sentence; a vision does not need a business plan or a durable-moat claim.
• Priorities: ordered decision rules that resolve competing feature choices.
• Boundaries: included outcomes and tempting adjacent work to exclude.
• Success evidence: observable signs of improvement. Label proposed metrics and unknown baselines; never invent approved targets.
• Decision status: agreed, proposed, or unresolved, with the source of important decisions.

For material claims in the present difficulty and promise, preserve the source and context. Distinguish observed behavior, reported experience, product data, secondary research, and hypotheses, and note material age or population mismatches.

For a journey that needs explaining, use a short storyboard: setting, trigger, current attempt, breakdown, desired turn, and after-state. Captions may be sufficient; render an image when it helps or the user requests it. Do not require a storyboard or hosted page for every vision discussion.

Check that the promise addresses the actual breakdown and that the priorities can reject an unsuitable feature. Identify contradictory requirements and recommend a resolution. Do not manufacture customer behavior, research, or emotional consequences to strengthen a pitch.

Save to a requested path or suitable project document when a durable brief is part of the task. Present unresolved material choices for decision; do not treat a proposed addition as approved. Carry existing approval forward. If criteria are also requested, produce them with $acceptance-criteria in this task. A vision-only request ends with the brief, not development work.