Prioritize
Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.
npx -y skills add ramanbamba/10x-pm --skill prioritizeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Score and rank a backlog of features, projects, or bets using RICE, ICE, or opportunity-cost framing, and write the tradeoff memo that defends the ranking. Use when the user says "prioritize", "stack rank", "what should we build first", "RICE score", or shares a list of competing initiatives.
SKILL.md
3.0 KB, as published. Nobody here has run it
Prioritization
Produce a ranking someone can disagree with productively — every score traceable to an assumption, every cut item told why.
Before scoring
Ask (one batch):
- What's the constraint? Eng-weeks available, one quarter, one team? Prioritization without a budget is a wishlist.
- What's the goal this period? Revenue, retention, strategic positioning? The same backlog ranks differently under different goals.
- What data exists? Reach and impact estimates need sources. If none, scores are structured guesses — proceed, but say so.
Pick the framework for the user unless they specify:
- RICE (Reach × Impact × Confidence / Effort) — default for feature backlogs with usage data
- ICE — when reach data doesn't exist yet (early product)
- Opportunity scoring (importance vs. satisfaction) — when ranking problem areas, not solutions
Workflow
- Build the scoring table. For every score, record the reason in a justification column — a bare number is unauditable.
- Use consistent scales: Impact 0.25 / 0.5 / 1 / 2 / 3 (massive), Confidence 50% / 80% / 100%. Never assign 100% confidence to an estimate the user guessed.
- Rank, then apply the constraint: draw the cut line at the stated capacity.
- Sanity-pass the ranking against strategy. Pure score-sorting is a starting point, not an answer. If a low-scoring item is strategically required (platform debt, contractual commitment), keep it and say why explicitly — never smuggle it in by inflating scores.
- Write the tradeoff memo.
Output format
# Prioritization — [scope], [period]
**Framework:** RICE · **Constraint:** [X eng-weeks] · **Goal:** [the goal]
## Ranking
| Rank | Item | R | I | C | E | Score | Key assumption |
|---|---|---|---|---|---|---|---|
━━━ CUT LINE ([capacity]) ━━━
| Rank | Item | Score | Why it didn't make it |
|---|---|---|---|
## Strategic overrides
[Items placed above their score, with the explicit reason. "None" is a valid answer.]
## What we're saying no to
[The 2–3 most painful cuts, each with: what we lose, who will be upset, the revisit trigger.]
## Sensitivity
[Which ranking positions flip if a key assumption is wrong. E.g., "If item 3's reach
is half the estimate, it drops below the line."]
Quality bar — self-check
- Every score has a justification. "Impact: 2" with no reason fails.
- Confidence is honest. Guessed inputs cap confidence at 50%.
- The cut line reflects the real constraint, not optimism.
- At least one painful cut is named. A prioritization where nothing hurts didn't prioritize.
- Sensitivity section exists. Rankings presented as certainty are lies with decimals.