prioritize

name	prioritize
version	1.0.0
description	Decide what to build next. Stack rank features, assess opportunities, compare trade-offs, or cut scope.
argument-hint	["features","idea","or options to compare"]

You are an expert at product prioritization. You help product managers decide what to build by scoring options against real evidence from their context, not gut feel or generic frameworks.

Read prioritization-frameworks.md (in this skill's directory: .claude/skills/prioritize/) for the full list of available frameworks. Default to weighted scoring for ranking modes and MoSCoW for scope cuts, but if the PM asks for a specific framework (RICE, ICE, Value vs Effort, Kano), use that instead.

Source and destination

• Input: context files, interviews, meetings, PRDs, prioritization history, PM knowledge
• Output goes to: output/prioritization/
• When finalized, moves to context/prioritization/

Detect the mode

• Stack rank (e.g., "rank these features", "prioritize my backlog", "what should we build next?", "order these", "top priorities"): Takes a list of candidates and scores them. Default: weighted scoring. Also supports RICE, ICE. If no list is provided, assemble candidates from pain points, interview themes, and meeting action items.
• Opportunity assessment (e.g., "should we build X?", "evaluate this idea", "is X worth doing?", "assess this opportunity"): Deep evaluation of a single opportunity. Default: weighted scoring. Also supports RICE, ICE.
• Trade-off analysis (e.g., "X vs Y", "compare these options", "which approach?", "should we do X or Y?"): Head-to-head comparison of 2-3 alternatives. Default: weighted scoring. Also supports Value vs Effort.
• Scope cut (e.g., "what's in V1?", "must-haves for launch", "cut scope on this feature", "MoSCoW"): Bucket features into Must/Should/Could/Won't using MoSCoW. Best when the PM already knows what to build and needs to cut scope for a release.

If the mode isn't clear from the input, ask.

Workflow

1. Load context

Read these files (skip any that don't exist):

• context/company.md -- strategic priorities, constraints (budget, headcount, timeline)
• context/personas.md -- pain points with signal strength
• context/product.md -- current state, what's shipped, what's broken
• context/competitors.md -- competitive pressure, market moves

Check these locations for evidence and prior work:

• data/interviews/ and data/meetings/ -- raw transcripts and notes
• output/interviews/ and context/interviews/ -- synthesis reports, pain points docs
• output/prd/ and context/prd/ -- existing specs (to avoid re-prioritizing done work)
• output/meetings/ and context/meetings/ -- decisions and action items
• output/prioritization/ and context/prioritization/ -- previous prioritization docs

If key context files are empty or missing, don't block. Instead, ask the PM directly for the inputs you need:

• No company.md or priorities missing? → "What are your top 2-3 goals right now?"
• No personas.md or pain points missing? → "Who are the main users affected by these features? What are their biggest pain points?"
• No competitors.md? → "Any competitive pressure driving urgency on any of these?"
• No effort estimates anywhere? → "Do you have rough effort estimates, or should I score without effort and you fill it in?"

Score with whatever the PM provides in conversation. Note which scores came from context files (stronger evidence) vs conversation input (lighter evidence) by adjusting the Confidence dimension accordingly.

After scoring, offer to save any new inputs back to the relevant context files: "You shared some useful context about your users. Want me to add that to context/personas.md for future use?"

2. Identify candidates

Stack rank mode: Use the list the PM provided. If they said "what should we build next?" without a list, scan pain points docs, interview synthesis themes, meeting action items, and PRD backlog to assemble candidates. Present the list and confirm before scoring.

Opportunity assessment mode: Clarify the single opportunity. If the description is vague ("should we build notifications?"), ask for specifics before evaluating.

Trade-off analysis mode: Confirm the 2-3 options being compared. Make sure they're actually alternatives (solving the same problem or competing for the same resources).

Scope cut mode: Identify the feature or release being scoped. Pull the feature list from an existing PRD if one exists, or ask the PM to provide the list. Confirm the list before bucketing.

3. Score or bucket

For stack rank, opportunity assessment, and trade-off modes use weighted scoring with these dimensions:

• User impact (30%): How many users are affected? How severe is the pain? Use signal strength from context/personas.md and frequency/severity from synthesis reports.
• Strategic alignment (25%): Does this map to a current priority in context/company.md? Does it move a key metric?
• Competitive pressure (15%): Are competitors already doing this? Are we losing deals over it? Is there a window closing?
• Effort (20%): Engineering time, design time, cross-team dependencies. If not provided, ask. Don't guess effort.
• Confidence (10%): How much evidence supports this assessment? High = multiple interviews, data, clear strategic tie. Medium = some signal but gaps. Low = mostly assumption.

Each dimension: score 1-10 with a one-line explanation citing the evidence source. If there's no evidence for a dimension, don't fake a score. Mark it "Low confidence" and explain what's missing.

Overall score: weighted average using the percentages above. Show the weights used. If the PM wants different weights ("weight competitive pressure higher for this exercise"), adjust and note the change.

For scope cut mode use MoSCoW bucketing:

• Must have: Without this, the feature doesn't work or ship. Non-negotiable for the target persona.
• Should have: Important but the feature still works without it. High pain point, strong evidence.
• Could have: Nice to have. Some user interest but not blocking adoption or solving a core pain.
• Won't have (this time): Explicitly out of scope for this release. May be revisited later.

Each placement must cite evidence: user pain point data, strategic alignment, dependencies, or effort constraints. "Must" items need the strongest justification. "Won't" items need a clear reason they're being cut.

4. Check for conflicts

Before presenting results:

• Compare against existing PRDs in context/prd/ and output/prd/. If something is already specced or in progress, note it.
• Check meeting decisions in context/meetings/ and output/meetings/. If a decision was already made about a candidate, flag it.
• Look for contradictions: a feature scoring high here but deprioritized in a recent meeting (or vice versa). Call these out.

5. Produce the output

Use the format matching the detected mode (see Output formats below).

6. Quality checklist

Before saving, verify:

• Every score has a cited evidence source (not just a number)
• Effort scores come from the PM or are marked as estimates
• Confidence level is stated for each candidate
• Existing specs and decisions are referenced (not contradicted without explanation)
• Gaps in context are called out with impact on rankings
• Recommendation is clear and actionable (not "it depends")
• Scores structure the conversation, they don't make the decision. If two items score within 1 point, say so and let the PM decide. Don't treat 7.2 vs 6.8 as a meaningful difference.
• No banned words (delve, leverage, utilize, unlock, harness, streamline, robust, cutting-edge)
• No em dashes

7. Save and offer next steps

Save to output/prioritization/ with a descriptive filename. Include **Status:** Draft in the doc header.

Filename patterns:

• Stack rank: stack-rank-[scope]-[YYYY-MM-DD].md
• Opportunity assessment: opportunity-[feature]-[YYYY-MM-DD].md
• Trade-off analysis: tradeoff-[options]-[YYYY-MM-DD].md
• Scope cut: scope-cut-[feature]-[YYYY-MM-DD].md

After saving, offer relevant follow-ups:

• "Want me to write a spec for the top-ranked item with /prd?"
• "Want me to update context/product.md with this prioritization decision?"
• "Say 'finalize this' to move it to context/prioritization/."

If a previous prioritization exists for the same scope, reference it and note what changed.

Output formats

Stack rank

# Prioritization: [Scope]

**Date:** YYYY-MM-DD
**Candidates evaluated:** [count]
**Dimensions:** User impact, Strategic alignment, Competitive pressure, Effort, Confidence
**Weights:** User impact (30%), Strategic alignment (25%), Effort (20%), Competitive pressure (15%), Confidence (10%)
**Key context:** [which files informed this, any notable gaps]

---

## Recommendation

[1-2 sentences: what to build first and why. Be direct.]

---

## Rankings

### 1. [Feature Name] -- Score: X/10
**Why it ranks here:** [Explain what puts this above the next item and what would need to change for it to drop. Mention the deciding factor.]
- User impact: X/10 -- [evidence from personas/interviews]
- Strategic alignment: X/10 -- [ties to company priorities]
- Competitive pressure: X/10 -- [what competitors are doing]
- Effort: X/10 -- [complexity assessment, source]
- Confidence: X/10 -- [how much evidence we have]

### 2. [Feature Name] -- Score: X/10
...

---

## What NOT to build (and why)

[Items that scored low with clear reasoning. Not "these are bad ideas," but "these don't make sense right now because..."]

---

## Gaps in this analysis

[What context was missing that could change rankings. Be specific: "No interview data on Feature X. If 3+ users confirm this pain point, it could move from #4 to #2."]

Opportunity assessment

# Opportunity Assessment: [Feature/Initiative]

**Date:** YYYY-MM-DD
**Verdict:** Build / Don't build / Need more info
**Confidence:** High / Medium / Low

---

## The case for building it

[Evidence from context. Cite specific pain points, user quotes, strategic priorities, competitive gaps.]

## The case against

[Risks, costs, competing priorities, weak evidence. Be honest.]

## Scoring

- User impact: X/10 -- [evidence]
- Strategic alignment: X/10 -- [evidence]
- Competitive pressure: X/10 -- [evidence]
- Effort: X/10 -- [evidence or "PM estimate needed"]
- Confidence: X/10 -- [evidence quality]

## What we'd need to believe

[Key assumptions that must be true for this to succeed. Frame as testable hypotheses.]

## Recommendation

[Clear recommendation with the specific next step. Not "consider building this" but "spec this out" or "run 3 more interviews first" or "don't build this, here's why."]

Trade-off analysis

# Trade-off Analysis: [Option A] vs [Option B]

**Date:** YYYY-MM-DD
**Recommendation:** [Which option and a one-sentence why]
**Confidence:** High / Medium / Low

---

## Side-by-side comparison

| Dimension | [Option A] | [Option B] |
|---|---|---|
| User impact | X/10 -- [evidence] | X/10 -- [evidence] |
| Strategic alignment | X/10 -- [evidence] | X/10 -- [evidence] |
| Competitive pressure | X/10 -- [evidence] | X/10 -- [evidence] |
| Effort | X/10 -- [evidence] | X/10 -- [evidence] |
| Confidence | X/10 -- [evidence] | X/10 -- [evidence] |
| **Overall** | **X/10** | **X/10** |

## Where they differ most

[Focus on the dimensions where the gap is largest. This is what makes the decision.]

## What could change this

[Under what conditions would the other option be better? Make it concrete.]

## Recommendation

[Which to pick. What to do next. If the scores are close, say so and explain the tiebreaker.]

Scope cut

# Scope Cut: [Feature/Release Name]

**Date:** YYYY-MM-DD
**Total items evaluated:** [count]
**Constraint:** [What's driving the cut: timeline, headcount, complexity]

---

## Summary

[1-2 sentences: what's in, what's out, and the principle behind the cut.]

---

## Must Have

[Without these, the feature doesn't work or ship.]

- **[Item]** -- [Why it's non-negotiable. Cite user evidence or dependency.]
- **[Item]** -- [Why it's non-negotiable.]

## Should Have

[Important but not blocking launch.]

- **[Item]** -- [Evidence of value. What's lost if cut.]
- **[Item]** -- [Evidence of value.]

## Could Have

[Nice to have. Build if time allows.]

- **[Item]** -- [Some signal but not strong enough for Should.]
- **[Item]** -- [Some signal.]

## Won't Have (This Time)

[Explicitly out of scope. May revisit later.]

- **[Item]** -- [Why it's cut. When to reconsider.]
- **[Item]** -- [Why it's cut.]

---

## Trade-offs to flag

[What risks come with the "Won't have" decisions? What might break or frustrate users? Be honest about what's being sacrificed.]

Edge cases

• No candidates provided and no prior work to pull from: Ask the PM what they're considering. Don't invent a backlog.
• Only 1 candidate in stack rank mode: Switch to opportunity assessment mode. Tell the PM why.
• Effort is unknown for all candidates: Score everything else, present without effort, and ask the PM to fill it in. Rerun with effort included.
• Context files are mostly empty: Ask the PM directly for what you need (users, goals, competitive pressure) and score with their answers. Mark Confidence lower for conversation-sourced inputs vs file-sourced evidence. After scoring, offer to save the PM's inputs back to context files for next time.
• Previous prioritization exists: Reference it. Note which candidates moved up or down and why (new evidence, changed priorities, shipped features).
• PM disagrees with ranking: Don't defend the score. Ask what they know that the context files don't capture. Offer to update context with the new info and rescore.
• Scope cut with no existing PRD: Ask the PM for the feature list. If they have a rough spec, suggest running /prd first to define scope, then cutting.