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.
It carries a title, description, status, teams, assignees, parent relationships, and taxonomy. Taxonomy types include goals, companies, products, skills, coding tools, and agents.
Think of initiatives as large planned tasks with a brief. Do not create an initiative for every small follow-up. Use 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 source brief people, coding tools, and agents build from. Keep the brief clear enough to launch from: problem, expected outcome, constraints, important links, and open decisions.
Bugs
Bugs are repair records for defects, unreliable behavior, or incidents. They often start in the backlog or triage. From there they can be accepted, declined, assigned to a reviewer, planned, blocked, completed, or cancelled.
A useful bug has a clear title, reproduction context, expected behavior, current behavior, impact, reporter, owner or assignee, status, and enough taxonomy to route it. Use taxonomy when a defect affects a customer, product area, skill, or goal.
For spec-driven development, the bug is the repair spec. Keep reproduction steps, expected behavior, actual behavior, impact, and failing links close to the bug before sending it to a person or agent.
Guided writing is available for initiatives. Bugs do not support it yet, so use direct fields and comments to keep the repair context clear.
Fields and statuses
Use initiative fields to make the work comparable and reviewable:
| Field | Use it for |
|---|---|
| Description | Problem, scope, proposal, risks, and decisions. |
| Teams and assignees | Who owns or contributes to the work. |
| Status | Whether the work is an idea, planned, in review, blocked, completed, or cancelled. |
| Effort | A rough low, medium, or high effort signal. |
| Impact | A rough low, medium, or high impact signal. |
| Taxonomy | Goals, companies, products, skills, coding tools, and agents. |
Closed child initiatives stay closed when a parent initiative changes status. That keeps completed or cancelled work from being reopened by accident.
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. |
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
You can create, edit, delete, duplicate, merge, add child initiatives, drag to reorder or reparent, convert between initiative and ongoing work, bulk update, and bulk delete. Planned initiatives can also be stack ranked when they have no planned children.
Use the roadmap table to search, filter, group, and inspect initiatives. Filters can include status, effort, impact, products, companies, goals, teams, and members. Member filters include Unassigned so teams can find work without an accountable person.
Grouping can split initiatives by owner, assignee, team, product, customer, goal, or skill. Initiatives with several matching taxonomy terms or teams appear in each matching group so they are not hidden.
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. Use Documents only when supporting context needs its own attached page, such as research, decisions, diagrams, or handoff notes.