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

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:

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)

Related Skills

product-owner

story

refine

project-manager

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 <!-- SYNC:critical-thinking-mindset:reminder -->
• MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. <!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->
• MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. <!-- /SYNC:ai-mistake-prevention:reminder -->