Initiatives

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

Initiatives are generated from your completed project documents, so the backlog is derived from the specification rather than assembled by hand. It arrives sequenced by dependency, estimated, and starting from foundations: your first project describes the shape of what you get.

The board is organized by whose turn it is

Initiatives are grouped by who currently holds them, not by status in the abstract.

This is the most useful thing to know about the surface. A conventional board answers “what state is this in”. Grouping by turn answers “what needs me”, which is the question you actually open it with. Work waiting on an agent is visible but not yours; work that has come back to you is.

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.

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, the timeline, and the controls.

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

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 build 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.