Todo List

Todo List turns one goal into an ordered checklist and presents one task at a time. It is intentionally not a result ledger: it does not classify task outcomes, aggregate evidence, or produce a completion report.

Start the workflow

mcp__moira__start({ action: "prepare", workflowId: "moira/todo-list", parentExecutionId: "none" })
mcp__moira__start({ action: "execute", startAttemptId: "<Start attempt ID from prepare>" })

The first step obtains 1–100 tasks. If the current user or caller context already contains a schema-valid ready list, its content stays the author’s: every item is submitted with its wording and scope unchanged, nothing is dropped, and no unrequested work is added. The order is the executor’s: items are placed where their prerequisites already hold, a remark that governs the whole job is attached to the items it constrains instead of being executed as one, and where the resulting order differs from the written one, the difference and the dependency behind it are visible to the author before any work starts. Otherwise the same step plans the list once from the current goal. Each task contains only:

• action: the self-contained work to perform;
• expected_result: the observable condition that proves completion.

Both strings are non-empty and limited to 1,000 characters. Array position is the task identity; the agent does not supply IDs, cursors, totals, statuses, or result codes.

Before completing checklist intake, the agent persists the actual task name through the guarded naming contract in the already materialized workflow-guide.md. Optional execution_note is arbitrary nonempty text of at most 120 characters and never a heading source. An authorized checklist revision updates the name only when actual scope changes; ordering alone retains it. Naming does not change completed positional identity or grant new authority.

Execution

Todo List owns a one-based cursor. It projects the current task, tells the agent its action and expected result, and waits. The agent performs the real work and verifies the expected result before calling step() with the local evidence and the bounded display outcome:

{
  "evidence": "The focused test command passed.",
  "progress_execution_outcome": "The affected test suite passed"
}

Both strings are non-empty and at most 500 characters. evidence is the concrete acknowledgement for the current step, remains node-local, and is not copied into a workflow-global array or terminal report. progress_execution_outcome replaces the latest confirmed Work synopsis for presentation; it is not evidence and never advances the cursor by itself.

If the task is incomplete or blocked, the agent must not call step(). It reports the verified blocker to the user, so the cursor stays on the current task. A schema-valid acknowledgement advances the cursor exactly once. Exhausting the ordered array completes the workflow.

Execution progress

The execution card and exported image share three blocks: Checklist → Prepare → Work. Checklist shows the latest confirmed synopsis of the authoritative ordered list. Prepare represents the engine’s existing derivation of the length, cursor, action, and expected result. Work covers both ordinary task execution and correction of a checklist that stopped describing the remaining work.

The current role remains explicit. Ordinary work is labelled Task N/M and shows the complete current action; the full expected result stays in the agent directive because it may be longer than the bounded progress field. A checklist jump is labelled Revise checklist and uses no task projection that might be unavailable on that route. Both roles belong to the final Work block, so normal completion and a revision that removes the whole unfinished tail both finish the progress presentation without adding a synthetic result step.

The Work block binds the checklist itself: tasks as the items, each item’s action as its title, current_task as the index in progress and total_tasks as the total. The run therefore reports how many tasks are done, which one is in progress and the time its passes spent on each.

Checklist and Work outcomes are bounded render-only values. Revision replaces the checklist synopsis and atomically keeps only a completed-task outcome that remains true for the preserved prefix, or Pending. Progress does not participate in conditions, cursor arithmetic, task data, completion evidence, terminal output, or authority.

Revising the checklist mid-run

When the checklist itself turns out wrong — remaining tasks are obsolete, missing, or in the wrong order — the agent jumps to the revision node instead of finishing a list it knows is wrong:

mcp__moira__step({ processId, attemptId, teleportTo: "teleport-revise-tasks" })

This is a jump target: no step leads into it, so a revision is always a deliberate decision. It is not an escape from a task that is merely hard, blocked, or failing — that case stays with the rule above.

The revision step asks for the complete corrected checklist and the position to continue from:

{
  "tasks": [
    { "action": "…already executed, unchanged…", "expected_result": "…" },
    { "action": "Repair the configuration the first task revealed as wrong", "expected_result": "The service starts with the corrected configuration" }
  ],
  "resume_from_task": 2,
  "progress_checklist_outcome": "The corrected list contains the preserved prefix and two remaining tasks",
  "progress_execution_outcome": "The first task remains verified"
}

Already executed tasks keep their original positions, because position is task identity and the run resumes by position. Everything before resume_from_task is treated as done and is not executed again. The workflow recomputes the total from the submitted array — the agent never supplies counts or cursor arithmetic — and continues through the ordinary cursor check, so a position past the end of the new list simply completes the run.

Supplying an existing checklist

A caller starts Todo as a child workflow and includes its schema-valid ready task array in the child’s task context. The first Todo step then submits that array through the ordinary step() response:

{
  "tasks": [
    {
      "action": "Check the implemented requirement",
      "expected_result": "The caller's domain report contains the verified result"
    }
  ],
  "progress_checklist_outcome": "One ordered task is ready",
  "execution_note": "Check the implemented requirement"
}

There is no separate supplied-task branch and no pre-start input mapping. The intake step preserves the content of a ready array rather than replanning it, orders it by dependency, and starts at the first item. Where two supplied items each need the other’s result, no order satisfies both, and that pair is named to the author rather than chosen silently. Keep domain results in the caller. For example, a requirements-coverage workflow should write its own report and own COVERED/GAP classifications instead of asking Todo List to transport them.

Notifications

Todo List sends two notifications through the user’s configured channels, each headed by the flow name and the run’s task, linked to the run page:

• Checklist ready — once the checklist is confirmed and work starts, with the whole checklist (▶ on the first task, ○ on the rest);
• All tasks done — before the run ends, with every task marked ✓. After a revision this is the revised checklist.

The messages are in English.

The flow has no user gate, so nothing asks the reader to act. Because the flow notifies, starting it for a user with no configured channel is refused with an instruction; an agent that wants to run without notifications prepares the start again with skipNotificationCheck: true. Child runs notify like top-level runs.

Completion contract

Todo List completes with an empty terminal output: {}. Completion means every supplied checklist item received a schema-valid acknowledgement after the agent performed and checked it. Per-item evidence remains in the execution interaction history; it is not promised as an accumulated output API.

A subgraph caller that needs domain data must produce and persist that data itself. The Todo success connection only indicates that the checklist reached its End node.