Initiatives & Bugs
Before planning starts, new work usually falls into four records: initiatives, bugs, ideas, or ongoing work. Initiatives belong on the roadmap. Bugs describe defects or incidents. Ideas hold requests that have not been accepted yet.
Initiatives
Create an initiative for planned work that needs roadmap context: a project, product bet, customer request, engineering program, or commitment that should stay visible beyond a single day.
An initiative should have enough brief, ownership, and roadmap context for the team to decide what happens next.
Think of initiatives as large planned tasks with a brief. Do not create an initiative for every small follow-up. Keep initiatives for the bigger pieces of planned work; connected tools and AI-generated completed tasks can capture the smaller execution details.
Initiatives can be nested. A large initiative can have child initiatives under it, and the roadmap table shows the hierarchy. Parent initiatives can show progress based on completed or cancelled descendants, excluding ideas.
For spec-driven development, the initiative is the brief people, coding tools, and agents build from. Keep it clear enough to launch from: problem, expected outcome, constraints, important links, and open decisions.
The full initiative field, hierarchy, and action model lives in Initiatives.
Bugs
Bugs are repair records for defects, unreliable behavior, or incidents. They often start in the backlog or triage, then move forward once someone decides whether to accept, decline, duplicate, or route them.
For spec-driven development, the bug is the repair spec. Keep the description and comments clear enough for someone to investigate, fix, and review the defect. Field details live in Bugs.
Initiative statuses
Initiative statuses
| Status | Meaning |
|---|---|
| Idea | Early concept or intake item that still needs shaping. |
| Open | Work exists, but has not been selected for active planning. |
| Planned | Approved or selected for upcoming work. |
| In Progress | Someone is actively working on it. |
| Review | Waiting for review, triage, or human confirmation. |
| Blocked | Waiting on a dependency, decision, missing input, or external issue. |
| Completed | Finished and included in history, recaps, and analytics. |
| Cancelled | Closed without continuing in its current form. |
Guided writing is available for initiatives. Bugs do not support it yet.
Create from anywhere
Select Write in the sidebar or desktop title bar to create an initiative or bug from any page in the workspace. The dialog sets status, parent initiative, owner, assignees, and teams. When you belong to one team in the workspace, that team is preselected.
The create dialog opens over the current page, so you can capture the work without leaving your place.
Completing initiatives and bugs
Marking an initiative or bug completed closes the roadmap item or repair item. A completed task can still appear in Daily recap when the closure needs a clear place in Worked on. Preferences controls whether that task is offered, created automatically, or skipped; Captured Work explains the recap behavior.
Writer Mode
When the brief is rough, create the initiative in Writer Mode. It asks follow-up questions about the problem, scope, constraints, proposal, and risks, then assembles the answers into a working draft. The session stays resumable until the draft is finalized.
The same writing session can continue across the dashboard and Slack. If an initiative already has an active writing session, its detail header shows Continue writing so you can resume the same draft.
Manage initiatives on the roadmap
The roadmap is where initiatives become visible planning work. Create the parent initiative first, add child initiatives when the work needs structure, and keep ownership current before the team starts delivery.
For roadmap filters, grouping, hierarchy, and initiative actions, see Initiatives.
Mentions
Type @ in comments or descriptions to mention a person or link an initiative. Initiative mentions become clickable chips that open the initiative detail panel.
When initiatives are ready to compare, use Priorities to decide what should move next.
Best practices
Do not turn every request into an initiative. Keep feature requests or product input as ideas until they are accepted or declined. Use ongoing work for recurring tasks without a clean end date.
If work already lives in a connected issue tracker, keep status and assignment in that app unless the integration supports editing those fields from the workspace. Add an initiative only when the issue needs broader roadmap context.
Create the initiative or bug first. Add a Document only when supporting context needs its own attached page, such as research, decisions, diagrams, or handoff notes.