Action Items
Action items emerge naturally from AI sessions. When the AI identifies something actionable (like "you should upgrade lodash" or "the auth module needs input validation") it can create a tracked action item linked to the session. You can also create action items manually. Track them at the project level or globally.
How Action Items Are Created
During a session, the AI may identify tasks or recommendations. These are captured as action items linked to the session and project. You can also create action items manually from the Action Items page.
Managing Action Items
Action items have statuses: open, done, dismissed, and deferred. You can manage them from the global Action Items page in the sidebar or within a specific project. Filter by project, status, or priority to focus on what matters.
Statuses
- Open — active tasks that need attention
- Done — completed and verified work
- Dismissed — items that are no longer relevant (a terminal "won't do" decision)
- Deferred — work you've consciously parked for later. Unlike dismiss, defer is reversible: the item is kept and lands in the Deferred lane, ready to Resume whenever you pick it back up. A deferred item is treated as resolved, so it no longer holds its parent brief open — which is the tidy way to ship a brief whose remaining child is genuinely future work. (Anywhere you can dismiss an item — its card, the detail view, or the Testing page — you can also defer it.)
Defer vs. spin-off. Defer keeps a parked child inside its brief; resuming it later reopens that brief. When the parked work is genuinely separate future work that shouldn't disturb the original (already-shipped) brief, use Move to follow-up (spin-off) instead — it extracts the item into its own standalone follow-up with a "derived from" link back, so the original brief stays complete.
Dependencies & Blocking
Action items can have blocking relationships — where one item must be completed before another can be picked up. This ensures work is executed in the correct order, especially when the autopilot is processing a queue of related changes.
How It Works
When item A "blocks" item B, the autopilot will not pick up item B until item A has reached "done" status. Blocking relationships are transitive: if A blocks B and B blocks C, then C is blocked until both A and B are done. This prevents the autopilot from implementing changes that depend on work that hasn't been completed or verified yet.
Example
- Navigation Cleanup E (kill dead routes) blocks Navigation Cleanup B (rationalize user menu) — because B needs the dead routes removed first.
- Navigation Cleanup B blocks Navigation Cleanup C (fix mobile drawer) — because C mirrors the desktop sidebar that B is restructuring.
- The autopilot processes E first, then B becomes available, then C.
Relationship Types
- Blocks — The source item must be completed before the target item can be picked up. This is the only relationship type that affects queue ordering.
- Related to — Informational link indicating the items are connected. Helps the AI and autopilot understand context but does not block execution.
- Caused by — Indicates the target item was created as a result of the source item. Useful for tracing root causes.
- Supersedes — The source item replaces or supersedes the target item. Useful when requirements change and an older item is no longer relevant.
How Dependencies Are Created
The AI creates blocking relationships during sessions when it identifies that action items have a natural execution order. You can also create relationships manually from the action item detail view by linking items together and choosing the relationship type.
Unblocking the Queue
Blockers must reach "done" status specifically to unblock dependent items — "awaiting verification" does not count. When you verify a completed item (marking it done), any items it was blocking become eligible for the autopilot on the next polling cycle. If your queue is stuck, check whether the blocking items need to be verified first.
Seeing Blocked Items
The autopilot pipeline view on the dashboard shows blocked items with a lock icon. Hover over the lock to see a tooltip listing which items are blocking it (e.g. "Waiting on: Navigation Cleanup E, Navigation Cleanup D"). This makes it easy to identify what needs to be completed or verified to unblock the queue.
If your autopilot is running but not picking up queued items, check the pipeline view for lock icons. The blocker items may be in "awaiting verification" status — verify them to mark them done and unblock the queue.
MCP Integration
Action items are available via MCP, so external coding tools can read your open tasks and mark them as completed when the work is done.
Roadmap
Action items will continue to expand with board/list views and external sync to GitHub Issues, Linear, and Jira.