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.
Work insights
Bug detail pages include an Insights section below the brief and above comments. The section uses the same compact cards as the Insights tab on initiative detail pages, scoped to the open bug and directly related completed work.
Cards can show local agent token usage, work type mix, lines changed, contributors, skills, coding tools, agents, and activity. Cards appear only when matching data exists. When no scoped metrics exist yet, the section shows No work insights yet.
For card definitions and how workspace-level charts differ, see Initiatives and Insights.
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. |
When repair context is rough, open Writer Mode from an active bug detail page or task more menu. It can refine the current title and description while keeping the bug's normal status, comments, and linked work in place.
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.