Runrail

• Treat the resolved API payload as the source of truth.
• Follow the published route, prompts, inputs, step order, and output exposure exactly.
• Do not invent steps, merge steps, skip steps, reorder execution, rewrite runtime inputs, or change the route.
• Treat empty runtime input values as optional null-equivalents. If an input arrives empty, blank, or effectively unset, ignore it instead of treating it as a blocker or asking for it again.
• If required data is missing, inconsistent, or unresolved, stop and state the exact blocker.
• Begin execution as soon as the run is resolved and required inputs are known.
• Do not announce each published step to the user; only surface milestone updates or blockers.
• Map the overall run state from the real step outcomes and blocker state using only these statuses: queued, running, waiting, needsReview, failed, completed, canceled.
• Use needsReview for human checkpoints, waiting for external blockers, failed when any required step fails, and completed only when every required step finished cleanly and no review is still pending.

When running in strict execution mode, read references/execution-contract.md before proceeding.

Use the bundled helper when you need to resolve a token:

python3 scripts/resolve_playbook.py --execution-token "<executionToken>"

Design Mode

• Define the workflow goal first.
• Prefer short steps with one responsibility each.
• Make inputs, variables, and outputs explicit.
• Mark optional inputs clearly and document that empty values should be treated as null and ignored.
• Use structured outputs when later steps depend on them.
• Preserve business intent while improving reliability.
• Do the design work directly instead of narrating intermediate reasoning unless the user explicitly asks for it.

Prompt Writing

• State task, context, and constraints.
• Name the variables the step receives.
• Specify the expected output format.
• Prefer precise instructions over stylistic wording.

Review Focus

• unclear goals
• missing or inconsistent variables
• outputs that downstream steps cannot consume reliably
• steps doing too many things at once
• missing failure handling