Initiatives

An initiative is the captured intent. Everything else in the work model is what the team does to deliver it.

A product manager has an idea and writes it as an initiative. A leader has an OKR that needs work and the work is an initiative. A customer-success engineer hears a recurring complaint and the fix is an initiative. The initiative is where intent enters the system, gets shaped (often with the agent's help), and decomposes into the plans an engineer can actually work.

If you are coming from Jira, an initiative is closer to a Feature than a Story or an Epic; it is the unit of intent that holds plans (the work to do it) and bugs (the issues that come up while doing it) underneath. If you are coming from Linear, an initiative is closer to a Linear initiative than to a project; it captures the why, not the who or the where.

How an initiative sits in the work model

An initiative sits inside a project (its required parent) and holds plans, bugs, and test cases underneath. It can carry attachments, depend on other initiatives, and be the target of a goal's key result. Here is the shape of those relationships in one picture.

How it looks in practice

Continuing the worked example.

A customer of the Insights product complained that they have to copy table data out of the reporting page by hand to do their own analysis. Sarah Chen picks up the request and turns it into an initiative.

The distinctive parts are populated like this:

Clarifications (4 total, on the Clarifications tab).

Plans (3, all created by the agent in a single chat turn after the spec was approved).

Bugs (1).

Now look at how the initiative connects.

Upward. The initiative lives in the Insights project (its required parent). Sarah created it from the Insights detail page's Initiatives tab; it inherited the project's default sandbox profile and the project's repository binding.

Downward. Three plans break the work into pieces an engineer can pick up and ship; one bug captures an issue caught during verification; two clarifications are still being worked (one pending revision, one waiting on an answer) and will be folded into the spec on the next Revise Spec.

Sideways. The initiative declares one dependency: an older initiative named "Reporting Page Performance" that wrapped up two weeks ago. The dependency lets the roadmap draw the relationship and lets the planning view show "blocked by" if the dependency had still been in progress.

Goals. A key result on the "Improve customer-reported export usability" goal points at this initiative as a contributing link. Because the initiative is initiative-targeted (not portfolio-supporting), the key result's auto-progress derives from this initiative's plans-progress rollup. As plans complete, the KR ticks up automatically.

Rollups at a glance. On the Initiative detail page Sarah sees: 3 plans, 1 complete (33% progress), 1 bug open, 1 bug total. On the Initiatives kanban, the card sits in the Approved column with chips showing those rollups; she'll drag it to In Progress once the second plan starts.

When you create one

Open SDLC, click into Initiatives, and click New initiative. The only required fields are a title and a project. The rest is optional at creation: a one-line summary, the body (a markdown document for the spec), an owner, start and target dates, a sandbox profile, and open questions.

Most teams skip everything except title at creation, then open the initiative and use Continue in Chat to ask the agent to fill in the body with a code-grounded spec. The agent reads the linked repository, asks clarifying questions back, and drafts the spec. You review, edit, and approve.

The initiative defaults to a status of planning and you as the owner.

Statuses

Six. Backed by a real workflow, with the transitions enforced server-side.

The transitions between them follow a conventional shape: planning → approved → in-progress → done is the happy path; blocked is a side state work returns from to in-progress (or back to planning if the block was about scope); cancelled is the terminal state for descoped work.

The transitions above are the defaults; your admin can customize the initiative workflow at Platform → Workflows, including the colors, the labels, the transitions, and whether each status is creatable (some teams hide Done and Cancelled from the create-status picker so a new initiative always starts in Planning).

A transition that is not allowed by the workflow returns an error and the initiative stays in its current status. The API will not let a caller bypass the rule by sending a different status in a PUT; the workflow is the source of truth.

From idea to approved

The shape of work on a new initiative usually moves like this:

1. Create the initiative with just a title. Pick a project, type a title, save. Status defaults to Planning, owner defaults to you.
2. Click Continue in Chat. The chat panel opens on the right with the initiative already in scope. The agent reads the linked repository in a sandbox and drafts the spec body, often asking clarifying questions back as it works.
3. Capture clarifying questions on the Clarifications tab. As the agent asks, the questions show up grouped by status (Needs Input, Pending Revision, Incorporated). You and the team answer them deliberately rather than scattered through chat.
4. Click Submit Answer on each question once you have a real answer. The question moves from Needs Input to Pending Revision, and a Revise Spec button appears in the tab header.
5. Click Revise Spec. The action launcher opens; you confirm and the agent runs in the background, re-reads the body and the new answers, and rewrites the body to fold the answers in.
6. Read the revised body when the run finishes. The body updates inline (no manual refresh needed); the questions you answered move to the Incorporated subsection; the edit is tagged AI-authored on the version history.
7. Set the status to Approved when the spec reads right. Use the status dropdown in the page header. Approved means the team can start work; plans get picked up after that.

At that point the initiative is ready to break into plans. You can ask the agent in the same chat (something like "draft the plans for this initiative") and it writes them as real plan records under the initiative, tagged as AI-authored. From there an engineer picks up a plan and runs a flow on it.

The whole arc, from a one-line title to an approved spec with plans underneath, can happen in a single sitting, or it can stretch across a week as your team works through the questions. The platform does not assume a tempo; it tracks what changed and who changed it.

The distinctive parts

A handful of features on the initiative go beyond what you would expect from a standard work record.

Clarifications

An initiative carries a list of open questions: the things you do not yet know that have to be resolved before work begins. Each question has text and an optional priority (blocking, important, or nice-to-have).

Questions live on the Clarifications tab, which appears on the initiative detail page whenever the initiative has at least one open question. The tab groups them into three sections so the state of every question is always visible at a glance:

• Needs Input. Questions without an answer yet. The card shows the priority chip, the question text, and an answer textarea.
• Pending Revision. Questions where you have submitted an answer but the spec body has not been updated to incorporate it. A "Revise Spec" button appears in the tab header when there is at least one question in this group.
• Incorporated. Questions whose answers have been folded into the spec body, with a green accent and a lower opacity. These are read-only and stay visible as a record of what was decided.

You submit an answer by typing it in the textarea and clicking Submit Answer. The question moves from Needs Input to Pending Revision; the spec body does not change yet (the revise step is separate so the answers can be folded in as a single pass, not scattered as side notes).

Revise Spec

Revise Spec is the AI action that folds answered questions into the body. The button appears in the Clarifications tab header whenever at least one question is in the Pending Revision group; clicking it opens the action launcher with the "Revise the spec to incorporate answered clarifications" flow pre-selected.

1. Click Revise Spec. The action launcher slides in from the right with the revise flow selected and the pending answers shown as starting context.
2. Pick the sandbox profile. Defaults to the initiative's profile, or the project's profile if the initiative does not have one set.
3. Launch. The flow runs in the background. The Clarifications tab does not block; you can navigate away while it works.
4. The spec body updates when the flow completes. The platform receives a real-time event when the run finishes, refetches the initiative quietly, and the body re-renders with the answers folded in. The questions you answered move to the Incorporated group on the Clarifications tab.

The body edit is tagged editSource: "ai" like any other agent write, so the version history shows the change as AI-authored. Each incorporated question gets a record of which version of the spec absorbed it, which is how the Incorporated subsection stays accurate over time.

You can run Revise Spec at any moment, not just at creation. If your team adds new clarifications mid-flight, work through the answers and revise the spec to absorb them. The body keeps getting better as the work uncovers things you did not know up front.

Continue in Chat

Every initiative has a Continue in Chat button at the top of its detail page. Clicking it opens the chat panel on the right with the initiative already in scope. The agent has access to the initiative body, the open questions, the child plans, the child bugs, and the attachments; you can ask it to break the initiative into plans, draft a verification plan, review the spec, suggest test cases, or anything else relevant.

The button is disabled if the initiative has no sandbox profile yet. Either set one on the initiative or let it inherit one from the project.

Breaking an initiative into plans is the most common job the chat handles. Ask the agent to draft the plans and it will write them as real plan records under the initiative, with type, summary, and acceptance criteria filled in. You review each one in the Plans tab and edit anything that needs editing; the agent's writes are tagged AI-authored so a reviewer can see what was drafted versus what was hand-written. This is the workflow most teams use day to day; creating plans one at a time from the Plans tab is available too, but the chat path is usually faster and produces a better-shaped set.

External system links

When you sync an initiative with an integration like Azure DevOps, the platform stores the external ID and renders the connection on the initiative detail page. The links live in a sidebar section on the Spec tab; one row per integration, with the integration's name and type badge, the work-item ID (clickable through to the external system when the integration provides a URL), the linked test cases (clickable through to the platform's local copy when the IDs match), and a last-synced timestamp.

This is what makes the initiative a real coordination point between your team's planning in Disco Parrot and the work-tracking your organization may also be doing in Azure DevOps. A PM reading the initiative sees the same record from both sides; the engineer working from the ADO board sees the link back to the spec.

The integration links are read-only on the initiative page itself; managing them happens through the integration's setup flow (Platform → Integrations) or through the agent when it picks up a sync action.

The dependsOn graph

An initiative can declare other initiatives it depends on. This shapes the roadmap (a dependent initiative cannot start before its dependencies finish) and the planning view (an initiative blocked by an unfinished dependency surfaces that blocker).

The graph is free-form: you add and remove dependencies as planning evolves. The platform does not currently check the graph for cycles, so if you add A depending on B and B depending on A, both links will store and the roadmap will draw them. Treat dependsOn as a shared sketch your team maintains; a quick review at planning time keeps it clean.

For relationships within an initiative (sub-tasks, breakdowns, sequencing), the plan records underneath are the structure to use. Initiatives are flat under projects; modeling intent as a tree of initiatives within a project tends to obscure rather than clarify, and the dependsOn graph plus the plan hierarchy together cover the relationships most teams actually need.

What an initiative connects to

A short reference of the relationships.

• Project (1:1). Every initiative belongs to a project. The project ID is required on creation.
• Plans (1:N). Plans are the work units underneath. Each plan has the initiative as its required parent.
• Bugs (1:N). Every bug rolls up to an initiative (server-enforced). A bug can also be scoped to a specific plan if it was found while working that plan, but the initiative parent is always required.
• Test cases (1:N). Test cases are initiative-scoped. A test case can also be linked to a verification plan, but the initiative parent is always required.
• Key results. A goal's key result can point at an initiative as a "contributing" link, which lets the key result's progress derive from the initiative's progress.
• Other initiatives via dependsOn. A free-form list.
• Attachments. Documents and files attached to the initiative are materialized into the agent's sandbox at chat start, alongside the spec.

Rollups

An initiative carries five built-in rollups that compute from its children.

• Plans count. The number of non-cancelled plans.
• Plans complete count. The number of plans with status "complete."
• Plans progress. The percentage of non-cancelled plans that are complete. Zero if there are no plans.
• Bugs count. The number of non-cancelled bugs.
• Bugs open count. The number of bugs in an open status (triage, backlog, todo, in-progress, in-review).

The rollups show on the initiative detail page, on the Initiatives list, and on the per-project Initiatives tab. They compute on demand (not cached) so they are always fresh.

Versioning

Initiatives are versioned. Every meaningful save creates a snapshot of the full record, tagged with who edited it and whether the edit came from a user or the agent. The version history is a tab on the initiative detail page.

What a snapshot covers

A snapshot covers all fields except the kanban sort order (which is internal positioning, not content). The edit source (user or AI) is stamped on every snapshot, so a reviewer reading the history can tell which fields were written by a person and which by the agent.

Restoring is non-destructive

Restoring a previous version writes a new version with the old content and a change note like Restored from v12. The old versions stay intact, so you can restore again later if you change your mind, and you have a record of when a restore happened and who triggered it.

Concurrent edits

If you and a teammate save changes at the same time, the system's last-write-wins on the record itself and both versions are preserved in history. You can see both attempts on the Version History tab.

The detail page

The initiative detail page is the place you spend the most time on a record. It carries the spec, the related work, and a chat panel one button away. The tabs across the top:

• Spec holds the title, summary, body, and the sidebar with the project chip, dates, progress, rollup chips, and any external system links. The primary view.
• Plans lists the child plans. New plans created here are pre-filled with the initiative.
• Bugs lists the child bugs, organized by status.
• Test Cases lists the initiative-scoped test cases.
• Clarifications (conditional). Appears when the initiative has at least one open question. The three-group view (Needs Input, Pending Revision, Incorporated) plus the Revise Spec button.
• Documentation renders the repository wiki for the project's linked repo, scoped to the initiative. Distinct from the Documents tab.
• Documents lists the files and documents attached to the initiative (uploaded files, imported docs).
• Sessions lists every chat and flow run that has worked this initiative.
• Version History holds the snapshots and the restore controls.

The page header carries the Continue in Chat button, the status dropdown (with allowed transitions only), the action launcher for running a flow or a skill, and the kebab for edit, delete, and the rest.

The list

The Initiatives page is the team's daily-work surface. It runs on the shared data grid, so everything that grid does (column filters, the filter panel, inline editing, bulk edit with select-all-matching, shareable URL views) works here. The default columns are title, status, owner, project, start and target dates, progress, and updated timestamp.

There is also a kanban board for initiatives, with one column per status. Drag a card to a different column and the platform runs the status transition through validateTransition server-side; invalid transitions reject with an error toast and the card snaps back. Within a column, cards stay in the order the server returns them; this is the boundary today between status-change (drag-across) and reorder-within-status (not yet wired for initiatives). The cross-project roadmap places initiatives on a time axis with their dependencies drawn between them.

Cross-links