prioritize

name	prioritize
version	2.0.0
description	[Project Management] Use when you need to prioritize backlog items using RICE, MoSCoW, or Value-Effort frameworks.

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Order 3+ backlog items using RICE, MoSCoW, or Value-Effort frameworks with scores and rationale.

Workflow:

1. Collect Items — Read from files or parse inline list (minimum 3 items)
2. Select Framework — RICE (quantitative), MoSCoW (stakeholder alignment), Value-Effort (quick decision)
3. Score Each Item — Apply framework criteria and calculate scores
4. Rank and Report — Output prioritized table with rationale and recommendations

Key Rules:

• Minimum 3 items required; fewer than 3 should be discussed directly
• Default to RICE if unsure; ask user if ambiguous
• Optionally update PBI file priority fields after ranking

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

Backlog Prioritization

Order backlog items using data-driven prioritization frameworks to produce a ranked list with scores and rationale.

When to Use

• Sprint planning needs an ordered backlog (3+ items to rank)
• Stakeholders need a priority ranking with justification
• Feature roadmap ordering with objective criteria
• Comparing competing features or initiatives

When NOT to Use

• Fewer than 3 items (just discuss directly)
• Creating PBIs or writing stories -- use product-owner or story
• Full product strategy -- use product-owner
• Project status tracking -- use project-manager

Prerequisites

• A list of 3+ backlog items (PBIs, features, or user stories)
• IF items exist as files: read from team-artifacts/pbis/ or user-provided path
• IF items provided inline: use the provided descriptions

Workflow

1. Collect items to prioritize

   • IF file path provided -> read items from files
   • IF inline list -> parse items from user message
   • IF fewer than 3 items -> ask user for more or suggest direct discussion

2. Select framework using decision tree:

   IF quantitative data available (reach, metrics)  -> RICE
   IF stakeholder alignment needed (must/should/could) -> MoSCoW
   IF quick decision needed (2 axes only)            -> Value-Effort 2x2
   IF user specifies framework                       -> use that framework
   IF unsure                                         -> ask user, default RICE
   

3. Score each item using selected framework:

   RICE:

   Score = (Reach x Impact x Confidence) / Effort
   
   Reach:      Users affected per quarter (number)
   Impact:     0.25 (minimal) | 0.5 (low) | 1 (medium) | 2 (high) | 3 (massive)
   Confidence: 0.5 (low) | 0.8 (medium) | 1.0 (high)
   Effort:     Story points (1, 2, 3, 5, 8, 13, 21)
   

   MoSCoW:

   Must Have:   Critical for release, non-negotiable
   Should Have: Important but not vital, workarounds exist
   Could Have:  Desirable, include if capacity allows
   Won't Have:  Out of scope for this cycle
   

   Value-Effort 2x2:

   High Value + Low Effort  = Quick Wins    (do first)
   High Value + High Effort = Strategic     (plan carefully)
   Low Value  + Low Effort  = Fill-ins      (if time permits)
   Low Value  + High Effort = Time Sinks    (avoid)
   

4. Rank items by score (descending for RICE, category for MoSCoW, quadrant for V-E)

5. Output prioritized list with scores and rationale

6. IF PBI files exist -> optionally update priority field in frontmatter (numeric 1-999)

Output Format

## Prioritized Backlog

**Framework:** [RICE | MoSCoW | Value-Effort]
**Date:** [YYMMDD]
**Items scored:** [count]

### Rankings

| Rank | Item      | Score | Rationale                                           |
| ---- | --------- | ----- | --------------------------------------------------- |
| 1    | Feature A | 45.0  | High reach (5000), high impact (3), high confidence |
| 2    | Feature B | 12.0  | Medium reach (2000), medium impact, low effort      |
| 3    | Feature C | 2.5   | Low reach, minimal impact, high effort              |

### Recommendations

- **Do first:** [top items]
- **Plan next:** [medium items]
- **Defer:** [low items with reasoning]

Examples

Example 1: RICE scoring of 5 features

Input: "Prioritize: SSO login, dark mode, export to PDF, email notifications, bulk import"

Output:

Rank	Feature	Reach	Impact	Conf	Effort	RICE
1	Email notifications	5000	2	0.8	1	8000
2	SSO login	2000	3	0.8	3	1600
3	Bulk import	500	2	1.0	1	1000
4	Export to PDF	1000	1	0.8	2	400
5	Dark mode	3000	0.5	0.5	2	375

Example 2: MoSCoW categorization

Input: "Categorize for Q1 release: payment gateway, admin dashboard redesign, API rate limiting, user avatars, audit logs"

Output:

• Must Have: Payment gateway (revenue-critical), API rate limiting (security)
• Should Have: Audit logs (compliance, workaround exists with manual exports)
• Could Have: Admin dashboard redesign (improves efficiency but current works)
• Won't Have: User avatars (nice-to-have, defer to Q2)

Optional Escalation: /llm-council on Ties

Gate evaluation: After producing the prioritized backlog (per ## Workflow step output), inspect the ranking output:

• Top-2 RICE scores within 15% of each other → gate fires
• Explicit MoSCoW tie (≥2 items in same Must/Should/Could band with material scope overlap) → gate fires
• Multi-stakeholder disagreement flagged in input → gate fires
• None of the above → gate does NOT fire; skill ends without prompting

MANDATORY ATTENTION — when the gate fires, you MUST use AskUserQuestion to present these options (identical preamble pattern to architecture-design's ## Next Steps MANDATORY ATTENTION block):

• "Escalate to /llm-council (Recommended)" — Tie/disagreement detected. Run 11 sub-agent council (5 advisors + 5 reviewers + chairman). Council's Contrarian + Outsider lenses are well-suited to multi-PBI ranking ties. Cheaper alternatives: /why-review, /plan-validate (use these instead if the tie is narrow but stakes are routine).
• "Skip — accept current ranking" — Acknowledge the tie; proceed with current ranking.

If gate does NOT fire, the prioritization decision stands; do NOT prompt.

Related Skills

Skill	When to use instead
product-owner	Full product management workflow
story	Breaking PBIs into user stories
refine	Refining ideas into PBIs
project-manager	Sprint/project status and tracking

---

Prompt-Enhance Closing Anchors

• IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval
• IMPORTANT MUST ATTENTION for every step/sub-skill call: set in_progress before execution, set completed after execution
• IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence
• IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses

Closing Reminders

• IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting
• IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
• IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act)
• IMPORTANT MUST ATTENTION add a final review todo task to verify work quality
• MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact.
• MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction.

[TASK-PLANNING] Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.

[IMPORTANT] Analyze how big the task is and break it into many small todo tasks systematically before starting — this is very important.

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

AI Mistake Prevention — Failure modes to avoid on every task:

• Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
• Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
• Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
• Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
• When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
• Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
• Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
• Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
• Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
• Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.