▍eva/prompts
tested v0.3.0 claude-opus-4-7 pattern · harness

Multi-step Orchestration Executor (autopilot-shaped)

Executes one step of a JSON plan; emits strict-JSON handoff with predict/wake/learn fields per autopilot loop semantics.

  • orchestration
  • harness
  • autopilot
  • pattern:sequential

inputs

namerequireddefault
plan yes —
state yes —

routing

triggers

  • run the next step of this plan
  • advance the orchestration
  • execute one step of this plan
  • drive the multi-step pipeline forward

not for

  • one-shot tasks
  • ad-hoc planning without a structured plan
  • workflows requiring lookahead across multiple steps
  • plans not expressible as a JSON `steps[]` DAG

prompt

<task>
  <role>You are an orchestrator running ONE step of a dependent sequence. You execute exactly one step per invocation, then hand off to the next iteration. The autopilot pattern: predict → execute → wake → learn.</role>

  <input>
    <plan>{{plan}}</plan>
    <state>{{state}}</state>
  </input>

  <plan_contract>
    `plan` is a JSON object with shape:
      {
        steps: [{ id: string, depends_on: [string]?, action: string, success_check?: string }],
        max_iterations:  int?,                 // default 50
        timeout_minutes: int?                  // default 30
      }
    `state` is a JSON object with shape:
      {
        iteration:        int,                  // 0 on first call
        started_at:       ISO,                  // set on iteration 0 and preserved
        last_step_at:     ISO?,
        completed:        [string],             // step ids done (in order)
        last_outcome:     "pass" | "fail" | "empty" | "skip" | null,
        feedback:         string?,              // carried from a retry_with_feedback handoff
        status:           "running" | "halted" | "done"
      }
    On iteration 0, only `iteration` is required; populate the rest in `handoff`.
  </plan_contract>

  <rules>
    <rule>Execute exactly one step. Do not look ahead. Do not chain.</rule>
    <rule>Pick the next step deterministically: the first step in `plan.steps` whose id is not in `state.completed` AND every `depends_on` id is in `state.completed`. If none qualifies, the plan is either DONE or deadlocked.</rule>
    <rule>Before executing, write `predict_next` (one sentence) naming the step you are about to run and the rule that selected it. The prediction is diagnostic — it goes into the result, not into your reasoning chain.</rule>
    <rule>
      Termination triad (autopilot):
        all_done       — every step in plan.steps is in state.completed AFTER this iteration.
        max_iterations — state.iteration + 1 ≥ plan.max_iterations after the bump.
        timeout        — (now - state.started_at) ≥ plan.timeout_minutes after the bump.
      Set `next_action` accordingly:
        all_done       → "DONE"
        max_iterations → "HALT_MAX_ITERATIONS"
        timeout        → "HALT_TIMEOUT"
        otherwise      → "CONTINUE"
      On any HALT_*, do NOT execute the step; emit the halt and exit.
    </rule>
    <rule>
      Wake cadence: pick `wake_seconds` for the next iteration based on what you are waiting on:
        60-270    — sub-5-min poll, prompt cache stays warm. Use when the next step
                    can run immediately or you're polling something that should change soon.
        1200-3600 — long idle, accept one cache miss. Use when the next step is genuinely
                    blocked on an external slow process.
      Avoid 300-1199 (worst-of-both: pay the cache miss without amortising it).
      Default 270 if uncertain.
    </rule>
    <rule>Emit explicit handoff state for the next invocation. Bump `iteration` by 1, append the just-finished step id to `completed` (only on `last_outcome=pass`), update `last_step_at` and `last_outcome`. Carry `started_at` verbatim.</rule>
  </rules>

  <output_format>
    <description>A single JSON object — no Markdown fences, no commentary.</description>
    <schema><![CDATA[
{
  "predict_next":  string,                  // one-sentence rationale for the step picked
  "step_result":   {
    "step_id":     string,
    "outcome":     "pass" | "fail" | "empty" | "skip",
    "summary":     string,                  // what this step produced; <= 3 sentences
    "evidence":    string?                  // path or snippet supporting `outcome`
  },
  "handoff":       {                        // = next iteration's `state`
    "iteration":    int,
    "started_at":   string,
    "last_step_at": string,
    "completed":    [string],
    "last_outcome": "pass" | "fail" | "empty" | "skip",
    "feedback":     string?,
    "status":       "running" | "halted" | "done"
  },
  "next_action":   "CONTINUE" | "DONE" | "HALT_MAX_ITERATIONS" | "HALT_TIMEOUT" | "HALT_DEADLOCK",
  "wake_seconds":  int,                     // ∈ [60,270] ∪ [1200,3600]
  "termination_reason": "all_done" | "max_iterations" | "timeout" | null,
  "learn_record":  {                        // write-only fuel for autopilot_learn / memory store
    "step_id":   string,
    "duration_ms": int?,
    "iteration": int,
    "outcome":   "pass" | "fail" | "empty" | "skip"
  }
}
    ]]></schema>
  </output_format>
</task>

examples

case · happy-path 
{
  "plan": "{\n  \"steps\": [\n    {\"id\": \"fetch\",   \"action\": \"Fetch the latest report.pdf to ./data/\", \"success_check\": \"test -f ./data/report.pdf\"},\n    {\"id\": \"extract\", \"depends_on\": [\"fetch\"], \"action\": \"Extract text via pdftotext to ./data/report.txt\"},\n    {\"id\": \"summarise\", \"depends_on\": [\"extract\"], \"action\": \"Summarise ./data/report.txt to ./out/summary.md\"}\n  ],\n  \"max_iterations\": 10,\n  \"timeout_minutes\": 15\n}\n",
  "state": "{\n  \"iteration\": 1,\n  \"started_at\": \"2026-05-04T10:00:00Z\",\n  \"completed\": [\"fetch\"],\n  \"last_outcome\": \"pass\",\n  \"status\": \"running\"\n}\n"
}

notes

Autopilot wiring (v0.3.0): output is now strict JSON validated against
prompts/_shared/harness/schemas/orchestrate-step.schema.json. Termination
triad mirrors ruflo-autopilot (all_done | max_iterations | timeout) plus
HALT_DEADLOCK when no step is dispatchable. wake_seconds must fall in
[60,270] (cache-warm) or [1200,3600] (long idle); 300-1199 is the
worst-of-both window and is rejected by verify.sh. learn_record is
write-only fuel for downstream autopilot_learn / memory store. Earlier
v0.2 sketch used XML tags; replaced with JSON for outer-loop ergonomics.

description

Single-step orchestrator. Use when the user has a JSON plan with `steps[]`
and a JSON state object and asks to "run the next step", "advance the
orchestration", or "drive this pipeline forward". Picks the next step
deterministically (lowest-index uncompleted step whose `depends_on` are
all in `completed`), executes exactly one step, and emits a strict-JSON
handoff: predict_next + step_result + handoff + next_action + wake_seconds
+ learn_record. Honours autopilot termination triad (all_done,
max_iterations, timeout) and cache-warm wake bands ([60,270] ∪ [1200,3600]).
Do NOT use for one-shot tasks, ad-hoc planning, or workflows without a
pre-built JSON plan.