/prioritize -- MoSCoW + RICE traceable to product vision

Skill que aplica MoSCoW (bucket) + RICE-adaptado (ranking) a los issues de un pillar, justificando cada veredicto contra el sub-spike PIBER+IDCF declarado en Linear y el vision audit mas reciente (si existe).

El output es:

1. Un report markdown en <codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md.
2. Descripcion de cada issue en Linear con un footer autogenerado (delimiter HTML, idempotente).
3. Un comment snapshot en el sub-spike del pillar (APP-101 para mobile, BACK-101 para backend, etc.).

Anti-trigger

Esta skill NO se activa cuando:

• El usuario quiere priorizar sin contexto de pillar (usar spike-recommend o triaging manual).
• El usuario quiere crear o editar issues individuales (usar MCP directo).
• El input es un PR, branch, o commit (el input es un pillar-slug).

Config resolution

Lee linear-setup.json en la raiz del cwd. Schema esperado:

{
  "team": { "key": "APP" },
  "projects": { ... legacy mapping ... },
  "pillars": {
    "<slug>": {
      "project": "<Linear project name>",
      "spike": "<Linear issue ID>",
      "codebase": "<path relative to cwd or absolute>"
    }
  }
}

• Si el archivo no existe: error claro, sugerir /make-no-mistakes:linear-projects-setup.
• Si pillars.<slug> no existe: modo interactivo (ver commands/prioritize.md).
• Si la config tiene pillars pero falta campo (project, spike, o codebase): pedir el faltante, ofrecer guardar.

Flujo principal

Paso A: Fetching paralelo

Dispatch 3 subagents via Agent tool con runinbackground: true:

Subagent 1 -- fetch-issues:

description: "Fetch issues del project <project-name>"
subagent_type: "general-purpose"
prompt: "Usar mcp__linear-server__list_issues para retornar todos los issues del project '<project-name>'
  que esten en estado Backlog, Todo, o In Progress. Si --issue-ids fue pasado, filtrar solo a esos.
  Output: JSON array con {id, identifier, title, description, labels, state, priority, size_label,
  estimate} por issue. Responder en bajo 200 palabras de explicacion + JSON."

Subagent 2 -- fetch-spike:

description: "Fetch y parse sub-spike PIBER+IDCF <spike-id>"
subagent_type: "general-purpose"
prompt: "Usar mcp__linear-server__get_issue con id=<spike-id>. Parsear el markdown buscando secciones:
  ## P, ## I, ## B, ## E, ## R, ## D -- Design Theses (marcar theses con ⚠️ como killshot),
  ## C -- Capabilities (tabla con build/buy/partner + priority), ## F -- Features (P0, P1, P2, P3),
  y Anti-patterns si existe. Output: JSON estructurado con estos campos + texto raw del spike por
  si la parsing falla. Responder en bajo 300 palabras + JSON."

Subagent 3 -- load-audit:

description: "Load most recent vision audit para <pillar-slug> en <codebase>"
subagent_type: "general-purpose"
prompt: "Glob pattern '<codebase>/audits/<pillar-slug>/vision-audit-*.md'. Si no hay matches,
  responder {audit: null, reason: 'no audit found'}. Si hay matches, elegir el de fecha mas
  reciente (YYYY-MM-DD en el filename). Read ese archivo. Parsear el scorecard table, Design
  Theses table (status OK/PARTIAL/MISSING/DRIFT), Capabilities table, Features por tier,
  Anti-patterns violations, y top 5 recommendations. Output: JSON estructurado + path del
  archivo cargado. Responder en bajo 250 palabras + JSON."

Esperar a los 3 antes de proceder al Paso B. Si subagent-1 o 2 fallan -> exit 2 con mensaje claro. Si subagent-3 falla (o retorna null) -> continuar con audit = null y Confidence default 0.8.

Paso B: MoSCoW bucket assignment

Para cada issue retornado por subagent-1, aplicar las reglas de references/scoring-rules.md en orden. Primera regla que matchea gana.

Output intermedio: cada issue etiquetado con:

• bucket: MUST | SHOULD | COULD | WONT | UNCLASSIFIED | DECOMPOSE
• matched_rules: array de nombres de reglas que aplicaron
• citedthesis / citedfeature / citedcapability / citedantipattern: referencias al spike
• audit_status: si el audit existe y matchea (OK/PARTIAL/MISSING/DRIFT/VIOLATION/null)

UNCLASSIFIED fallback: si ninguna regla matchea, dispatch un subagent sync (no background) con el prompt de references/prompts/llm-fallback-bucket.md, pasando el issue + sections relevantes del spike. Si el subagent retorna confidence < 0.6 -> mantener UNCLASSIFIED. Si >= 0.6 -> asignar el bucket retornado + anotar matchedrules: ["llm-fallback"] + llmrationale: <response>.

DECOMPOSE: issues con size_label == "XL" van a DECOMPOSE directamente, sin pasar por otras reglas. No reciben RICE score. Aparecen en seccion separada del report.

Paso C: RICE intra-bucket ranking

Para cada bucket (MUST, SHOULD, COULD, WONT), si tiene >3 issues:

1. Calcular RICE por issue: (Reach × Impact × Confidence) / Size.
2. Variables:

- Reach: inferir del spike (every user = 9, pillar users = 3, admin-only = 1). Default 3. - Impact: 0 (no thesis avanzada), 1 (1 match), 2 (2+ matches), 3 (killshot ⚠️ match). - Confidence: audit lookup. PARTIAL -> 1.0, DRIFT -> 0.8, MISSING -> 0.5. Sin audit o ambiguo -> 0.8. - Size: XS=1, S=2, M=4, L=8. (XL ya esta en DECOMPOSE.) Sin label -> M=4 + flag low-confidence-estimate.

1. Ranking desc. Empates por issue.identifier lexicografico asc.

Si un bucket tiene ≤3 issues, mantener orden natural (spike-derived) sin rankear. Ver references/frameworks/moscow-rice.md para detalle de edge cases.

Paso D: Confidence flags

Marcar cada issue con flag low-confidence-estimate si:

• size_label missing -> Size default=M.
• description.length < 100 -> Reach/Impact inferidos solo del titulo.
• --no-audit fue pasado pero el audit existe -> Confidence default=0.8.
• Subagent-2 parse warnings presentes (ambiguity en spike sections).

El flag se muestra como "⚠" en el report al lado del RICE score. NO bloquea el ranking.

Paso E: Composicion de artifacts

Generar 3 artifacts en paralelo (via Agent tool subagents para I/O pesado) o secuencial si mas simple:

Artifact 1 -- Priority report markdown:

• Write a <codebase>/audits/<pillar>/priority-<YYYY-MM-DD>.md.
• Si el directorio no existe, crear con mkdir -p.
• Si ya existe un archivo con la misma fecha -> append sufijo -2, -3, etc.
• Template: ver references/linear-mutations.md seccion "Priority report template".

Artifact 2 -- Description footer per issue:

• Solo si --dry-run=false.
• Para cada issue scoreado, leer la description actual via mcplinear-serverget_issue.
• Aplicar la regla de reemplazo idempotente de references/linear-mutations.md seccion "Delimiter convention".
• Escribir la description actualizada via mcplinear-serversave_issue.
• Log success/fail por issue. Fallas NO abortan el batch -- se reportan al final.

Artifact 3 -- Snapshot comment en sub-spike:

• Solo si --dry-run=false.
• Target: pillars.<slug>.spike (ej: APP-101 para mobile).
• NO editar comment anterior. Siempre agregar uno nuevo con fecha.
• Si existe comment previo con patron matching, agregar link al bottom del nuevo comment.
• Usar mcplinear-serversave_comment con el body del template (ver references/linear-mutations.md seccion "Sub-spike comment template").

Paso F: Resumen al usuario

Al final de la ejecucion (independiente de dry-run):

Priority snapshot generado para <pillar>:
  Must:         N issues (top: ALT-XXX, RICE=X.X)
  Should:       N issues
  Could:        N issues
  Won't:        N issues
  Unclassified: N issues (needs human review)
  Decompose:    N issues (XL-sized, suggest /spike-recommend)

Report: <path al priority-*.md>
<If !dry-run:>
  Descriptions updated: N/M issues (<failure count> failures)
  Sub-spike comment: <link to comment>
<If dry-run:>
  Mutations proposed but NOT applied. Run without --dry-run to apply.

Next steps:
  - Review top Musts en el report.
  - Corre `/make-no-mistakes:spike-recommend <issue-id>` para el top-3 Must.
  - Corre `/make-no-mistakes:implement <issue-id>` una vez el brief este listo.

Error handling

Ver references/scoring-rules.md y references/linear-mutations.md para detalle por caso. Tabla resumen:

Reglas de oro

1. Deterministico first, LLM second: las reglas de MoSCoW se aplican primero. LLM solo para UNCLASSIFIED residual.
2. Citar siempre: cada bucket assignment cita el match (thesis #, feature tier, anti-pattern, audit status).
3. Idempotencia en Linear: correr 2 veces debe dar el mismo resultado. Description footer se reemplaza, no se stackea. Sub-spike comment es nuevo cada run (no edit del anterior).
4. Coexistencia de snapshots: el report NO sobreescribe el anterior. Git version-controla.
5. No time estimates: nunca decir "2 sprints", "1 mes". Sequential ordering con milestones conceptuales.
6. Respetar config: si linear-setup.json no declara un pillar, pedir al usuario, ofrecer guardar. Nunca inventar.
7. Low-confidence transparente: si faltan datos, marcar flag, no adivinar sin avisar.

Interaccion con el usuario

• Confirmar args al inicio si algo es ambiguo (pillar sin config, codebase no existe, MCP no disponible).
• Mostrar progreso: "Fetching issues + spike + audit en paralelo...", "Aplicando reglas MoSCoW a N issues...", "Calculando RICE en bucket Must...".
• Al final, mostrar el resumen del Paso F.
• Preguntar si hay mutations fallidas: "Queres reintentar los N issues que fallaron?".

Fallbacks

Si el codebase del pillar no tiene audits/<pillar>/:

• Crear el directorio antes de escribir el report.
• Mencionar en el executive summary del report: "primer priority snapshot, no hay historial previo".

Si el pillar tiene mas de 200 issues:

• Advertir al usuario: "200+ issues detectados, esto puede tomar un rato. Considera filtrar con --issue-ids o cerrar issues obsoletos primero."
• Proceder igual.

Referencias

• references/scoring-rules.md -- tabla deterministica MUST/SHOULD/COULD/WONT.
• references/frameworks/moscow-rice.md -- v1 impl (formula RICE, edge cases).
• references/frameworks/{rice,moscow,ice,wsjf,kano}.md -- v2 stubs.
• references/linear-mutations.md -- delimiter convention + templates.
• references/prompts/llm-fallback-bucket.md -- LLM prompt para UNCLASSIFIED fallback.

Ver tambien el spec completo: docs/superpowers/specs/2026-04-21-prioritize-command-design.md.