Robust Task

Workflow for reliable execution of complex, multi-step tasks. It saves the plan and evidence to a disk workspace for context recovery, validates the plan and every step through an independent reviewer subagent, and routes failures through bounded retry loops with user escalation. Use for critical tasks where reliability matters.

For simpler tasks, consider Quick Task instead.

mcp__moira__start({ workflowId: "moira/robust-task", parentExecutionId: "none" })

The flow runs seven phases: UNDERSTAND → DECOMPOSE → VALIDATE → APPROVE → EXECUTE → VERIFY → DELIVER.

flowchart LR
    A[Understand] --> B[Decompose]
    B --> C[Validate Plan]
    C -->|issues| C
    C -->|clean| D[Approve]
    D -->|revise| B
    D -->|ok| E[Execute Step]
    E --> F[Gate Review]
    F -->|fail| E
    F -->|pass| G{More Steps?}
    G -->|yes| E
    G -->|no| H[Verify Criteria]
    H --> I[Final Review]
    I -->|gaps| H
    I -->|ok| J[Deliver]

The first step checks whether the agent has file-system access (Read/Write/Edit tools). The rest of the flow adapts to the answer.

With file access (preferred), the workflow creates a workspace and works from disk:

• Workspace folder: ./moira-ws/{task-name}-{YYYYMMDD}-{HHMM}/ (path ends with a trailing slash, stored in workspace_path).
• The plan lives in {{workspace_path}}plan.md (one numbered item per step).
• Requirements are frozen in {{workspace_path}}task-requirements.md; the planning standards in {{workspace_path}}planning-standards.md; the process ID in {{workspace_path}}process-id.txt for recovery after session archival.
• Per-step evidence is written to {{workspace_path}}step-{{current_step}}/evidence.md.
• The agent passes paths, not payloads: decompose returns total_steps and plan_saved_to_file — it does NOT echo the plan array back. Reviewers receive file paths and read the artifacts directly.

Without file access, the flow falls back to in-context state: the plan lives only in workflow memory. Decompose must return the full steps[] array plus current_step_action and current_step_expected_output for step 1, and each complete-step returns the next step’s action and expected output.

Decompose produces as many steps as the task genuinely needs — small tasks may have a few, large tasks many. The plan is not padded or truncated to hit a target number; the task’s real scope decides.

The decompose and validate steps enforce a single canon of planning standards:

Verification never relies on the executing agent’s own judgment. Two layers of independent review run, plus a light self pre-pass before the final one.

After each step executes, verify-step-execution delegates a gate review to an independent reviewer subagent (the executor does not review its own work). The reviewer:

• Reads the full plan and the step’s evidence directly — no trust in summaries.
• Judges the step for plan integrity: does it correctly build on the previous steps and set up the future steps, with no drift, regression, or quality degradation?
• Verifies the evidence fully matches the step’s expected_output (partial match, no concrete evidence, or missing elements all count as NOT verified).
• Returns step_verified (yes/no), issues_found, and verification_details.

The reviewer’s verdict is authoritative. On no (with file access), the issues are written to {{workspace_path}}step-{{current_step}}/verification-issues.md.

When all steps are done, completion verification runs in two passes:

1. verify-criteria — a light self pre-pass. The agent re-checks every success criterion against the real artifact (code, files, command output, tests), one criterion at a time, requiring concrete evidence per criterion. “Looks done” / “should work” / “documented as complete” is a gap, not evidence.
2. final-review — an independent final review. A reviewer subagent re-derives success-criteria coverage from the frozen requirements and the real artifacts (not the executor’s claims), one check per criterion, returning final_issues_count (0 = fully covered) and a flat list of gaps.

If the final review finds gaps, the flow routes to fix-gaps and re-verifies.

Every quality loop is bounded by a round counter and escalates to the user instead of looping forever. Each looping step’s directive states that re-entry is expected, not a bug — the agent must not report a stuck flow.

When a step’s gate review fails, the per-step retry loop increments step_retry and retries with reviewer feedback until max_retries. On exhaustion, a Telegram notification fires and the user is asked to choose:

At the approval gate, present-plan waits for an explicit user yes/no. Anything other than a pure “yes” — including “Yes, but…” or “Good, just change…” — is treated as plan_approved: no, and the flow routes through the revise-plan branch (not teleport). The agent records the comments in revision_feedback and does not fix the plan itself; the workflow drives the revision.

During execution, if the remaining plan no longer fits what has already been built, the agent uses the teleport-replan jump. It does not restart from step 1:

1. The current step is closed as-is — recorded honestly, even if partial.
2. Completed steps (1..current) are kept untouched.
3. Any unfinished part of the current step moves forward into a new next step.
4. Only the tail (steps after the current one) is reshaped or extended to fit the revision reason.
5. The steps are recounted and total_steps is refreshed.
6. The cursor advances and the revised plan is re-validated.

The engine owns the step counter. Expression nodes advance current_step (current_step = current_step + 1) and reset step_retry to 0; the agent never does the arithmetic and must not change current_step itself. The check-all-steps-done condition compares current_step against total_steps to decide whether to execute the next step or move to completion verification.

{
  "type": "expression",
  "id": "expr-inc-current-step",
  "expressions": [
    "current_step = current_step + 1",
    "step_retry = 0"
  ],
  "connections": { "default": "check-all-steps-done" }
}

Each step must produce verifiable evidence, not a “done” claim.

With file access the evidence is written to {{workspace_path}}step-{{current_step}}/evidence.md; reviewers read it directly.

The flow sends a Telegram notification at three points (and continues even if sending fails):

• Plan ready — the validated plan is ready for the user to confirm.
• Escalation — a step failed after max_retries and a decision is required.
• Completion — the task is finished and the deliverable is ready.

• Implement a feature with tests and verification
• Write and publish an article
• Conduct research and produce a report
• Any multi-step task requiring verified completion and recovery after context loss

• Quick Task — For simpler tasks
• Content Creation — For text content creation
• Verified Research — For research with verified sources
• Workflow Templates Overview — All available templates