git:20260809.21f29b0 to git:20260809.5c2aad2

- Priority is not a feeling, and it isn't the reporter's tone of voice — it's the product of two independently-scored axes. This skill's defining constraint, from ITIL's incident priority matrix: **Priority = Impact × Urgency**, scored separately before they're combined, so a loud but low-impact request and a quiet but high-impact one land where they actually belong instead of where they were pushed.

- This is the ongoing backlog process — for a live production outage happening right now, use `incident-response`'s severity/declaration phase instead; that skill owns the real-time incident path, this one owns the queue.

- ## Phase 1 — Classify

- - **Bug** — something that used to work, or was specified to work, doesn't.

- - **Enhancement** — new capability or improvement; nothing is broken.

- ## Phase 2 — Score Impact × Urgency

- Score each axis independently, then combine — scoring them together is how a vivid report inflates urgency into impact it doesn't have.

- - **Impact** — how much of the system, how many users, or how much business function is actually affected. One user's edge case is not the same impact as an outage of a shared path, regardless of how it's phrased.

- - **Urgency** — how quickly a resolution is actually needed: is there active harm accumulating (data loss, security exposure, blocked release), or is this tolerable for a while even though it matters?

- Write down the reasoning for each axis, not just the resulting P-number — the number alone is where re-litigation starts later; the reasoning is what settles it.

- ## Phase 3 — Verify before committing a priority

- - **For a bug**, reproduce it from the reporter's steps before scoring impact. An unreproduced bug is a `needs-info` state, not a P-number yet — a report that can't be reproduced can't be sized honestly.

- - **For an enhancement**, check whether it's already implemented (search by the underlying capability, not just the request's wording) — a request for something that already exists is a routing decision, not a priority decision.

- ## Phase 4 — Route

- - **`needs-info`** — verification in Phase 3 couldn't confirm the claim, or scoring in Phase 2 is missing information only the reporter has. State precisely what's missing; a vague "need more detail" ask gets a vague answer back.

- - **`ready-to-spec`** — verified, scored, and specific enough to hand to `spec-to-tickets` for slicing into tracer-bullet work.

- - **`scheduled`** — verified and scored, but deliberately queued behind higher-priority work; note the P-number so re-triage later starts from the same reasoning instead of from scratch.

- - **`wontfix`** — rejected (state why) or already implemented (point to where it lives — this is a different reason than rejection and shouldn't be logged the same way, since it means the request was valid but redundant).