Action Items

Action items emerge from sessions or direct creation. They record intent, acceptance criteria, relationships, provenance, and implementation evidence. They are not messages sent to agents.

Creating and managing items

Create items during a conversation or from the Action Items page. Use assignees for human planning and visibility; assigning a person does not route the item to that person's coding agent.

Lifecycle and agent activity are separate. The current lifecycle/completion rules are served at devspec://product/implementation-contract; do not infer completion from an agent status or duplicate server policy in clients.

Asking an agent to implement

Implementation requires a current explicit user request:

• a direct request naming the item;
• a server-authorized exact-target canonical conversation command from the connection owner or an authorized delegate; or
• a direct user-invoked implementation surface naming the item ids.

The agent then calls reserve_work_items with the requested ids in order and claim_work_item one item at a time. Internal assignment/reservation rows coordinate competing claims only. They do not deliver work or grant implementation authority. Presence, read-only discovery, controls, and automations are separate surfaces.

Dependencies and conflicts

A blocks relationship records a real prerequisite. Claim guards can reject an item whose required dependency is unresolved. File-scope and semantic-conflict guards can likewise prevent incompatible concurrent claims.

These relationships coordinate work the user already requested; they do not select a next item. When a guard rejects a reserve or claim, follow the returned reason rather than forcing past it or substituting unrelated work.

Relationship types

• Blocks — target work depends on the source.
• Related to — informational connection.
• Caused by — target arose because of the source.
• Supersedes — source replaces the recorded intent of the target.

Deferred and follow-up work

• Defer parks work while preserving it and is reversible.
• Move to follow-up extracts genuinely separate future scope into a linked standalone item.
• Dismiss records that the item will not be done.

A later implementation still needs a fresh explicit request; resuming or discovering an item does not send it to an agent.

Implementation and verification

After claiming, an agent implements in an isolated branch/worktree, runs configured checks, tags the commit [devspec:<id>], and records implementation evidence. DevSpec returns the resulting lifecycle. Verification surfaces record acceptance-criterion evidence and apply the served completion contract; this page does not redefine who may write done.

MCP integration

External tools can discover and read action items freely. Work acquisition is explicit: reserve_work_items for the user-requested ordered ids, then claim_work_item one at a time. Use record_implementation for completion evidence rather than direct done writes.