Initiatives

An initiative is a slice of work an agent can plan and build. It is where a product stops being described and starts producing changes to a codebase.

The first initiatives are generated from your completed product documents, so they are derived from the specification rather than assembled by hand. They arrive sequenced by dependency, estimated, and starting from foundations: your first product describes the shape of what you get.

On an imported codebase, those first initiatives are a gap analysis rather than a build plan. Every one of them traces to evidence the import recorded: a capability whose absence explains several findings or a policy violation, a finding with no one-click fix in Maintaining, or the foundation for building and testing changes where the repository has none. A finding with a one-click fix is left to Maintaining, unless another initiative builds on it or it is all there is to plan. Import an existing codebase describes that first set. When a linked repository is available, the planner reads it to confirm something is missing before naming it; if the repository cannot be read, the planner works from the documents alone. What already works is not rebuilt.

The board is a line

The initiatives list is grouped by where each initiative is on the way to a merged pull request, furthest along at the top:

• Build: the one initiative Taiga is working. Planning is the first thing it does there, so this is where a plan being written, a plan waiting for your verdict, and a run in flight all sit.
• Queue: initiatives you have lined up, in the order you want them done.
• Todo: work you mean to do soon.
• Backlog: everything else, someday.

Done and Canceled sit below, and archived work behind Show archived.

The top two groups are the line, and Taiga works them on its own: it takes the first initiative in the queue, plans it, builds the plan, and starts the next when the pull request is merged. The two groups below them are yours, and Taiga never moves anything into or out of them.

One at a time, planning included. Build holds a single initiative per product, and nothing else starts work, so Taiga is never planning one initiative while building another. The order the queue is in is the order things happen.

An initiative also carries dependencies: what blocks it, and what it blocks. Those stay editable at all times, because scheduling is not an input to a run.

Moving work along

You move an initiative by dragging its row into another group, or from the menu at the end of its row, which offers the same moves. The same menu works from the keyboard, and so does the drag handle: focus it, press space to pick the initiative up, move it with the arrow keys, then press space again to drop it, or escape to leave it where it was.

The queue is the only way to start something. There is no “plan this now”: you put an initiative in line and its turn comes, which is what keeps Taiga to one thing at a time. To do something first, drag it to the top of the queue.

From Backlog and Todo you can move it to the other, or add it to the queue. From the queue you can take it back out to either. From Build you can take it off the line entirely — to Todo, to Backlog, or back into the queue. If Taiga is in the middle of planning or building it, that asks you first, because leaving means throwing that work away; the plan or the run is stopped before the move. Sending it back to the queue means it is planned again when its turn comes. The exception is an initiative whose pull request is still open, waiting for your review or your merge: it waits its turn in the queue without holding Build, and when the turn comes that same pull request comes back to Build instead of a new plan. If Taiga picks the pull request up again while it waits, to answer a review, it is in Build for as long as it works on it. If the pull request is closed while it waits, the initiative is planned again when its turn comes, like any other.

Taking it off the line closes its pull request. Moving an initiative whose pull request is waiting for your review or your merge to Todo, Backlog or Canceled closes that pull request, wherever the initiative is on the board. Taiga asks first, closes the pull request before it moves the initiative, and leaves a comment on the pull request saying why it closed. If GitHub refuses the close, nothing is moved and Taiga tells you why. The branch stays, and reopening the pull request on GitHub brings the review back. Otherwise, when the initiative comes back to the queue it is planned and built again. To keep the pull request open while something else goes first, put the initiative in the queue instead. Marking it Done leaves the pull request open, since you may still merge it.

You can finish an initiative by hand. Mark it Done or Canceled yourself, from any group, without waiting on a pull request. Marking a building initiative Done asks first, because Taiga would otherwise complete it for you when its pull request merges.

Archiving puts work out of the way without discarding it. Archive files an initiative away from anywhere except Build, and Unarchive returns it to the group it left. Archived work stays behind Show archived.

Backlog, Todo and the queue keep the order you give them. Done, Canceled and the archive keep the order you arrange them in too. Build holds one initiative, so it has no order.

Adding more initiatives

The first batch is not the last. New work, a feature, a fix, a piece of tech debt, enters as a new initiative, and there is one way to add it: describe it, and an agent adds it to the backlog.

A request you describe. The agent reads your product documents, expands what you wrote into a full brief, and turns it into one initiative, or an ordered set for bigger work, with the dependencies between them linked. You give it a title and a description, and the description takes pasted images. It runs in the background, and the initiatives appear in Backlog when it finishes. You can also talk a request through first in product chat, whose card hands the brief to the same agent. While it runs, a pending row holds its place in Backlog, and you can cancel it there; a second request waits until the first is done. Each one is planned in detail later, when it is queued for building.

No request at all. Leave the request empty and the agent suggests one next initiative, in this order:

1. On a product imported from an existing repository, the most urgent open evidence that no initiative covers yet: a security finding urgent enough to act on that has no one-click fix on the Maintaining tab, or a critical or high policy violation. When the suggestion addresses that evidence it is linked to it, so the next suggestion moves on to the next one.
2. Something your product documents describe, such as a user journey or a requirement, that no initiative delivers yet.
3. An idea that fits the product, tied to someone your documents say it serves.

If nothing is left to suggest, no initiative is added. A finding the Maintaining tab can fix in one click is never suggested here: fix it from the Maintaining tab.

Either way, the agent also reads the product’s linked repository when Taiga can reach it. A request you write is planned against the code that is there rather than against a description of it, and a suggestion is checked against the code before it proposes something as missing. If the repository cannot be read at that moment, the work is still planned, from the documents alone.

One request is not always one initiative. What comes back is sized to what you asked for. A request that is a single piece of work stays a single initiative. A request that describes a program of work comes back as an ordered set of them, each small enough to plan, build and review on its own, and each depending on the ones that have to land before it. Ask to migrate a frontend from Vue to React, for example, and you get the seam that lets both run side by side first, the views ported across after it, and the removal of the old framework last.

Not every request adds an initiative, and Taiga always says which answer you got. Most requests are planned, and you get the initiative, or the ordered set of them, described above. If an existing initiative already covers what you asked for, Taiga names that initiative and adds nothing. If Taiga cannot read what you typed as work to build, or the request is not something this product builds at all, it adds nothing and tells you which of the two it was.

A policy of your own can block a request, and Taiga tells you how to unblock it. When a request is clear and buildable and one of your company policies does not allow it as asked, nothing is planned, and nothing is quietly dropped. Taiga names the policy, says what in the request conflicts with it, and gives you the route the policy itself defines for deciding otherwise. It also quotes the line your request runs into, whenever it can copy that line out of your policy word for word: a quote it cannot verify against your own text is dropped rather than shown, because a quotation you cannot check is worse than none. Record the exception your policy asks for, or change the policy, and ask again. Taiga does not argue the technology with you either way: it repeats what your policy already says, and leaves the decision where your organization put it.

Images pasted into the description travel with what the planner adds. A new initiative starts in Backlog.

From intent to plan

An initiative starts as a description of intent. Planning turns it into steps, and it starts one way: the initiative reaches the front of the queue.

An initiative the planner writes, or one Taiga raises from a finding, a policy violation or monitoring setup, states that intent in three parts: the end state in a sentence or two, Why it is needed, and Scope, which says what the work covers and what it leaves alone. An initiative the planner writes can also say What it looks like once it lands: what people see and do, or for platform work, the shape of the system. None of it is the plan: the steps, files and tests come when the initiative is planned. The planner is instructed to plan every item the work covers and nothing it leaves alone. A description you write yourself can take any shape.

The planner reads your repository, the whole document set, your policies and instructions, and the product’s real deployment topology, so the steps describe changes to actual files and actual infrastructure rather than to a guess about them.

Plans are versioned. Plan again, on the initiative’s page, supersedes the plan and keeps it, and every run records which plan version it executed. It is offered whenever the turn is yours — a plan that failed, a plan you do not want built, a run whose direction was wrong — and not while an agent is mid-plan: there is nothing to redo yet, and stopping one is a different decision.

A finished plan is built as soon as the product has room for it. Taiga builds one initiative at a time per product: when a plan lands and nothing else is being built, the run starts on its own, and a review item lands in Action Required alongside it so you can read what is about to be executed.

One gate is worth knowing about. Planning an initiative whose dependencies are not yet settled would produce steps against files that do not exist yet, because the planner reads the codebase as it is now. Putting an initiative in the queue is your override of that: an initiative you have put in line is planned when its turn comes, whatever its dependencies are doing.

Reading the plan first

If you would rather see a plan before anything is built from it, turn off Build on its own by default under Autonomy in the product’s settings. Every landed plan in that product then waits at the Build station with two buttons on its row, and on its page.

Approve builds it now, as you. Reject asks you what should change, and plans again: the planner reads your comment together with the plan you rejected, and the new plan lands in the same place for another look.

That is the product’s default. An initiative can say otherwise for itself: on its page, Build on its own waves this one through a product that normally stops for review, or stops just this one for a look while the rest run through. A plan waiting for you carries the two buttons; one that does not is simply a plan at the Build station, and the line takes it from there.

Two things about it are deliberate.

A failed plan starts nothing. However the planning ended, the agent failed, nobody was left running it, or you stopped it yourself, the initiative is flagged with what went wrong and waits for you. A plan that did not finish is precisely the moment you should look at it, not the moment to hand it to a coding agent.

The run is created as the person who approved the plan, or planned it, and only if they could still start it by hand. Taiga never runs anything as someone who has lost that permission.

Everything else is unchanged. The run opens a pull request and stops there, it merges the way that product’s pull requests merge, by you or on its own, and the run says on its own page that it started this way.

When the line stops on something

When a plan fails, a build fails or is stopped, or a build cannot start, the line stops on that initiative and says why: the row is marked Needs you, with the reason on the badge and on the initiative’s page, and Taiga does not touch that initiative again until you answer.

The initiative stays where it stopped, at the Build station, with a fault to answer. Deciding the plan was the problem is your call, not the line’s.

The verb on the row says what it will do about that particular fault. Resume build carries a broken build on from its first incomplete step, keeping the work already committed. Plan again supersedes the plan and asks the planner for a new one; on a failed plan that is the only sensible answer, so it is the verb you get. A build that could not start offers Try again. Start over builds the current plan again on a fresh branch and keeps nothing from the stopped run. It is offered on the initiative, not on the run: the run is the record of an attempt, and decisions about the work are made where the work lives. If you would rather not, take the initiative off the line — to Todo, to Backlog, or back into the queue to be planned again when its turn comes — and the line carries on without it.

One case cannot be resumed, because it is a decision rather than a failure. An initiative queued by somebody who has since left the organization has nobody for Taiga to run it as: move it out of the line and put it back yourself.

A fix Taiga raises from Maintaining joins the line like any other initiative, at the end of the queue. It waits its turn and holds the Build station while it runs, so nothing jumps your order on its own; a fix that cannot wait is one you drag to the front.

The queue

The queue answers “do these, in this order, one at a time”, and it is the only way work starts.

Add initiatives to it, from their rows, their menus or by dragging them in, and put them in the order you want them done. Taiga takes the first one, plans it, builds it, and opens a pull request. When that merges, whether you merge it or Taiga does, it starts the next.

A few things about it are worth knowing.

It is yours. Taiga never reorders the queue and never decides something of its own should go first. The one thing it adds on its own is a fix from Maintaining, and that goes to the end of the line. If the order changes, a person changed it. Anyone who can start a run on the product can also change the queue.

You order it by dragging. Drag a queued initiative to where you want it and that is the new order. Reordering lives with the list and nowhere else, because putting one initiative ahead of another is a judgment about the ones it is passing, and an initiative’s own page cannot show you those. Its own page still tells it where it sits in line, and can take it out of the queue, but it does not reorder.

It waits for the merge, not for the run. The next initiative is planned only once the previous one is actually merged, because planning reads your repository as it is now. Planning the next one against a main branch that does not yet have the last one produces steps for a codebase that does not exist. This does mean the queue moves at the speed you review pull requests, which is the honest trade and not a limitation we plan to remove.

It stops rather than stepping over. If an initiative’s planning or build fails, the line stops there and tells you why, instead of moving on to the next one. Skipping would plan everything behind it against a main branch missing the work that just failed.

It waits for a repository. Planning reads your repository, so a product with none connected plans and builds nothing, and the queue waits rather than stopping. You can still add initiatives to it and put them in order, and the line takes the first one once a repository is connected. Until then Taiga offers nothing that plans or builds, and points you to where you connect one. If the line stopped on something earlier for want of a repository, answer it once one is connected and the line carries on.

Unfinished dependencies do not stop the queue: putting an initiative in line was your decision to plan it when its turn comes, whatever it depends on.

Pausing the line

Pause the line, in the Build heading, halts the whole line for the product. The plan being generated is cancelled and the build in flight is stopped where it stands; both are flagged, and nothing more is planned or built. Initiatives keep their places, so the board still shows what was about to happen.

Resume the line starts it again. The interrupted plan is planned again from scratch, the interrupted build carries on from its first incomplete step, and the line picks up where it was. A build you had stopped yourself before pausing stays stopped: that was your decision, not the line’s.

The initiative page is where you operate

Everything about a single initiative happens on its own page: the description, the acceptance criteria, the plan and its steps, its activity, and the controls.

An initiative linked to findings or policy violations also lists them under Evidence, whether Taiga raised it to fix them or the planner cited them as the reason for it: each finding’s severity, rule and location, or the policy control, with the way to it.

The activity is the initiative’s history in order: who defined it, who changed its title or description and what the change was, who moved it between columns, when an agent planned or built it, and which pull request each run opened and when it merged. Every run the initiative has had is listed there, with the way into its run log.

Once a run has built the plan, each step on the page shows how it went, and what the step actually did is on the run’s own page. If the initiative is planned again after its last run, the new plan shows as not yet built, and the earlier run stays in the list.

An initiative can have one assignee: the person accountable for it. You choose them in the right-hand column, and only someone who can open the product can be assigned. On the board, an assigned initiative shows its assignee’s avatar at the end of its row. Each assignment, reassignment and unassignment appears in the activity. If the assignee loses access to the product, the initiative is unassigned, and the activity names the person whose change took the access away. The assignee is emailed when the initiative is waiting on them; see Notifications.

Anyone who can open the product can follow an initiative by subscribing to it, with Subscribe at the head of its Activity. The person who creates an initiative is subscribed automatically, and so is each person it is assigned to; someone it is reassigned away from stays subscribed. Initiatives from an imported backlog, and those Taiga raises on its own, start with no subscribers. Beside Subscribe, the faces of everyone subscribed open the list of subscribers. There, anyone who can edit the initiative can add or remove anyone who can open the product, and the audit log records who did it. Unsubscribing is remembered: being assigned again does not subscribe that person again, though they, or someone who can edit the initiative, can. Someone who loses access to the product is no longer subscribed.

An initiative that is done, canceled or archived is read-only. Its description, dependencies and documents stay as the record of what was built; the only change left to make is to reopen it. Anyone who can open the product can still subscribe to it or unsubscribe.

The controls are always available even when the content is locked. Stopping, approving and resuming are decisions about the work, so they are never gated on whether an agent is mid-run.

An initiative is planned by being put in the queue, and only that way. The block it sits in is chosen in one control in the right-hand column: Queue, Todo, Backlog, Done or Canceled. Choosing Queue puts it in line, and the line plans it when its turn comes.

Acceptance criteria

Each criterion is a checkbox with attribution: who marked it met, when, and an optional note.

Criteria an agent verified at the end of a run are marked as verified by an agent. The distinction is deliberate and worth respecting: one is a claim by the thing that wrote the code, the other is a person having checked.

Checking criteria off stays available even while the rest of the initiative is locked, because verifying them against an open pull request is exactly your job at that moment. Rewording or adding a criterion is an edit, and locks with everything else.

What locks, and when

The description, the criterion texts and the step descriptions become read-only whenever an agent holds the turn: while planning, while building, and while a pull request is in review. They reopen the moment it comes back to you.

The reason is that these are inputs. Editing the description halfway through planning produces a plan for something that no longer exists. If you need to change an input mid-run, stop first, edit, then continue.

The shape of an initiative

Two properties decide how well this goes, and both are yours.

Small enough to review. The plan and the diff are the things you approve. An initiative that produces more than you will read carefully is one you will approve without reading.

Specific enough to plan. Detailed planning reads your repository, so an initiative whose intent is clear produces steps against real code rather than against a guess.

When output keeps missing the mark, the fix is usually in standing context rather than in the initiative. See write intake agents can act on.