@su-record/vibe 2.9.18 → 2.9.20

package/skills/parallel-research/templates/paper.md

@@ -0,0 +1,88 @@
+---
+topic: {{RESEARCH_TOPIC}}
+slug: {{SLUG}}
+date: {{DATE}}
+stack: [{{TECHNOLOGY_STACK_CSV}}]
+question: {{RESEARCH_QUESTION}}
+---
+
+# {{RESEARCH_TOPIC}}: A Structured Survey for Implementation
+
+**Date**: {{DATE}}
+**Stack**: {{TECHNOLOGY_STACK}}
+**Research question**: {{RESEARCH_QUESTION}}
+
+---
+
+## Abstract
+
+{{ONE_PARAGRAPH_ABSTRACT}}
+
+**TL;DR recommendation**: {{RECOMMENDATION}}
+
+## 1. Background
+
+{{PROBLEM_CONTEXT — why this matters now, what forced the investigation}}
+
+### 1.1 Prior art in this codebase
+
+{{EXISTING_PATTERNS — what's already here, at what file paths}}
+
+### 1.2 Scope
+
+- In scope: {{IN_SCOPE}}
+- Out of scope: {{OUT_OF_SCOPE}}
+
+## 2. Method
+
+Parallel research across four specialized agents (best-practices, framework-docs, codebase-patterns, security-advisory). Findings weighted by source priority: **security > official docs > codebase consistency > community consensus > blog posts**.
+
+## 3. Findings
+
+### 3.1 Approach A — {{APPROACH_A}}
+- Pro: {{A_PRO}}
+- Con: {{A_CON}}
+- Evidence: {{A_EVIDENCE}}
+
+### 3.2 Approach B — {{APPROACH_B}}
+- Pro: {{B_PRO}}
+- Con: {{B_CON}}
+- Evidence: {{B_EVIDENCE}}
+
+### 3.3 Conflicts and resolutions
+
+| Conflict | Position A | Position B | Resolution | Rationale |
+|----------|-----------|-----------|------------|-----------|
+| {{C_1}} | {{A_1}} | {{B_1}} | {{R_1}} | {{WHY_1}} |
+
+## 4. Security considerations
+
+| Risk | Severity | Mitigation | Blocker? |
+|------|----------|------------|----------|
+| {{RISK_1}} | {{SEV_1}} | {{MIT_1}} | {{YN}} |
+
+## 5. Recommendation
+
+**Primary**: {{PRIMARY_APPROACH}}
+**Acceptable fallback**: {{FALLBACK}}
+**Reject**: {{REJECTED}} — reason: {{REJECT_REASON}}
+
+### 5.1 Implementation starting point
+
+{{CONCRETE_FIRST_STEP — file to touch, function to add, snippet}}
+
+## 6. Open questions
+
+- [ ] {{OPEN_Q_1}} — resolve before {{PHASE}}
+- [ ] {{OPEN_Q_2}} — can proceed without
+
+## 7. References
+
+| # | Source | Agent | Confidence |
+|---|--------|-------|------------|
+| 1 | {{SRC_1}} | {{AGENT_1}} | {{CONF_1}} |
+| 2 | {{SRC_2}} | {{AGENT_2}} | {{CONF_2}} |
+
+---
+
+**Reuse**: cite this file by path (`.claude/vibe/research/{{SLUG}}/paper.md`) when writing a SPEC — paste the Findings and Recommendation sections into the SPEC's Context block.

package/skills/parallel-research/templates/synthesis.md

@@ -1,101 +1,101 @@
-# Research Synthesis: {{RESEARCH_TOPIC}}
-
-**Date**: {{DATE}}
-**Technology**: {{TECHNOLOGY_STACK}}
-**Question**: {{RESEARCH_QUESTION}}
-
----
-
-## Executive Summary
-
-{{ONE_PARAGRAPH_SUMMARY}}
-
-**Recommended approach**: {{RECOMMENDATION}}
-
----
-
-## Findings by Agent
-
-### 1. Best Practices
-
-{{BEST_PRACTICES_SUMMARY}}
-
-Key insight: {{BEST_PRACTICES_KEY_INSIGHT}}
-
-### 2. Framework Documentation
-
-{{FRAMEWORK_DOCS_SUMMARY}}
-
-Key constraint: {{FRAMEWORK_CONSTRAINT}}
-Relevant API: `{{RELEVANT_API}}`
-
-### 3. Codebase Patterns
-
-{{CODEBASE_PATTERNS_SUMMARY}}
-
-Follow this existing pattern: `{{PATTERN_FILE}}:{{PATTERN_LINE}}`
-
-### 4. Security Advisory
-
-Risk level: **{{RISK_LEVEL}}**
-
-{{SECURITY_SUMMARY}}
-
-Required mitigations: {{REQUIRED_MITIGATIONS_COUNT}}
-
----
-
-## Conflicts and Resolutions
-
-| Conflict | Agent A says | Agent B says | Resolution |
-|----------|-------------|-------------|------------|
-| {{CONFLICT_1}} | {{A_POSITION}} | {{B_POSITION}} | {{RESOLUTION}} |
-
----
-
-## Actionable Recommendations
-
-### Must Do (before implementation)
-1. {{MUST_DO_1}}
-2. {{MUST_DO_2}}
-
-### Should Do (best practice)
-1. {{SHOULD_DO_1}}
-2. {{SHOULD_DO_2}}
-
-### Avoid
-1. {{AVOID_1}} — reason: {{AVOID_REASON_1}}
-2. {{AVOID_2}} — reason: {{AVOID_REASON_2}}
-
----
-
-## Impact on SPEC / Implementation Plan
-
-Add to SPEC Context section:
-
-```markdown
-## Context (from parallel research)
-
-- Best practice: {{SPEC_BEST_PRACTICE_NOTE}}
-- Framework constraint: {{SPEC_CONSTRAINT_NOTE}}
-- Security requirement: {{SPEC_SECURITY_NOTE}}
-- Existing pattern to follow: {{SPEC_PATTERN_NOTE}}
-```
-
----
-
-## Unanswered Questions
-
-- [ ] {{OPEN_QUESTION_1}} — investigate before Phase {{PHASE}}
-- [ ] {{OPEN_QUESTION_2}} — can proceed without answer
-
----
-
-## Sources
-
-| Agent | Source | Confidence |
-|-------|--------|-----------|
-| Best Practices | {{SOURCE_1}} | {{CONFIDENCE_1}} |
-| Framework Docs | {{SOURCE_2}} | {{CONFIDENCE_2}} |
-| Codebase | `{{SOURCE_3}}` | High |
-| Security | {{SOURCE_4}} | {{CONFIDENCE_4}} |
+# Research Synthesis: {{RESEARCH_TOPIC}}
+
+**Date**: {{DATE}}
+**Technology**: {{TECHNOLOGY_STACK}}
+**Question**: {{RESEARCH_QUESTION}}
+
+---
+
+## Executive Summary
+
+{{ONE_PARAGRAPH_SUMMARY}}
+
+**Recommended approach**: {{RECOMMENDATION}}
+
+---
+
+## Findings by Agent
+
+### 1. Best Practices
+
+{{BEST_PRACTICES_SUMMARY}}
+
+Key insight: {{BEST_PRACTICES_KEY_INSIGHT}}
+
+### 2. Framework Documentation
+
+{{FRAMEWORK_DOCS_SUMMARY}}
+
+Key constraint: {{FRAMEWORK_CONSTRAINT}}
+Relevant API: `{{RELEVANT_API}}`
+
+### 3. Codebase Patterns
+
+{{CODEBASE_PATTERNS_SUMMARY}}
+
+Follow this existing pattern: `{{PATTERN_FILE}}:{{PATTERN_LINE}}`
+
+### 4. Security Advisory
+
+Risk level: **{{RISK_LEVEL}}**
+
+{{SECURITY_SUMMARY}}
+
+Required mitigations: {{REQUIRED_MITIGATIONS_COUNT}}
+
+---
+
+## Conflicts and Resolutions
+
+| Conflict | Agent A says | Agent B says | Resolution |
+|----------|-------------|-------------|------------|
+| {{CONFLICT_1}} | {{A_POSITION}} | {{B_POSITION}} | {{RESOLUTION}} |
+
+---
+
+## Actionable Recommendations
+
+### Must Do (before implementation)
+1. {{MUST_DO_1}}
+2. {{MUST_DO_2}}
+
+### Should Do (best practice)
+1. {{SHOULD_DO_1}}
+2. {{SHOULD_DO_2}}
+
+### Avoid
+1. {{AVOID_1}} — reason: {{AVOID_REASON_1}}
+2. {{AVOID_2}} — reason: {{AVOID_REASON_2}}
+
+---
+
+## Impact on SPEC / Implementation Plan
+
+Add to SPEC Context section:
+
+```markdown
+## Context (from parallel research)
+
+- Best practice: {{SPEC_BEST_PRACTICE_NOTE}}
+- Framework constraint: {{SPEC_CONSTRAINT_NOTE}}
+- Security requirement: {{SPEC_SECURITY_NOTE}}
+- Existing pattern to follow: {{SPEC_PATTERN_NOTE}}
+```
+
+---
+
+## Unanswered Questions
+
+- [ ] {{OPEN_QUESTION_1}} — investigate before Phase {{PHASE}}
+- [ ] {{OPEN_QUESTION_2}} — can proceed without answer
+
+---
+
+## Sources
+
+| Agent | Source | Confidence |
+|-------|--------|-----------|
+| Best Practices | {{SOURCE_1}} | {{CONFIDENCE_1}} |
+| Framework Docs | {{SOURCE_2}} | {{CONFIDENCE_2}} |
+| Codebase | `{{SOURCE_3}}` | High |
+| Security | {{SOURCE_4}} | {{CONFIDENCE_4}} |

package/skills/prioritization-frameworks/SKILL.md

@@ -1,87 +1,87 @@
----
-name: prioritization-frameworks
-tier: standard
-description: "Reference guide to 9 prioritization frameworks with formulas, when-to-use guidance, and templates — RICE, ICE, Kano, MoSCoW, Opportunity Score, and more."
-triggers: [prioritize, prioritization, rice, ice, kano, moscow, opportunity score]
-priority: 50
-chain-next: [create-prd]
----
-
-# Prioritization Frameworks Reference
-
-> Based on the Product Frameworks Compendium from [Product Compass](https://www.productcompass.pm/p/the-product-frameworks-compendium) by Pawel Huryn (MIT License).
-
-A reference guide to help you select and apply the right prioritization framework for your context.
-
-## Core Principle
-
-Never allow customers to design solutions. Prioritize **problems (opportunities)**, not features.
-
-## Opportunity Score (Dan Olsen, *The Lean Product Playbook*)
-
-The recommended framework for prioritizing customer problems.
-
-Survey customers on **Importance** and **Satisfaction** for each need (normalize to 0-1 scale).
-
-Three related formulas:
-- **Current value** = Importance x Satisfaction
-- **Opportunity Score** = Importance x (1 - Satisfaction)
-- **Customer value created** = Importance x (S2 - S1), where S1 = satisfaction before, S2 = satisfaction after
-
-High Importance + low Satisfaction = highest Opportunity Score = best opportunities. Plot on an Importance vs Satisfaction chart — upper-left quadrant is the sweet spot.
-
-## ICE Framework
-
-Useful for prioritizing initiatives and ideas. Considers not only value but also risk and economic factors.
-
-- **I** (Impact) = Opportunity Score x Number of Customers affected
-- **C** (Confidence) = How confident are we? (1-10). Accounts for risk.
-- **E** (Ease) = How easy is it to implement? (1-10). Accounts for economic factors.
-
-**Score** = I x C x E. Higher = prioritize first.
-
-## RICE Framework
-
-Splits ICE's Impact into two separate factors. Useful for larger teams that need more granularity.
-
-- **R** (Reach) = Number of customers affected
-- **I** (Impact) = Opportunity Score (value per customer)
-- **C** (Confidence) = How confident are we? (0-100%)
-- **E** (Effort) = How much effort to implement? (person-months)
-
-**Score** = (R x I x C) / E
-
-## 9 Frameworks Overview
-
-| Framework | Best For | Key Insight |
-|-----------|----------|-------------|
-| Eisenhower Matrix | Personal tasks | Urgent vs Important — for individual PM task management |
-| Impact vs Effort | Tasks/initiatives | Simple 2x2 — quick triage, not rigorous for strategic decisions |
-| Risk vs Reward | Initiatives | Like Impact vs Effort but accounts for uncertainty |
-| **Opportunity Score** | Customer problems | **Recommended.** Importance x (1 - Satisfaction). Normalize to 0-1. |
-| Kano Model | Understanding expectations | Must-be, Performance, Attractive, Indifferent, Reverse. For understanding, not prioritizing. |
-| Weighted Decision Matrix | Multi-factor decisions | Assign weights to criteria, score each option. Useful for stakeholder buy-in. |
-| **ICE** | Ideas/initiatives | Impact x Confidence x Ease. Recommended for quick prioritization. |
-| **RICE** | Ideas at scale | (Reach x Impact x Confidence) / Effort. Adds Reach to ICE. |
-| MoSCoW | Requirements | Must/Should/Could/Won't. Caution: project management origin. |
-
-## How to Choose
-
-1. **Prioritizing customer problems?** → Opportunity Score
-2. **Quick initiative ranking?** → ICE
-3. **Large team with data?** → RICE
-4. **Understanding user expectations?** → Kano Model
-5. **Stakeholder alignment needed?** → Weighted Decision Matrix
-6. **Requirements scoping?** → MoSCoW (with caution)
-
-## Templates
-
-- [Opportunity Score intro (PDF)](https://drive.google.com/file/d/1ENbYPmk1i1AKO7UnfyTuULL5GucTVufW/view)
-- [Importance vs Satisfaction Template (Google Slides)](https://docs.google.com/presentation/d/1jg-LuF_3QHsf6f1nE1f98i4C0aulnRNMOO1jftgti8M/edit#slide=id.g796641d975_0_3)
-- [ICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1LUfnsPolhZgm7X2oij-7EUe0CJT-Dwr-/edit?usp=share_link)
-- [RICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1S-6QpyOz5MCrV7B67LUWdZkAzn38Eahv/edit?usp=sharing)
-
-## Further Reading
-
-- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
-- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)
+---
+name: prioritization-frameworks
+tier: standard
+description: "Reference guide to 9 prioritization frameworks with formulas, when-to-use guidance, and templates — RICE, ICE, Kano, MoSCoW, Opportunity Score, and more."
+triggers: [prioritize, prioritization, rice, ice, kano, moscow, opportunity score]
+priority: 50
+chain-next: [create-prd]
+---
+
+# Prioritization Frameworks Reference
+
+> Based on the Product Frameworks Compendium from [Product Compass](https://www.productcompass.pm/p/the-product-frameworks-compendium) by Pawel Huryn (MIT License).
+
+A reference guide to help you select and apply the right prioritization framework for your context.
+
+## Core Principle
+
+Never allow customers to design solutions. Prioritize **problems (opportunities)**, not features.
+
+## Opportunity Score (Dan Olsen, *The Lean Product Playbook*)
+
+The recommended framework for prioritizing customer problems.
+
+Survey customers on **Importance** and **Satisfaction** for each need (normalize to 0-1 scale).
+
+Three related formulas:
+- **Current value** = Importance x Satisfaction
+- **Opportunity Score** = Importance x (1 - Satisfaction)
+- **Customer value created** = Importance x (S2 - S1), where S1 = satisfaction before, S2 = satisfaction after
+
+High Importance + low Satisfaction = highest Opportunity Score = best opportunities. Plot on an Importance vs Satisfaction chart — upper-left quadrant is the sweet spot.
+
+## ICE Framework
+
+Useful for prioritizing initiatives and ideas. Considers not only value but also risk and economic factors.
+
+- **I** (Impact) = Opportunity Score x Number of Customers affected
+- **C** (Confidence) = How confident are we? (1-10). Accounts for risk.
+- **E** (Ease) = How easy is it to implement? (1-10). Accounts for economic factors.
+
+**Score** = I x C x E. Higher = prioritize first.
+
+## RICE Framework
+
+Splits ICE's Impact into two separate factors. Useful for larger teams that need more granularity.
+
+- **R** (Reach) = Number of customers affected
+- **I** (Impact) = Opportunity Score (value per customer)
+- **C** (Confidence) = How confident are we? (0-100%)
+- **E** (Effort) = How much effort to implement? (person-months)
+
+**Score** = (R x I x C) / E
+
+## 9 Frameworks Overview
+
+| Framework | Best For | Key Insight |
+|-----------|----------|-------------|
+| Eisenhower Matrix | Personal tasks | Urgent vs Important — for individual PM task management |
+| Impact vs Effort | Tasks/initiatives | Simple 2x2 — quick triage, not rigorous for strategic decisions |
+| Risk vs Reward | Initiatives | Like Impact vs Effort but accounts for uncertainty |
+| **Opportunity Score** | Customer problems | **Recommended.** Importance x (1 - Satisfaction). Normalize to 0-1. |
+| Kano Model | Understanding expectations | Must-be, Performance, Attractive, Indifferent, Reverse. For understanding, not prioritizing. |
+| Weighted Decision Matrix | Multi-factor decisions | Assign weights to criteria, score each option. Useful for stakeholder buy-in. |
+| **ICE** | Ideas/initiatives | Impact x Confidence x Ease. Recommended for quick prioritization. |
+| **RICE** | Ideas at scale | (Reach x Impact x Confidence) / Effort. Adds Reach to ICE. |
+| MoSCoW | Requirements | Must/Should/Could/Won't. Caution: project management origin. |
+
+## How to Choose
+
+1. **Prioritizing customer problems?** → Opportunity Score
+2. **Quick initiative ranking?** → ICE
+3. **Large team with data?** → RICE
+4. **Understanding user expectations?** → Kano Model
+5. **Stakeholder alignment needed?** → Weighted Decision Matrix
+6. **Requirements scoping?** → MoSCoW (with caution)
+
+## Templates
+
+- [Opportunity Score intro (PDF)](https://drive.google.com/file/d/1ENbYPmk1i1AKO7UnfyTuULL5GucTVufW/view)
+- [Importance vs Satisfaction Template (Google Slides)](https://docs.google.com/presentation/d/1jg-LuF_3QHsf6f1nE1f98i4C0aulnRNMOO1jftgti8M/edit#slide=id.g796641d975_0_3)
+- [ICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1LUfnsPolhZgm7X2oij-7EUe0CJT-Dwr-/edit?usp=share_link)
+- [RICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1S-6QpyOz5MCrV7B67LUWdZkAzn38Eahv/edit?usp=sharing)
+
+## Further Reading
+
+- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
+- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)

package/skills/prioritization-frameworks/rubrics/frameworks.md

@@ -1,79 +1,79 @@
-# Prioritization Frameworks Rubric
-
-## RICE
-
-**Formula**: `(Reach × Impact × Confidence) / Effort`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Reach | Users/month (absolute) | 5,000 users |
-| Impact | Opportunity Score 0.0–1.0 | 0.7 |
-| Confidence | 0–100% | 80% = 0.8 |
-| Effort | Person-months | 2 |
-
-**Example**: `(5000 × 0.7 × 0.8) / 2 = 1400` — higher score = prioritize first.
-
-**When to use**: Large teams with data. Separates audience size (Reach) from value per user (Impact).
-
-**Watch out for**: Effort estimates are often optimistic — apply a 1.5x buffer.
-
----
-
-## ICE
-
-**Formula**: `Impact × Confidence × Ease`
-
-| Factor | Scale | Example |
-|--------|-------|---------|
-| Impact | 1–10 (or Opportunity Score × Users) | 8 |
-| Confidence | 1–10 | 7 |
-| Ease | 1–10 (inverse of effort) | 5 |
-
-**Example**: `8 × 7 × 5 = 280` — higher score = prioritize first.
-
-**When to use**: Quick ranking of ideas/initiatives. Faster than RICE, good for early-stage decisions.
-
-**Watch out for**: "Ease" is subjective — calibrate across team before scoring.
-
----
-
-## MoSCoW
-
-**Categories**:
-
-| Category | Meaning | Guideline |
-|----------|---------|-----------|
-| **Must** | Cannot launch without | Max 60% of scope |
-| **Should** | High value, not critical | Next priority after Must |
-| **Could** | Nice to have | Include only if capacity allows |
-| **Won't** | Explicitly deferred | Documents what is NOT in scope |
-
-**When to use**: Scoping a release. Good for stakeholder alignment conversations.
-
-**Watch out for**: Stakeholders inflate "Must" — challenge each Must with "What happens if we skip this for V1?". MoSCoW is a scoping tool, not a discovery tool.
-
----
-
-## Opportunity Score
-
-**Formula**: `Importance × (1 − Satisfaction)` (normalize both to 0–1 scale)
-
-**Example**:
-- Importance: 0.9, Satisfaction: 0.3 → Score: `0.9 × 0.7 = 0.63` (high opportunity)
-- Importance: 0.9, Satisfaction: 0.9 → Score: `0.9 × 0.1 = 0.09` (already solved)
-
-**When to use**: Prioritizing customer problems before deciding on solutions. Prevents building features customers already find satisfactory.
-
-**Watch out for**: Survey sample must be representative. Low sample size inflates confidence.
-
----
-
-## Choosing the Right Framework
-
-| Situation | Recommended Framework |
-|-----------|----------------------|
-| "Which customer problems matter most?" | Opportunity Score |
-| "Which features should we build this sprint?" | ICE |
-| "How do we rank initiatives across a large team?" | RICE |
-| "What goes into V1 vs. later?" | MoSCoW |
-| "Stakeholders disagree on priorities?" | Weighted Decision Matrix |
+# Prioritization Frameworks Rubric
+
+## RICE
+
+**Formula**: `(Reach × Impact × Confidence) / Effort`
+
+| Factor | Scale | Example |
+|--------|-------|---------|
+| Reach | Users/month (absolute) | 5,000 users |
+| Impact | Opportunity Score 0.0–1.0 | 0.7 |
+| Confidence | 0–100% | 80% = 0.8 |
+| Effort | Person-months | 2 |
+
+**Example**: `(5000 × 0.7 × 0.8) / 2 = 1400` — higher score = prioritize first.
+
+**When to use**: Large teams with data. Separates audience size (Reach) from value per user (Impact).
+
+**Watch out for**: Effort estimates are often optimistic — apply a 1.5x buffer.
+
+---
+
+## ICE
+
+**Formula**: `Impact × Confidence × Ease`
+
+| Factor | Scale | Example |
+|--------|-------|---------|
+| Impact | 1–10 (or Opportunity Score × Users) | 8 |
+| Confidence | 1–10 | 7 |
+| Ease | 1–10 (inverse of effort) | 5 |
+
+**Example**: `8 × 7 × 5 = 280` — higher score = prioritize first.
+
+**When to use**: Quick ranking of ideas/initiatives. Faster than RICE, good for early-stage decisions.
+
+**Watch out for**: "Ease" is subjective — calibrate across team before scoring.
+
+---
+
+## MoSCoW
+
+**Categories**:
+
+| Category | Meaning | Guideline |
+|----------|---------|-----------|
+| **Must** | Cannot launch without | Max 60% of scope |
+| **Should** | High value, not critical | Next priority after Must |
+| **Could** | Nice to have | Include only if capacity allows |
+| **Won't** | Explicitly deferred | Documents what is NOT in scope |
+
+**When to use**: Scoping a release. Good for stakeholder alignment conversations.
+
+**Watch out for**: Stakeholders inflate "Must" — challenge each Must with "What happens if we skip this for V1?". MoSCoW is a scoping tool, not a discovery tool.
+
+---
+
+## Opportunity Score
+
+**Formula**: `Importance × (1 − Satisfaction)` (normalize both to 0–1 scale)
+
+**Example**:
+- Importance: 0.9, Satisfaction: 0.3 → Score: `0.9 × 0.7 = 0.63` (high opportunity)
+- Importance: 0.9, Satisfaction: 0.9 → Score: `0.9 × 0.1 = 0.09` (already solved)
+
+**When to use**: Prioritizing customer problems before deciding on solutions. Prevents building features customers already find satisfactory.
+
+**Watch out for**: Survey sample must be representative. Low sample size inflates confidence.
+
+---
+
+## Choosing the Right Framework
+
+| Situation | Recommended Framework |
+|-----------|----------------------|
+| "Which customer problems matter most?" | Opportunity Score |
+| "Which features should we build this sprint?" | ICE |
+| "How do we rank initiatives across a large team?" | RICE |
+| "What goes into V1 vs. later?" | MoSCoW |
+| "Stakeholders disagree on priorities?" | Weighted Decision Matrix |