Documentation

Turn results into improvement actions

Create an action from a run or through an agent, complete it, and record the tracker issue it became

An action is the next step recorded against a health check or retrospective - a title, an optional owner, due date and priority - tracked until it is completed.

Creating one

Once a run reaches Discuss - and after it closes - the results panel for the dimension on stage carries an Actions from this run list. A facilitator adds one with the Create action for … button, which names that dimension, and captures a title, owner, due date and priority. The action is stamped with the run and the dimension, so it appears both there and on the team's list. Everyone in the run reads the list; only a facilitator writes to it. A retrospective board files actions the same way, stamped with the session.

Add action in the Team health → Improvement actions header files one without a run. Pick the team, give it a title, and optionally set an owner, due date and priority; it is stored as a manual action, open. create_action takes the same fields in one call, plus a description that the API and MCP carry and the form does not.

The improvement actions list

Team health → Improvement actions lists every action the viewer can see - everything, for an admin; otherwise their teams' actions plus anything they personally own. Filter by team, status (Open covers open and in progress), priority and owner, plus an Overdue only checkbox; every filter runs on the server and the list pages 25 rows at a time. Tick an action's checkbox to complete it and untick it to reopen it - an admin, the owner, the creator, or any member or manager of the action's team may.

An action past its due date is marked Overdue on the row, and a nightly sweep sends its owner one Inbox notification and fires one action.overdue webhook event per action. Assigning an owner notifies that person; action.created and action.completed fire on the matching writes.

Linking an external tracker

After pushing an action to Jira, GitHub or another tracker through that tool's own MCP connection, an agent can record the resulting issue key or URL against the action. set_action_external_ref stores the provider, the issue key and an optional URL, and every action read returns it.

Correlating against absence

correlate_health_signals lines a dimension's trend up against absence. Given a team's closed-run history, it walks it period by period against approved leave days per member in the same window, flagging inverse movement when a dimension falls while absence rises, and leading decline when people's felt-direction votes turned negative before the average did. It returns the aligned series and the flags, and leaves the reading to the agent.

Worked example

Marta ticks "Rebalance Platform's on-call rotation" done on Improvement actions. When Workload dips again after Platform's next Pulse 5 run, she asks her agent to list Platform's open actions and to correlate the dip against absence before she files a new one.