Review Node

The Review node is a gate that pauses the workflow until a reviewer approves, rejects, or requests revision. It is the primary mechanism for mixing human judgment into an otherwise automated pipeline.

When to use

Insert a Review node before any destructive or irreversible operation — deployments, data migrations, publishing content, submitting to external systems. You can also use it to check intermediate artifacts and ask for rework if quality is insufficient.

Two reviewer modes are supported:

• human — the reviewer decides through the HQ dashboard.
• minion — the reviewer is another minion that applies LLM judgment using the criteria prompt.

Configuration

Field	Description
reviewer_type	"human" or "minion".
reviewer_id	Minion UUID. Required when reviewer_type is "minion".
criteria	The review prompt. For minion reviews this is the LLM instruction; for human reviews it is guidance shown in the dashboard.
revision_target	Auto-populated when you draw a revision edge from the review node back to an ancestor. The node to rerun if revision is requested.

The revision target must be an ancestor of the review node — reachable forward through non-revision edges. Otherwise the revision loop cannot actually revisit the node you picked.

Behavior

1. When cascade reaches the Review node, it is inserted as waiting with review_status: review_pending and sits there.
2. The reviewer (human via the dashboard, or the assigned minion via its pending-reviews queue) submits a decision:
   • approved — cascade continues along the approved outgoing edge.
   • revision — the revision target is re-executed with revised context; the review node itself will reopen once that target’s re-run settles.
   • rejected — the graph halts at this node.

Validation rules

• review config block is required.
• reviewer_type is required.
• When reviewer_type === "minion", reviewer_id is required.
• criteria must be non-empty.
• revision_target must reference an existing node that is a forward-ancestor of the review node.
• The review node must have at least one approved outgoing edge (or an approved io-edge to the template Out marker, if inside a fan-out template). Otherwise the happy path cannot continue after approval.
• A revision edge must exist from the review node to the revision target.

Example

flowchart LR
    Draft["Skill: draft-post"] --> R{"Review"}
    R -->|approved| Publish["Skill: publish"]
    R -. revision .-> Draft

The revision edge (dotted) sends the flow back to draft-post when the reviewer asks for changes. When draft-post finishes again, the review reopens automatically.