prioritization

name	prioritization
description	Produces a PRIORITIZATION.md (a ranked backlog under one stated framework — RICE/value-effort/WSJF — with per-item scores and an explicit cut line); primes the editorial + ai gates. Use to rank candidate items before sequencing a roadmap.

prioritization

The ranking producer of the product domain — it turns a set of candidate items (a PRD.md's stories, the brief's bets, or a raw backlog) into a PRIORITIZATION.md: one explicitly-stated framework (RICE / value-effort / WSJF / Kano), per-item scores against that framework's criteria, and an explicit cut line dividing what's in from what's deferred. The bar is that the ranking follows the framework, not vibes, and is reproducible — the same items and framework yield the same order. Verified by Attestation: a named owner attests the ranking is sound and owns the call. prioritization produces the ranking that roadmap then sequences; it does not sequence into horizons itself.

What this does / does not do

Does: resolve the prioritization sub_target, declare one scoring framework + its criteria, score each candidate item against them, rank by the composite, draw an explicit cut line, and write a PRIORITIZATION.md; write a prioritization receipt. Does not: decide the problem/persona/success metric (that is product-brief), sequence the winners into now/next/later horizons (that is roadmap), build the items (the target domain's executor does), issue the gate verdict (the editorial/ai gates do — this primes them), or invent scores (inputs are sourced or flagged as estimates, never fabricated).

When NOT to use

• The work is sequencing already-chosen bets into horizons / a timeline — that is roadmap; prioritization scores and ranks, it does not sequence.
• The work is deciding the problem or the success metric itself — that is product-brief.
• A current, committed PRIORITIZATION.md still fits and nothing changed — re-scoring a stable ranking churns a contract stakeholders are tracking.
• The user wants the ranking attested or the items built — that is the Attestation owner + the build domain.

Reference Routing

Situation	Reference
The PRIORITIZATION.md contract template	references/prioritization-template.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md
The (optional) product contract for the value metric	the attested PRODUCT-BRIEF.md, when present

Inputs

• The candidate items to rank — a PRD.md's user stories, the brief's bets, or a raw backlog list.
• The attested PRODUCT-BRIEF.md when present — the success metric the value score serves (optional; a raw backlog can be ranked without it, with the gap flagged).
• The product domain pack (../vocabulary.md, ../acceptance/) + state/intake.json.

How to do it

1. Gather the candidates: collect the items to rank (PRD stories / brief bets / a raw backlog). Each is a unit of value to be scored, not a task.
2. Choose ONE framework: declare it and why (RICE / value-effort / WSJF / Kano). State its criteria and the scale before any scoring — the framework comes before the ranking, not reverse-fitted to a desired order.
3. Anchor the value axis: if a PRODUCT-BRIEF.md is present, tie the value/impact criterion to its success metric; if not, define value explicitly and flag that it lacks a metric anchor (cold-start).
4. Score each item: assign per-criterion scores on the stated scale, then the composite. Sources or estimates are labelled; an estimated input is flagged (record_type: alert), not stated as certainty (the ai gate).
5. Rank + draw the cut line: order by the composite, then place an explicit cut line — above it is in scope this round, below it is deferred — with the rationale for where the line falls (capacity / risk / theme).
6. Check reproducibility: a second pass on the same inputs and framework reproduces the order; if it does not, the scoring is subjective — tighten the criteria.
7. Write PRIORITIZATION.md from references/prioritization-template.md; name the attestation owner.

Gate (before marking complete)

• Exactly one framework is declared, with its criteria + scale, before the ranking.
• Every item has per-criterion scores and a composite; the order follows the composite.
• The ranking is reproducible (same inputs + framework yield the same order), not a vibe sort.
• An explicit cut line is drawn with a stated rationale.
• Estimated/sourced inputs are labelled; no fabricated scores (the ai gate).
• An attestation owner is named.

A gate failure is fixed before lock, not waived — these mirror the editorial/ai gates.

Output

• PRIORITIZATION.md at the product root (or product/PRIORITIZATION.md; BACKLOG.md is an accepted alias) — persistence: Spec-Anchored. The framework + criteria · per-item scores + composite · ranked order · explicit cut line + rationale · attestation owner.
• receipt (<workspace>/receipts/prioritization-receipt-<ts>.json): base schema + sub_target, framework, items_scored, cut_line, reproducible, prioritization_path, attested_by, gate_checks. persistence: Spec-Anchored.

Proactive Triggers

• A ranking with no stated framework: declare one (RICE / value-effort / …) and re-score — an unframed ranking is the vibes-sort failure mode.
• Scores reverse-fitted to a desired order: the framework comes first; if the order drove the scores, redo it honestly or the ranking is not reproducible.
• A fabricated estimate stated as fact: label it sourced or flag it as an estimate (the ai gate); do not present invented numbers as certainty.
• No cut line: a ranking with everything "in" made no decision — draw the line and say why.

Completion Criteria

Done when: a PRIORITIZATION.md exists with one declared framework, per-item scores and a composite, a reproducible ranking, an explicit cut line with rationale, and a named attestation owner; a prioritization receipt records the gate checks.

Not done if: no framework is stated; the order does not follow the scores; the ranking is not reproducible; the cut line is missing; scores were fabricated rather than sourced/flagged; or no owner is named.

Next step: roadmap sequences the above-the-line bets into horizons; the target domain's executor builds each (verified by that domain's mode); the named owner attests the ranking (Attestation).

Related Skills

• roadmap: sequences the chosen bets into now/next/later. prioritization ranks and cuts; roadmap sequences the survivors. Prioritization runs first.
• product-brief: decides the problem/persona/success metric the value score serves. Optional upstream — prioritization can rank a raw backlog, but anchors value to the brief's metric when present.
• prd: specifies a chosen item into testable requirements. A top-ranked item becomes a PRD becomes a build.