| name | beads-priority-assignment |
| description | Choose Beads issue priority (P0–P4, numeric, or named) from urgency, impact, and risk when creating or triaging work. |
beads-priority-assignment
Use this skill whenever you bd create a issue or re-triage priority (bd update) so the queue reflects real severity. Follow bd doctor / your Beads version for the exact --priority values your CLI accepts (integers 0–4, labels like P0–P4, and/or names like critical / high / medium / low).
Harness mapping (dashboard + types/beads.ts)
Exports and the dashboard normalize numeric priority roughly as:
| Tier | Typical bd inputs | Meaning in this harness |
|---|
| Critical | 0, P0, critical | Drop other work: production down, active exploit, data loss, irreversible customer harm |
| High | 1, P1, high | Urgent: broken main path, release blocker, failing CI on default branch, severe bug with weak workaround |
| Medium | 2, P2, medium | Default scheduled work: most features, typical bugs, refactors with agreed dates |
| Low | 3–4, P3–P4, low | Backlog: polish, nice-to-have, cleanup, research spikes with no near deadline |
Values 3 and above both map to low in the static dashboard export — use them to order work inside the backlog if your bd install preserves numeric order.
Rubric (three axes)
Score mentally; the highest axis that applies usually wins (then downgrade one step if mitigations exist).
- Urgency — Must this start today / this week / this sprint / later?
- Impact — How many users or systems are affected, and how badly?
- Risk if deferred — Does waiting increase security exposure, compliance exposure, cost, or cascade blockers?
Escalate one level if the issue blocks other ready work or sits on a critical path to a dated epic.
De-escalate one level if there is a documented workaround, the area is feature-flagged off, or the report is duplicate / unclear until clarified.
Defaults
- If the user states “P0” / “urgent” / “critical”, map to that tier — do not normalize down.
- If you have no signal after the rubric, use
P2 / 2 / medium (harness default), not empty priority.
- Never inflate priority to look important; never leave priority unset on purpose when the CLI supports it.
Examples
| Situation | Suggested priority |
|---|
| Auth service returning 500 for all logins | 0 / P0 / critical |
CI red on master, no merge until fixed | 1 / P1 / high |
| New feature from roadmap, normal sprint | 2 / P2 / medium |
| Typo in internal-only docs | 3 or 4 / low |
/triage auto-filed “CI failing on PR #n” (matches existing harness command) | 1 / P1 / high |
Commands (non-interactive)
bd create --type task --title "..." --repo <repo> --priority <value>
bd update <id> --priority <value>
After changing priority on an existing issue, add a short Beads comment: worklog: priority set to <value> because <one line>.
