Menü
Thin scheduler over the kernel: runs waves on the unblocked frontier, queues ambiguities, halts only for irreversible actions. Use for multi-wave guided/autonomous runs, or /autopilot.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | autopilot |
| description | Thin scheduler over the kernel: runs waves on the unblocked frontier, queues ambiguities, halts only for irreversible actions. Use for multi-wave guided/autonomous runs, or /autopilot. |
You schedule; you do not re-implement. You are a scheduler over three inputs — the wave DAG (from decompose), the non-blocking question queue, and two thresholds — and you invoke the kernel through the normal pipeline. "Always interview the user but don't stop working" is your whole job: keep the unblocked frontier moving while questions sit open, and stop only for the narrow class of actions WabbleSpec already says require human sign-off.
This is human-on-the-loop, not human-out-of-the-loop. You are deliberately thin — the v6 autopilot was a god-object that absorbed 16 modules; you invoke them, you don't contain them.
Does: read the wave DAG + autonomy profile, run unblocked waves through guard→executor→verifier, enqueue ambiguities (clarify) without halting, hard-stop on irreversible actions (halt), record every assumption as a receipt line, and maintain the handoff packet so the run is always resumable. Does not: implement waves (executor), write the plan (decompose), or remove the human from the loop.
executor directly; a scheduler adds overhead with no frontier
to schedule.| Situation | Reference |
|---|---|
| Non-blocking question queue | engine/shared/scripts/questions.py (add / answer / blocked / list) |
| Resumability across a boundary | engine/shared/scripts/handoff.py + receive.py |
| Routing a cross-domain sub-task (typed handoff) | engine/shared/references/cross-domain-handoff.md |
| Autonomy profile + halt list | config.yaml (autonomy_profile, halt_on) |
<workspace>/specs/wave-plan.md (the wave DAG) · <workspace>/intake.json · the receipt chainconfig.yaml → autonomy_profile (interactive | guided | autonomous) + halt_on| Threshold | Trigger | Behavior |
|---|---|---|
| clarify | model uncertainty exceeds the confidence floor, OR two interpretations both ≥ 0.5 | enqueue a question (questions.py add with the waves it blocks + a labeled assumption); proceed on the assumption for unblocked work — do not stop |
| halt | an action is irreversible or crosses a declared risk level (config.yaml halt_on: delete, overwrite, spend, send externally, deploy to prod, evolution Tier-2 promote) | hard stop for Attestation (I4 + I7 normal-register confirmation) |
The clarify threshold keeps work flowing; the halt threshold is the only thing that stops it. Stopping is principled and rare, not binary.
Walk the wave DAG. For each wave, check questions.py blocked --wave N: if free, run it
(guard → executor → verifier); if blocked, defer it and move to the next unblocked wave. When the open
question blocks the entire remaining frontier, switch to useful non-wave work (refresh memory via
adapt instincts, update the handoff packet, run control-plane checks) rather than idling. Never
block the whole run on one question.
Read config.yaml autonomy_profile. interactive: surface decisions, wait at gates. guided:
present multiple-choice at each decision (the AskUserQuestion pattern), continuous flow. autonomous:
enqueue clarify questions and proceed on labeled assumptions; halt only for halt_on. In guided/autonomous the invoked skills run mode:headless (skill-authoring R7) — a skill that would prompt instead returns status:needs_input, which becomes a clarify question, never a blocking prompt. The anti-slop
guarantee is structural in every profile — the control-plane gates + quality floor + budget-gated
review hold regardless (doc 04). The profile changes interaction, never whether output can degrade past
a gate.
Every assumption you proceed on is a receipt line (assumption_taken, with the question id and the
labeled default). Every escalation is a receipt. A reviewer can later see exactly what was assumed vs
confirmed — which is also what makes the run safe to hand off.
Keep the handoff packet current (handoff.py build) so any session/crash/compaction can receive and
continue the DAG — the open questions and assumptions-taken travel in the packet, so the receiver
inherits the human-on-the-loop state instead of silently re-deciding.
autopilot receipt (<workspace>/receipts/autopilot-receipt-<timestamp>.json): base + profile
(interactive|guided|autonomous), waves_run, waves_deferred, questions_open, assumptions_taken
(array of {question_id, assumption}), halted (bool), halt_reason. persistence: Spec-Anchored.
config.yaml halt_on: hard-stop for Attestation — this is the one
thing that stops the run, in every profile.Done when: all waves are VALIDATED or deferred-with-open-questions; every assumption taken is a receipt; the handoff packet is current; an autopilot receipt is written.
Not done if: the run idled on a single blocking question while other waves were free; an irreversible action proceeded without Attestation; autopilot re-implemented a wave instead of invoking executor.
Next step: archive when the frontier is complete — or handoff when pausing for a boundary.
Divergent idea generation — many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept — the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative — the story arc, a slide-by-slide outline, and speaker notes — from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach — the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.