Menu
Choose Beads issue priority (P0–P4, numeric, or named) from urgency, impact, and risk when creating or triaging work.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run red-green-refactor in vertical slices, emphasizing behavior-first tests and harness quality gates.
Break a plan/PRD into independent vertical-slice Beads issues with explicit dependencies.
Synthesize current context into a PRD and file it as a Beads feature/epic issue.
Phase 2 of the Forge pipeline. Turn a research document into an implementation plan that is built around Beads issues and TDD. Reads plans/research/<slug>.md, designs the build, sets up red-green-refactor test strategy using the tdd skill, materializes a Beads epic/feature/tasks with dependencies and priorities, and defines demo/test checkpoints. Use when starting /forge-plan or the plan step of /forgemaster.
Fact-check an implementation plan against the real codebase and first-party documentation, flagging inaccuracies with what / why / evidence and a severity tier. Use when the user wants a plan reviewed or validated for accuracy, runs /review-plan, or wants a plan checked against real code before implementing. Accepts a Beads issue, a filesystem path, or a plan pasted into chat.
Phase 3 of the Forge pipeline. Execute the plan's Beads tasks with red-green-refactor TDD, committing per checkpoint and pausing at each natural stopping point so the user can run a live demo or test and see the work themselves. Use when starting /forge-implement or the implement step of /forgemaster.
| name | beads-priority-assignment |
| description | Choose Beads issue priority (P0–P4, numeric, or named) from urgency, impact, and risk when creating or triaging work. |
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).
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.
Score mentally; the highest axis that applies usually wins (then downgrade one step if mitigations exist).
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.
P2 / 2 / medium (harness default), not empty priority.| 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 |
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>.