Context
Context holds the goal, the declared inputs, accepted agent outputs, command facts and stage outcomes. Conditions and prompts read it by dotted path, and context.pr.state and pr.state read the same value.
Inputs and defaults
Section titled “Inputs and defaults”inputs="work,notes?" requires work and makes notes optional. Names are identifiers and cannot occupy engine or probe namespaces. goal is built in; do not redeclare it. Starting a run requires a goal and all required inputs, and rejects undeclared inputs. An absent optional value renders empty.
defaults supplies comma-separated literal assignments, for example defaults="goal='Review this project',notes='Owner''s notes'". Double a single quote inside a value. Defaults may name goal and declared inputs only. Explicit run input replaces a default.
Inputs are copied into context when the run starts, so {{ context.work }} can later change while {{ inputs.work }} keeps the original. Loop restart restores the original inputs.
Agent outputs
Section titled “Agent outputs”An agent declares comma-separated name:kind entries and finishes with a JSON object under context_updates, for example:
{"context_updates":{"verdict":"pass","findings":[]}}That response fits outputs="verdict:choice,findings:json" when the outgoing edges declare the pass choice. The engine supplies the exact output contract to the agent and accepts only declared keys with matching types.
| Kind | Contract |
|---|---|
choice |
One of the literals inferred from the node’s outgoing choice conditions. |
text |
A non-empty string. |
json |
A JSON object or array, stored as JSON text in context. Scalar values are rejected. |
work |
A validated current-work scope with a supported tagged variant. |
Work scopes are Leaf with a ticket URL and a Parent or None parent, Hierarchy with a ticket and a hierarchy, Candidate with a description and evidence, or Goal with goal text. Required descriptive values are non-empty. Ticket URLs use HTTP or HTTPS, and a leaf cannot be its own parent. {{ current_work }} renders the saved scope for shared delivery prompts. A missing scope does not silently fall back to a previous ticket.
Malformed output triggers up to two correction turns in the same session. If correction fails, the node fails and follows failure routing. Context changes only after acceptance. The final prose stays available as {{ context.response.<node> }}.
Command facts
Section titled “Command facts”A script node writes exactly the dotted names in its facts declaration, plus <node>.failed. It cannot overwrite built-in probe facts or reserved failure paths.
A probe node writes per-folder facts under the folder name, such as web.pr.raw. Selected PR and thread facts also roll up, including pr.state and threads.unresolved. Diff and worktree probe facts stay per-folder. A worktree removal node separately writes run-wide worktree.clean and worktree.status.
PR routing prioritises MERGED, CLOSED, CONFLICTS, CI_FAILED, CHANGES_REQUIRED, then WAITING. Across several repositories the rollup takes the worst state in the order CLOSED, CONFLICTS, CI_FAILED, CHANGES_REQUIRED, WAITING, MERGED, and reports MERGED only when every observed repository has merged. A PR that merges or closes while the probe reads it is observed once more and routed as MERGED or CLOSED instead of failing the probe. Raw PR evidence gives repair prompts the check and feedback details.
Stage outcomes
Section titled “Stage outcomes”The engine writes outcome as succeeded or failed after each stage, with failure_reason empty on success. Both are readable from conditions and prompts.
Availability
Section titled “Availability”The validator checks that a value is produced on every path leading to the node that reads it. A branch cannot read a sibling’s outputs. After the join, read branch values through parallel.results, whose entries carry node, outcome, failure_reason and context. Numeric dotted segments address them, for example parallel.results.0.context.assessment; in templates the index is quoted.
See conditionals for how conditions consume these values and template variables for how prompts read them.
Inline attribute expressions on this page are syntax fragments. Use the complete attribute wrapper and the linked runnable examples as validation contexts.