beads-priority-assignment
Choose Beads issue priority (P0–P4, numeric, or named) from urgency, impact, and risk when creating or triaging work.
SKILL.md.claude/skills/beads-priority-assignment/SKILL.md
GitHubbeads-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>] ..." --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>.