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: Produce a defensible ranked ordering of 3+ backlog items using RICE, MoSCoW, or Value-Effort frameworks so the team works highest-value items first — every rank backed by a score and tech-agnostic rationale (value/effort/risk/impact).

Summary:

• Require 3+ items first; pick the framework by the decision tree — RICE when quantitative data exists, MoSCoW for stakeholder must/should/could alignment, Value-Effort 2x2 for a quick call — default RICE when unsure.
• Score with the exact framework formula (RICE = Reach×Impact×Confidence ÷ Effort using the fixed Impact/Confidence scales and story-point Effort), then rank descending (RICE), by band (MoSCoW), or by quadrant (V-E).
• Keep every rationale tech-agnostic per M1: justify by value/effort/risk/business impact, never by named stack, framework, or design pattern.
• On a near-tie (top-2 RICE within 15%, same-band MoSCoW overlap, or flagged stakeholder disagreement), the gate fires — use AskUserQuestion to offer /llm-council escalation vs. accepting the ranking; otherwise end without prompting.

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
• Tech-agnostic rationale (M1): See .claude/skills/shared/sdd-artifact-contract.md → "AI-SDD Mandates (M1-M6)" for BLOCKING criteria. Justify every ranking by value, effort, risk, and business impact — NOT by implementation technology. Rationale prose stays tech-agnostic per docs/project-reference/spec-principles.md §3: no framework/product/language/design-pattern names; effort may cite story points and relative complexity, never a named stack.

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 frameworks → ranked list with scores and rationale.

When to Use

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

When NOT to Use

• Fewer than 3 items (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

• List of 3+ backlog items (PBIs, features, user stories)
• IF items exist as files: read from team-artifacts/pbis/ or user-provided path
• IF items provided inline: use 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 prioritized backlog (per ## Workflow step output), inspect 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 Goal: produce a defensible ranked ordering of 3+ backlog items via RICE/MoSCoW/Value-Effort so the team works highest-value items first — every rank backed by a score and tech-agnostic rationale (value/effort/risk/impact)

Protocols in force (concise digest of the SYNC/shared blocks this skill carries):

• Critical Thinking: ALWAYS trace file:line proof for every claim, confidence >80% to act, NEVER present guess as fact.

• AI Mistake Prevention: verify generated content against evidence, trace downstream references, verify all affected outputs, re-read after context loss, surface ambiguity.

• IMPORTANT MUST ATTENTION require 3+ items BEFORE ranking; fewer than 3 → discuss directly, NEVER force a framework — why: ranking 1-2 items adds ceremony without signal

• IMPORTANT MUST ATTENTION keep every rationale tech-agnostic per M1 — justify by value/effort/risk/business impact, NEVER by named stack/framework/product/language/design-pattern; effort may cite story points + relative complexity only — why: spec-principles §3 BLOCKING, a tech-named rationale leaks implementation into a priority call

• IMPORTANT MUST ATTENTION score with the EXACT framework formula (RICE = Reach×Impact×Confidence ÷ Effort, fixed Impact/Confidence scales, story-point Effort), then rank descending (RICE) / by band (MoSCoW) / by quadrant (V-E) — NEVER invent ad-hoc scores — why: a defensible rank needs a reproducible number

• IMPORTANT MUST ATTENTION on a near-tie (top-2 RICE within 15%, same-band MoSCoW overlap, flagged stakeholder disagreement) the gate FIRES — use AskUserQuestion to offer /llm-council escalation vs. accepting the ranking; if the gate does NOT fire, end WITHOUT prompting — why: tie-breaking is a judgment call the user owns, but a clear winner needs no interruption

• IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting; mark one in_progress, completed immediately after evidence

• IMPORTANT MUST ATTENTION search codebase/artifacts for 3+ similar patterns before creating new structure; evaluate pattern FIT (same constraints/scope) before copying a nearby example — why: closest example ≠ matching preconditions

• IMPORTANT MUST ATTENTION cite file:line evidence for every claim (confidence >80% to act, <60% DO NOT recommend); NEVER present a guess as fact

• IMPORTANT MUST ATTENTION optionally update PBI file priority fields (numeric 1-999) ONLY after ranking; grep downstream consumers before changing any priority field — why: stale priority refs cascade silently

• IMPORTANT MUST ATTENTION add a final review todo task to verify work quality

Anti-Rationalization:

Evasion	Rebuttal
"Only 2 items, just rank them"	Below the 3-item floor → discuss directly; a framework adds ceremony, not signal
"I'll cite the framework in the rationale"	Tech-agnostic per M1 — justify by value/effort/risk only, never by named stack
"Scores are close enough, I'll pick"	Near-tie fires the gate → AskUserQuestion for /llm-council, never silently break
"RICE feels right, skip the formula"	Apply the EXACT formula with fixed scales — a defensible rank needs a number
"Already know the patterns"	Show file:line evidence — no proof = no search

MUST ATTENTION apply critical + sequential thinking — every claim needs appropriate traced evidence (file:line for repo/code claims; source URL or artifact section for research, product, content, and docs claims); confidence >80% to act, <60% DO NOT recommend. Anti-hallucination: never present guess as fact, admit uncertainty freely, cross-reference independently, stay skeptical of own confidence.

MUST ATTENTION apply AI mistake prevention — verify generated content against evidence, trace downstream references before deleting or renaming, verify all affected outputs, re-read files after context loss, and surface ambiguity before acting.

[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:

Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing. Before changing a constant, limit, flag, wording, or pattern, read nearby context and history. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.