This skill should be used when the user asks to "discover vision", "create a vision", "define product vision", "document vision", "what should my vision be", "help me with vision", "start requirements from scratch", "begin new product planning", "define product direction", "establish product vision", or when starting a new requirements project and needs to establish the foundational product vision before identifying epics or stories.
Provides structured methodology for discovering and documenting product vision through problem analysis, user definition, solution articulation, and success metrics. Triggers when users request to "discover vision," "define product vision," "start requirements from scratch," or begin new product planning.
/plugin marketplace add sjnims/requirements-expert/plugin install requirements-expert@requirements-expert-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
examples/sample-vision.mdreferences/5-whys-technique.mdreferences/common-pitfalls.mdreferences/success-metrics-examples.mdreferences/vision-template.md| User Intent | Action | Resource |
|---|---|---|
| Understanding the problem | Apply 5 Whys technique | references/5-whys-technique.md |
| Defining target users | Create user personas | Step 2: Identify Target Users |
| Articulating solution | Use elevator pitch format | Step 3: Define the Solution Vision |
| Establishing metrics | Apply SMART framework | references/success-metrics-examples.md |
| Documenting vision | Use template | references/vision-template.md |
| Reviewing vision quality | Check common pitfalls | references/common-pitfalls.md |
| Viewing example | Load sample | examples/sample-vision.md |
The /re:discover-vision command orchestrates the vision creation workflow. This skill provides the methodology, templates, and techniques (like 5 Whys) that the command uses. Load this skill for deeper understanding of vision discovery concepts or when you need guidance beyond what the command provides.
Vision discovery is the critical first step in the requirements lifecycle. A clear, well-articulated product vision provides direction for all subsequent work—epics, user stories, and tasks all flow from and align with the vision. This skill guides the process of discovering and documenting a compelling product vision through structured questioning and best practices.
A product vision defines:
The vision serves as a north star for all product decisions, helping teams stay aligned and prioritize work that delivers the most value.
Begin by exploring the problem being solved. Ask probing questions to uncover the root issue:
Key Actions:
Technique: Use the "5 Whys" technique to dig deeper into root causes. When the user describes a problem, ask "why is that a problem?" repeatedly to uncover underlying issues.
Output: Clear problem statement with root cause identified. Documented current state, workarounds, and consequences of inaction.
Examples:
Clearly define who will use and benefit from the solution:
Key Actions:
Technique: Create user personas with specific, concrete details. Interview or research actual users when possible. Prioritize users by frequency of use and criticality of their needs.
Output: Documented user personas or archetypes with specific characteristics. Clear distinction between primary and secondary users. Avoid vague descriptions like "business users"—be specific: "marketing managers at mid-size B2B companies tracking campaign ROI."
Examples:
Articulate what the solution is and how it addresses the problem:
Key Actions:
Technique: Use the "elevator pitch" format: "For [target users] who [need/problem], [product name] is a [category] that [key benefit]. Unlike [alternatives], our product [unique differentiator]."
Output: One-sentence product description. Clear value proposition. Defined scope boundaries (what's included and explicitly excluded). Core capabilities identified.
Examples:
Define how success will be measured:
Key Actions:
Technique: Apply the SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound). Focus on leading indicators of value rather than vanity metrics. Distinguish between adoption metrics, engagement metrics, and outcome metrics.
Output: Specific, measurable success criteria with clear targets and timeframes. Avoid vanity metrics—focus on indicators of genuine value and impact.
Examples:
Create a structured vision document in GitHub Projects as an issue with Type: Vision. Use the template structure from references/vision-template.md.
Key Actions:
Technique: Use the vision template structure. Synthesize outputs from Steps 1-4 into a cohesive document. Keep it concise (500-1,000 words total). Review with stakeholders before finalizing.
Output: Complete vision document as a GitHub issue with all required sections and proper metadata (Type: Vision, labels, custom fields).
Core Sections:
Additional Sections (as applicable):
Strategic Alignment - Business goals, market opportunity, competitive landscape
Risks & Assumptions - Key assumptions that must hold true, known risks and mitigations
Examples:
type:vision labelA vision should be digestible in 5-10 minutes. Aim for:
Balance ambition with achievability:
The vision defines direction, not implementation:
Before finalizing the vision:
Vision is not set in stone:
Watch for visions that are too vague, too prescriptive, have scope creep, unmeasurable success, missing user focus, or solution-before-problem thinking. See references/common-pitfalls.md for detailed examples and remediation.
Create the vision as a GitHub issue in the relevant GitHub Project:
Issue Title: "Product Vision: [Product Name]"
Issue Description: Full vision document with all sections
Two-Layer Metadata (both required):
Set BOTH custom fields AND labels to ensure proper filtering:
| Layer | Field | Value | Purpose |
|---|---|---|---|
| Custom Field | Type | Vision | Project views and filtering |
| Custom Field | Status | Active | Project status tracking |
| Label | type:vision | - | Cross-project queries, API filtering |
Why both? Custom fields are project-specific and enable GitHub Projects views and filtering. Labels are portable across GitHub and enable API-based filtering and cross-project queries.
The vision issue becomes the parent of ALL epics. This establishes the root of the requirements hierarchy:
Vision Issue (#1, Type: Vision)
└── Epic Issue (#2, parent: #1)
└── Epic Issue (#3, parent: #1)
└── Epic Issue (#4, parent: #1)
This hierarchy enables:
All epics will be created as child issues of this vision issue, establishing clear traceability throughout the requirements lifecycle.
For detailed guidance and templates:
| Reference | When to Load | Path |
|---|---|---|
| vision-template.md | Creating vision issue content or documenting vision | references/vision-template.md |
| 5-whys-technique.md | Conducting root cause analysis during problem discovery | references/5-whys-technique.md |
| success-metrics-examples.md | Defining SMART success metrics for the vision | references/success-metrics-examples.md |
| common-pitfalls.md | Reviewing vision quality or troubleshooting vision issues | references/common-pitfalls.md |
Working examples that can be copied and adapted:
| Example | Use Case | Path |
|---|---|---|
| sample-vision.md | Viewing a complete vision document | examples/sample-vision.md |
Load these skills when vision work reveals needs beyond this skill's scope:
| Vision Context | Load Skill | Routing Trigger |
|---|---|---|
| Vision is complete and user wants to break it down | epic-identification | User is ready to identify major capabilities from vision |
| Vision needs stakeholder validation | requirements-feedback | User needs to gather input on vision elements |