backlog-prioritization

Backlog Prioritization

A backlog ordered on ticket fields alone re-decides things the organization has already decided. The evidence that changes the order is usually not in the tickets: a commitment made to a client, a decision that makes one item a prerequisite for three others, an area that has produced two incidents this quarter, a cluster of requests that are really one feature. This skill puts that evidence next to each item and reports the order it implies — plus a summary short enough to open a leadership conversation rather than postpone it.

The order is a proposal. Ranking is an act of authority that stays with the people accountable for the outcome; this skill's job is to make their decision better informed, and to be explicit about where its own evidence runs thin.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking, and memory-capture owns any durable write; they ship with the gutt-pro plugin (this plugin depends on it). Without them, follow the rules below and note the gap in one line. Jira access comes from whatever Atlassian tooling the session surfaces; names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Jira is read-only here — never write an order into it. No rank field, no priority field, no sprint or fix-version assignment, no status changes, no edits to any other field. The output is a proposal in the reply. The one permitted write is a comment, drafted and posted only after the user approves the exact text in this session. Treat it as final — approval is the gate, not an undo; a truly needed correction re-approves the text and targets the existing comment if the tool allows, rather than posting a second one. Write markdown and set the tool's content-format parameter to markdown when it exposes one.
2. Every item's position carries its reason, and thin evidence says so. Each ranked item gets the evidence that placed it there. An item whose only input is its own ticket fields is labelled no memory evidence and stays where the board already had it — moving an item on no evidence is the one failure mode this skill must never have. Never let a confident tone stand in for a citation.
3. The criteria come from the organization, not from this skill. Read what the project actually ranks on before ranking anything: the issue type's own field schema, and the values present on the slice. Where custom fields carry value, effort, risk, client, or commitment data, rank on those and name them in the output. Never import an outside scoring framework, never invent weights the organization has not agreed, and never hardcode a field name — discover them per project, and where nothing rankable is exposed, say so and fall back to the visible order plus rule 4's evidence.
4. Evidence is the differentiator, and it is specific. Four kinds move an item: a decision or commitment that binds it, a dependency that makes it block or wait on other items, history in the area it touches (incidents, repeated rework), and overlap with other items in the slice. Where a backlog-dedupe run's clusters are in the session, they are the overlap evidence, cited as such and carrying each cluster's own evidence label — a similarity only cluster stays similarity only here; otherwise step 3's own search covers it. Each one enters the output with its source and date, or it does not enter.
5. Every claim is real and cited — a Jira key, or a memory episode, lesson, decision, or incident with its id and date. No invented history, no commitment attributed to a client that no record shows, no dependency the graph does not carry.
6. Org scope is checked at the output — pass explicit group_ids naming the org group on reads (take the name from session results or ask; never guess one), treat scope as server-decided, and before any item of evidence enters the summary or an offered comment, confirm that item's own scope is the org group. Personal-scope material stays in the in-session output. A summary written for a client audience carries nothing from another client's engagement — check this per line, not per run. Bare tool names, probed with ToolSearch. No memory writes — a durable prioritization rationale goes through memory-capture's gate.