Skill: Prioritize Backlog

Purpose and modes

Set source-backed priorities without confusing normal planning with a complete reassessment. Load roadmap modeling and the project's policy. This skill owns priority decisions, not roadmap placement, dependency registration, requirement creation or task decomposition.

Policy is the reusable decision rule; priority and any source-backed same-level precedence are its results. Arrangement rationale explains the applied decision, not a second scoring system. Reuse existing records and pass settled precedence to promotion; do not invent a rank field, force an order for genuine ties or maintain the current item inventory in both the policy and backlog. See the Spec's policy/decision contract.

An explicit policy-change request may select affected settled items for replacement. Policy/framework conflicts are visible; full assessment does not silently waive business policy. Do not run full reassessment merely because promotion needs priorities.

Procedure

1. Read project norms, strategic goals, policy, item sources and current priority decisions. Choose the mode from the request and evidence. Extract facts before asking; ask only for unresolved policy mappings, required comparison inputs or a business decision. If no policy exists, offer framework assessment; do not manufacture project policy from the scoring defaults.
2. Detect the project's declared backlog path and layout. Supported layouts, in fallback order, are a directory of item frontmatter (multi-file), a single file with an items YAML array (yaml-list), H2 entries followed by YAML blocks (h2-yaml), and a Title/Priority table (table). Conventional paths are docs/process-management/backlog/ or docs/backlog/, then their .md equivalents. If mixed, report the ambiguity; preserve declared authority, otherwise use multi-file and report the ignored single file. Never write both. If none is recognizable, report the limitation and hand off to capture-work-items.
3. Inventory every item and retain current priority and decision as audit evidence. Exclude status: declined. Report the selected scope and preserved items. In policy mode, map the stated business conditions to project labels; record the policy reference and exceptions. Unknown conditions remain unresolved. A single item may receive a policy priority without a comparison batch.
4. In framework modes, load four-framework assessment and compare the selected batch using all four methods. For a single item, explain the comparison limitation and ask whether to continue; do not block valid policy application. Show every result and evidence gap, never a weighted average. With missing numeric inputs, report cannot score and obtain evidence rather than calculating invented scores. A gap of two or more levels needs a user decision; a smaller gap yields a provisional RICE suggestion.
5. Present a result table with item, old priority, policy or framework basis, proposed priority, conflict/unknown and rationale. The user settles material trade-offs. Existing authorization or an explicit deterministic project policy can authorize application; do not repeatedly ask to approve settled rules.
6. Write only settled decisions in the detected layout. Preserve source approval and execution. Record priority_decision with final, previous, rationale, decided_by (user/auto), decided_at, and mode. Policy mode adds policy_ref; framework modes add frameworks (rice/wsjf/moscow/ice results). An upward override of the framework consensus also carries strategic_override. Auto denotes deterministic authorized application, not invented business judgment. Multi-file uses frontmatter; yaml-list uses the matching array entry; h2-yaml uses its block; table uses the Priority cell and a linked Priority Decisions section keyed by stable item anchor. Preserve surrounding content.
7. An explicit user decision never to do an item writes status: declined, declined_reason and declined_at; P3 alone does not mean rejection. Never decline automatically. Only the last previous priority is retained; callers needing longer history use project records, not a new archive created here.
8. Report mode, layout, scanned/changed/preserved/unresolved counts, distribution, policy exceptions, framework conflicts and declined count. Suggest promote-roadmap-items; do not invoke it automatically.

Output

A comparison/decision table and updated source priority records. No tier, version membership or date changes are made. Missing source facts are explicit limitations.

Self-Check

• Mode, scope and authoritative layout were resolved before writing.
• Normal policy application preserved settled priorities and terminal exclusions.
• Full reassessment occurred only on explicit intent, retaining previous values.
• Selected framework assessments used all four methods and disclosed gaps/conflicts.
• Decisions cite policy or assessment evidence; business overrides are traceable.
• Source approval, execution, tier and version scope were preserved.
• Output reports changed, preserved and unresolved items without automatically promoting.

Examples

• A project ranks active-customer blockers P0 and sales requests P2. One new customer blocker receives P0 under that policy; settled items are unchanged.
• A user requests complete reassessment after a strategy change. Compare all non-declined items afresh, expose policy conflicts and retain overwritten values.
• A project has no policy and sparse intake. Offer framework comparison, identify missing Reach/Effort evidence and leave unsupported results unresolved.

Filled deliverable example

Filled policy decisions. This is a fictional completed output, not a template or authorization to change the adopting project.

Revision history maintenance

Retain the source priority decision and its previous value as already required. When a settled priority change alters a published roadmap, hand the confirmed before/after decision and policy/assessment basis to update-roadmap for a revision under the revision contract. Do not write tier/version/date changes here or create a competing roadmap history. An unresolved assessment or priority-only source edit not yet reflected in a roadmap is not falsely reported as an applied roadmap revision.

Self-check: material changes are traceable, retained links resolve, and repeated execution adds no duplicate revision.

Deliverable language

Before writing roadmap-chain deliverables, apply the language contract. Read the user instruction, consuming-project policy and existing artifact first; retain a settled choice across handoffs. For a new artifact infer only from consistent reader/document evidence; ask only unresolved gaps or winning-level conflicts. Conversation language and English templates alone do not select artifact language. Record the choice and source in existing norms/planning decisions; no new mandatory configuration. Localize all new prose and display labels consistently while preserving IDs, machine fields, canonical enums, source links and historical originals.

Apply the retained choice to new reports, rationale, tables and diagram labels as well as refreshed roadmap projections. Preserve existing source-record policies; this workflow does not authorize bulk translation of unrelated documents.

Self-check: language evidence and retained choice are explicit; all new display prose is consistent, machine contracts are unchanged, and unavailable checks are reported.