Skip to main content
A phase is where a piece of work sits in its lifecycle. Every feature and fix has exactly one phase at a time. The phase set is fixed — five values, no custom phases per team. That constraint is deliberate: the board looks the same across every project, and integrations don’t have to translate between team-specific vocabulary.

​
The five phases

​
The state machine

Phases are intended to move forward. They can move backward when work needs rework — for example, a review that surfaces a missed test case moves the feature back to development. Backward transitions are normal; the dashboard doesn’t treat them as failures.

​
How phase is set

You don’t write phase: testing by hand in most workflows. The phase is inferred from signals in your repository:
  • The integration (GitHub Action, generic CI helper, MCP push) reports PR/commit state on each push.
  • Frontmatter on the feature/fix file can override the inferred phase when the integration is wrong (e.g. work-in-progress that isn’t yet in a PR).
The explicit frontmatter override always wins.

​
Phase vs status

Phases are orthogonal to status (not_started, in_progress, completed). Status answers “are we doing this work?”; phase answers “where is it in its lifecycle?”. A feature in phase: testing is necessarily status: in_progress — but a feature in phase: ideation might still be not_started if nobody’s picked it up.

​
Phase rollup on epics

Epics don’t have a phase of their own. The dashboard rolls up the phases of the features and fixes inside the epic and shows a distribution — “8 in development, 3 in review, 2 done”. This is intentional: an epic with mixed phases is healthy and normal; collapsing that to a single epic phase would lose information.

​
See also