Bugs
Bugs capture defects with enough detail for triage, ownership, and repair.
Create bugs directly or bring them in from connected issue trackers such as Jira, Linear, GitHub Issues, or GitLab.
What a bug needs
Bugs use the same work model as other planned records, with bug-specific routing through priority, reporter, reviewer, and connected issue metadata when those apply.
| Field | Purpose |
|---|---|
| Title | Names the defect or incident. |
| Description | Holds the detail someone needs to understand the problem. |
| Status | Shows whether the bug is in intake, planned, in progress, blocked, in review, completed, or cancelled. |
| Priority | Helps route urgent or important repair work. |
| Owner and assignees | Show who is accountable and who is doing the repair work. |
| Teams | Decide where the bug appears for planning, standups, and updates. |
| Parent initiative | Connects the bug to larger planned work when the repair supports a roadmap item. |
| Reporter and reviewer | Appear for triage and review intake flows. |
| Taxonomy | Connects the bug to a customer, product area, skill, or goal when that affects routing or reporting. |
For spec-driven development, the bug is the repair spec. Put investigation notes, screenshots, logs, or failing links in the description or comments when they help someone fix it.
Where bugs move
Bugs often start in the backlog or triage queue. From there they can be assigned, planned, moved to in progress, sent for review, blocked, completed, or cancelled.
When you mark a bug completed, the same optional completed-task behavior applies as for initiatives. Captured Work explains how those closures appear in Daily recap and the Journal.
Bug priorities from connected issue trackers
| Priority | Meaning |
|---|---|
Critical | Highest severity work that needs immediate attention. |
Urgent | Time-sensitive work that should interrupt normal ordering. |
High | Important work that should be handled before the default queue. |
Medium | Normal priority work. |
Low | Useful work that can wait behind higher-impact items. |
Lowest | Low-impact work to keep visible without crowding current planning. |
Guided writing is available for initiatives, not bugs. Keep repair context in the description and comments.
When a bug comes from Jira, Linear, GitHub, or GitLab, we can keep issue fields synchronized with the source issue tracker. Titles, descriptions, status, priority, and assignees may be editable inline depending on the integration and its mappings.
Private follow-up work belongs in private todos. Synced issues follow the visibility rules of the source app, so assume teammates with access to that issue tracker can inspect the issue there.
When a bug is not ready for execution, move through Triage before it becomes planned work. For reviewer decisions, accept, decline, and duplicate behavior, see Triage Items.