Boundary rules
- An ordered block enforces local order, not global lock-in. The user can trigger a different skill mid-block (interrupt). The block pauses and, if the user chooses to resume, continues at the same step when the interrupt completes.
-
@skill.<name>guarantees parent resumes; user-initiated interrupt does not. An@skill.<name>reference is a structured invocation with guaranteed return. An interrupt is a user changing topic; the original skill stays on the stack but may not be revisited. -
Prose and ordered blocks coexist. Prose references a block via
@block.<block_id>. The orchestrator enters the block, runs it, and returns to prose on the same turn when leftover work remains. -
if:markers are prompt-level, not execution-level. They change what the LLM sees, not what the orchestrator tracks. Each marker scopes the one paragraph beneath it, so every case reads as its ownif:. -
tool_constraintsare always enforced. Whether the LLM or an ordered-blockexecute_tool:step attempts the call,requires:and any confirmation gate are checked before the function runs. -
Every gate fails closed. When a
requires:orif:condition does not hold, the tool stays hidden and the paragraph stays out of the prompt. Withholding is the safe direction, so it is also what happens when a condition cannot be evaluated. -
Values can satisfy upcoming
collect:steps early. A user who volunteers several answers at once lets the block advance past each already-satisfiedcollect:step in one turn, unless the step setsask_before_filling: true. Order is still preserved: the block never runs a later step before an unsatisfied earlier one.
Conditions
Everyrequires:, if:, ordered-block step complete_when:, utter: when:,
and next: condition is a string expression in one grammar. Skill-level
frontmatter complete_when is different: it must be a mapping with
condition (one of those expression strings) and/or criteria (sentences in
natural language).
See Conditions and
skill.md complete_when.