Pm Prioritize

pm-prioritize — Rank requirements with RICE / ICE / MoSCoW / Kano

Part of the Personal Corp framework — running a one-person business through AI agents.

Rank a list of requirements using a structured framework. A built-in decision tree picks the right framework based on data availability and decision context. Output is transparent and traceable, so a team can argue with the scores instead of the recommendation.

Inputs

Optional config

Most of the skill works out-of-box. If you want stable defaults across runs, add an ## Prioritize Config section to your project's CLAUDE.md:

## Prioritize Config

### Default framework (optional)
If unset, the skill auto-recommends per the decision table below.
- default_framework: RICE | ICE | MoSCoW | Kano

### Default resource constraint (optional)
Used in the Sprint allocation step. Skip if you'd rather state it per run.
- sprint_capacity: 20 person-days per Sprint

### Backlog source (optional)
Where the skill should fetch the requirement list from when you don't paste one.
- backlog_source: gh-issues  # gh-issues | github-project | tasks-file | paste
- gh_owner: your-github-handle
- gh_repo: your-main-repo
- gh_label: backlog
- tasks_file: docs/backlog.md

When a config field is set, the skill uses it silently. When unset, the skill asks (see "When input is incomplete").

Research commands (auto-discovery)

If the user points at a backlog source instead of pasting items, the skill can pull the list itself:

# GitHub issues by label
gh issue list -R $OWNER/$REPO --label $LABEL --state open \
  --json number,title,body --limit 100

# GitHub Project items
gh project item-list $PROJECT_ID --owner $OWNER --format json

# Local backlog file
cat $TASKS_FILE

Step 1 — Pick a framework

If unspecified, recommend per this decision table:

Framework comparison:

Step 2 — Score requirements

RICE (default)

RICE Score = (R × I × C) / E — higher = higher priority.

Calibration mechanism:

• Score the same dimension across all items first (all R, then all I) — avoids per-item anchoring bias
• R calibration: pick a baseline ("login: affects 100% of users"), score others relative
• I calibration: ≤ 50% of items can score 3 — forces differentiation
• E calibration: must include design (20%) + dev (50%) + QA (20%) + integration (10%)

ICE (fast)

Score 1-10 on each dimension. ICE Score = I × C × E / 10.

MoSCoW

Common trap: everything ends up Must Have. Counter: cap Must Have at 60%, force trade-offs.

Kano

Kano decay: today's Attractive feature becomes One-dimensional, then Must-be over 2-3 years (e.g. fingerprint unlock). Continuously create new delighters.

Step 3 — Output ranking

RICE results table:

Impact × Effort 2×2:

Sprint allocation:

• Allocate per sprint_capacity (config) or stated resource constraint
• Quick Wins fill first; Strategic by RICE Score
• Reserve 10-20% per Sprint for unexpected work

Step 4 — Decision log

• Core trade-offs: why A over B this cycle
• Disputed items: which ranks may be contested, and why
• Confidence flags: which scores have C < 80% — propose validation experiments
• Next-cycle candidates: Won't-Have items most likely to promote next cycle

Quality bar

1. Every score has a one-sentence rationale
2. Effort includes design + dev + QA + integration
3. C < 80% items get "validate via small experiment" tag
4. Must Have ≤ 60% of total
5. Calibration mechanism applied to avoid anchoring

Red lines

1. Not a decision-maker — output is a recommendation; the final call is the team's
2. No hidden assumptions — every score's assumption is explicit
3. Never ignore Effort — no "must do" recommendation based on Impact alone

When input is incomplete

• No backlog source provided → ask: "Where is the list — paste, file path, or a GitHub issues filter (owner/repo + label or milestone)?"
• No business goal → ask: "Current focus this cycle — growth / retention / revenue / efficiency? Optional, but it tightens the recommendation."
• No resource constraint → ask: "Available capacity for the next cycle — person-days or Story Points? Optional, but needed for Sprint allocation."
• Framework unset → don't ask. Auto-recommend per the Step 1 decision table and propose it with a one-sentence rationale; user confirms or overrides.
• < 3 requirements → still rank, but flag "sample too small, add more for stability"
• No data at all → switch to ICE or MoSCoW; tag "qualitative ranking due to missing quantitative data"

Related skills

• weekly-planning — uses the ranked backlog from this skill to pick weekly OKRs / outcomes. Prioritization feeds OKR selection, not replaces it.
• weekly-retro — feeds the next backlog with retro findings and carry-over items
• /pm-user-stories — top-priority requirements → break into Stories
• /pm-prd — Must-Have requirements → write PRDs