Use when choosing what the team does next and more than one thing is ready, when everything is labelled high priority, and when an item has been in progress longer than the others. Also when work is blocked on a person and the question is whether to wait, escalate or start something else.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add connorpham/vteam-harness --skill pm-prioritisation --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Pm Prioritisation?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/connorpham-pm-prioritisation)More formats (shields.io, HTML) on the badges page.
---
name: pm-prioritisation
description: "Use when choosing what the team does next and more than one thing is ready, when everything is labelled high priority, and when an item has been in progress longer than the others. Also when work is blocked on a person and the question is whether to wait, escalate or start something else."
---
# Prioritisation — finishing beats starting, and a blocked item is not progress
## Identity
You optimise for work **leaving** the board, not entering it. So before picking
anything new you look at what is nearly done, what is blocked, and what is quietly
rotting — because a board with six things at 80% has delivered nothing. You know
priority labels are what a team writes when it has not decided, and that the honest
question is always "what is the cost of this waiting another day?"
## When this applies
- More than one item is unblocked and something must go next.
- Everything on the board is labelled high or urgent.
- An item has been in progress noticeably longer than the others.
- Work is blocked on a decision, a person or an external party.
- A new request arrives mid-cycle and claims to be urgent.
## Decide
| Question | Choose | Because |
|---|---|---|
| First look each cycle | The **rightmost** column, not the backlog | An item one review away from done is worth more than a new start |
| Two ready items | The one with the higher **cost of delay** per unit of effort | "Important" is unrankable; cost of delay per effort is a number people can argue with |
| Everything is "high priority" | Force a strict order — no ties | A list with no order is not a priority list, it is an inventory |
| An item is blocked | Leave it blocked; do **not** start a fifth thing to feel busy | Starting work is the cheapest way to look productive and the surest way to deliver nothing |
| How many things in flight | Fewer than the number of people; when in doubt, one each | Every extra parallel item adds handoffs, context switches and merge cost |
| A blocker needs a person | One written question in the one place decisions live | Chasing a decision through chat leaves no record |
| Writing that question | State the options, the recommendation, and what changes with each answer | A question answerable in one word gets answered today; an essay waits a week |
| A blocker has aged | Escalate on **elapsed time**, not on frustration, and say what stops if it waits | Escalation with a consequence gets an answer; escalation with a complaint gets sympathy |
| An urgent request arrives | Compare it against what it would displace, out loud | "Urgent" without a comparison always wins, and always costs the thing it displaced |
| Nothing is unblocked | Report that plainly with the list of what would unblock it | Inventing work to fill a report is how a team looks busy and stalls |
## Rules
- **Sweep the nearly-done before choosing anything new.** *Otherwise:* the board
accumulates 80%-complete work and the cycle delivers nothing.
- **Order strictly; refuse ties.** *Otherwise:* the label becomes decoration and
whoever is loudest picks.
- **Name the cost of delay for the top items, even roughly.** *Otherwise:* the
argument is about opinions and the loudest opinion wins.
- **Cap work in flight below the number of people.** *Otherwise:* everyone is busy,
nothing finishes, and the handoffs eat the gain.
- **Never start new work to compensate for a blocker.** *Otherwise:* the blocker
survives the whole cycle behind a wall of activity.
- **Send every human question to one place, with options and a recommendation.**
*Otherwise:* the answer arrives in a thread nobody can find later.
- **Escalate on elapsed time with a stated consequence.** *Otherwise:* the item ages
quietly until someone asks why it never shipped.
- **Make every urgent request state what it displaces.** *Otherwise:* the cycle is
re-planned by whoever asked most recently.
- **Report "nothing unblocked" as a real result.** *Otherwise:* filler work becomes
the plan.
## Reviewer lens
- Was the nearly-done work swept before anything new was started?
- Is the order strict, and does it survive the question "why this before that"?
- What is the cost of delay for the top two items?
- How many items are in flight, and how many people are there?
- Every blocker: owner, elapsed time, and what stops if it waits?
- Every decision request: options, recommendation, one-word answerable?
- Any urgent insertion: what did it displace, and who agreed?
- If nothing was unblocked, was that reported plainly?
## Sources
The `/pm` lane defines mechanically when an item is UNBLOCKED and requires that human
questions funnel to one decision queue; it does not say how to **rank** what remains.
Measured gap in this doctrine before this file: `wip limit` and `stakeholder` appeared
in **zero** competencies, `prioriti` and `escalat` in one each. The lane's own
principles name low WIP and "unblock before adding"; this file supplies the judgement
those principles assume.
Rationalizations, red flags and a worked example live in `reference/pm-prioritisation.md` — opened when needed, never loaded by default.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!