Skip to main content
ClaudeWave
ES, Spanish
Skill755 estrellas del repoactualizado 7d ago

define-prioritization-framework

The define-prioritization-framework Claude Code skill evaluates candidate features or initiatives against multiple prioritization methods (RICE, ICE, MoSCoW, Weighted Scoring, Kano) filtered by data availability. It produces a comparison table showing where framework rankings align or diverge, an executive summary with recommendation, and flags estimation gaps rather than fabricating scores. Use this when deciding among competing work items and need to surface hidden assumptions or validate confidence in a single-framework conclusion.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/define-prioritization-framework && cp -r /tmp/define-prioritization-framework/skills/define-prioritization-framework ~/.claude/skills/define-prioritization-framework
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
# Prioritization Framework

You run all applicable prioritization frameworks against a candidate list of work items. Your job is to (a) filter frameworks by data availability and context, (b) score each item explicitly per applicable framework, (c) produce a comparison table showing where rankings agree and diverge, (d) synthesize an executive summary with recommendation, and (e) flag what could go wrong with the prioritization.

## Identity

- Phase skill (define); Triple Diamond integration
- Single-turn lifetime; produces one ranked artifact per invocation
- Read-only tools (Read, Grep); no write outside the output artifact
- Outputs a markdown document with per-framework scoring tables + comparison + recommendation

## Core principle

**Multi-framework analysis surfaces what single-framework selection hides.** Where RICE and ICE agree, confidence rises. Where they disagree, the divergence reveals hidden assumptions worth examining - often the most valuable finding.

Filter frameworks by applicability: RICE requires quantitative reach/impact/effort inputs; ICE works with coarse estimates; MoSCoW is for binary commitment decisions; Weighted Scoring requires multi-criteria weights; Kano requires customer-research input (gated). Run all frameworks that pass the applicability filter. Do NOT reduce to one framework when multiple are applicable.

## When NOT to Use

- You have not yet structured outcomes and opportunities into a candidate list -> use `define-opportunity-tree`; this skill ranks a list, it does not discover what belongs on it
- You want to test one specific assumption rather than rank several items -> use `define-hypothesis`, then `measure-experiment-design`
- You need to size a market opportunity (TAM/SAM/SOM), not rank a feature list -> use `discover-market-sizing`
- Your items are already ranked and you need launch readiness next -> use `deliver-launch-checklist`
- You need qualitative synthesis of user research to generate candidates, not rank an existing list -> use `discover-interview-synthesis`
- You have a raw, unstructured situation (notes, transcript, exec ask) rather than a defined candidate list of items to score -> use `foundation-prioritized-action-plan` for a general ranked next-action plan; this skill requires a candidate list and scores it against formal frameworks

## Inputs

Required:

- List of candidate items (features, initiatives, work items). Each item needs at least a name and a one-sentence description.
- Decision context: "Q3 roadmap candidates" or "MVP scope reduction" or "Hypothesis triage for the next sprint" etc.

Optional but improves quality:

- Available data per item (impact estimate, effort estimate, customer signal, business case)
- Stakeholder criteria (engineering capacity, business priority, customer urgency)
- Confidence levels on input data
- Time horizon (sprint, quarter, half, year)
- Customer-research data (unlocks Kano)

## Framework applicability filter

Before running, evaluate each framework against the available inputs. Run all frameworks that pass:

| Framework | Runs when | Excluded when |
|---|---|---|
| **RICE** (Reach * Impact * Confidence / Effort) | Quantitative reach, impact, effort estimates are available or user accepts an estimation scaffold | Inputs unavailable and user declines estimation scaffold |
| **ICE** (Impact * Confidence * Ease) | Always applicable; coarse estimates are acceptable | Not excluded; ICE is the lowest-input framework |
| **MoSCoW** (Must / Should / Could / Won't) | Decision involves binary commitment per item or scope bounding | Not applicable for pure ranking decisions without scope constraint |
| **Weighted Scoring** (multi-criteria with weights) | Multiple stakeholders or criteria apply; user provides or accepts proposed default weights | Single criterion dominates; or criteria are purely personal preference |
| **Kano** (Must-Have / Performance / Delighter) | Customer-research input is provided, at either evidence tier below | **Gated:** excluded only if no customer research at all is provided; explain why and suggest what research would unlock it. Run at the tier the evidence supports and label the tier in the output |

At least one framework will always run (ICE is always applicable). Show which frameworks ran and which were excluded, with brief rationale.

## What you produce

### 1. Applicability filter summary (3-5 sentences)

Which frameworks ran, which were excluded, and why. Note any frameworks excluded due to missing inputs and what would unlock them.

### 2. Inputs summary

What you were given. If any input is missing or assumed, note: "Reach was not provided; assumption: large reach unless flagged."

### 3. Per-framework scoring tables

Run each applicable framework and produce its scoring table.

**For RICE:**

| Item | Reach (users/qtr) | Impact (0.25-3) | Confidence (%) | Effort (capacity-weeks) | RICE Score | Notes |
|---|---|---|---|---|---|---|
| Item A | 1000 | 2 | 80% | 3 | 533 | High confidence on reach |

**For ICE:**

| Item | Impact (1-10) | Confidence (1-10) | Ease (1-10) | ICE Score | Notes |
|---|---|---|---|---|---|

**For MoSCoW:**

| Item | Bucket | Rationale | Risk if dropped |
|---|---|---|---|
| Item A | Must | Critical for launch | Cannot ship without |

**For Weighted Scoring:**

| Item | Criterion 1 (weight) | Criterion 2 (weight) | ... | Total Weighted Score |
|---|---|---|---|---|

**For Kano:**

| Item | Category (Must / Performance / Delighter / Reverse / Indifferent / **Ambiguous**) | Response distribution (surveyed runs; `not available (inferred)` otherwise) | Evidence tier and claim strength | Customer evidence | Implication |
|---|---|---|---|---|---|

### 4. Per-framework ranking output

For each scored framework: items sorted by score or grouped by bucket. For scored frameworks, highlight the top 5 and bottom 5 with the gap between them. **When the backlog has 10
chainSlash Command

Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)

define-hypothesisSkill

Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.

define-jtbd-canvasSkill

Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.

define-opportunity-treeSkill

Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.

define-problem-statementSkill

Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.

deliver-acceptance-criteriaSkill

Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.

deliver-edge-casesSkill

Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.

deliver-launch-checklistSkill

Creates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team change. For the customer-facing announcement of what shipped, use deliver-release-notes instead.