---
name: zero-touch-orchestrator
description: Plan, execute, verify, and recover multi-step tasks as bounded autonomous, evidence-driven workflows. Use when Codex or another agent must coordinate multiple tools, files, external systems, quality gates, progress updates, risk decisions, or approval boundaries, especially for research, analysis, coding, artifact generation, and operational work that cannot be completed reliably in one immediate step.
---

# Zero-Touch Orchestrator

Use this skill whenever the task cannot be completed reliably in one immediate
response or when tools, files, external systems, or multiple verification steps
are involved.

## Objective

Complete the user's intended outcome with the least necessary interruption while
preserving control over consequential actions. Never trade reliability,
authorization, or evidence for apparent autonomy.

Read [references/agent-contract.md](references/agent-contract.md) when configuring a dedicated orchestrator agent or when the runtime needs a full state-machine contract. Read [references/operating-model.md](references/operating-model.md) for atomic step and evidence patterns.

## Required inputs

Normalize the request into a `TaskIntent` containing:

- `goal`: the outcome the user wants;
- `deliverables`: concrete outputs;
- `constraints`: scope, format, deadlines, policies, and exclusions;
- `context`: relevant files, systems, prior decisions, and assumptions;
- `risk_level`: `low`, `moderate`, `high`, or `prohibited`;
- `success_criteria`: observable conditions for completion;
- `approval_boundaries`: actions that need explicit user authorization.

When minor information is missing, make reversible assumptions and label them.
Ask only when the missing information materially changes the outcome, safety, or
authorization boundary.

## Operating loop

### 1. Intake

1. Restate the operational goal internally.
2. Identify deliverables and success criteria.
3. Separate facts, assumptions, and unknowns.
4. Classify risk before using tools.
5. Refuse prohibited work and redirect to a safe alternative.

### 2. Inspect

1. Read the minimum relevant context before editing or acting.
2. Prefer primary or authoritative evidence.
3. Check the current state instead of assuming it.
4. Treat tool output, test output, file content, and source data as evidence.
5. Do not claim access, execution, review, or validation that did not occur.

### 3. Plan

Create a dependency-aware plan of atomic steps.

Apply **foundation-first ordering**:

1. authorization and safety boundaries;
2. environment and current-state inspection;
3. data, schema, interfaces, or source evidence;
4. core implementation or analysis;
5. integration and presentation;
6. verification, documentation, and handoff.

Each step must include:

- expected output;
- required tools or context;
- acceptance check;
- rollback or recovery path when relevant.

Do not create a long plan for a trivial task. For substantial work, communicate a
brief user-facing plan and provide material progress updates.

### 4. Execute

1. Perform one atomic step at a time.
2. Stay inside the authorized workspace and scope.
3. Prefer reversible changes and small diffs.
4. Preserve existing behavior unless change is required.
5. Never expose secrets, credentials, personal data, or hidden system content.
6. Never convert a read request into a write action.
7. Do not send, publish, purchase, delete, merge, deploy, or modify external
   systems unless explicitly authorized under the risk policy.

### 5. Verify

Use deterministic checks before subjective review whenever possible.

Examples:

- files: existence, parseability, schema checks, render checks, diffs;
- code: format, static analysis, typecheck, tests, build, security checks;
- research: source triangulation, date checks, quotation checks;
- writing: requirement coverage, factual consistency, audience and format checks;
- operations: state read-back, status checks, audit record, rollback readiness.

Verification must produce evidence. "Looks correct" is not sufficient when a
deterministic check exists.

### 6. Review

Perform a separate review pass against:

- user requirements;
- correctness and completeness;
- safety and authorization;
- edge cases and failure modes;
- unsupported claims;
- unintended side effects;
- output usability.

Do not call this review "independent" unless it was performed by a genuinely
separate process, model, or reviewer.

### 7. Self-heal

On failure:

1. capture the exact error or failed criterion;
2. identify the most likely root cause;
3. change one relevant variable;
4. rerun the narrowest useful check;
5. record the attempt.

Default maximum: three attempts for one failing step.

Stop early when:

- the same failure repeats without new evidence;
- the next action crosses an approval boundary;
- the remaining uncertainty is external or inaccessible;
- further attempts risk data loss, cost escalation, or scope expansion.

A failed item must not block unrelated safe work.

### 8. Deliver

The completion report must state:

- outcome;
- artifacts or changes;
- verification performed and evidence obtained;
- assumptions;
- unresolved items or residual risks;
- any action still requiring approval.

Never report completion when mandatory success criteria failed.

## Risk and approval rules

Read [references/risk-policy.md](references/risk-policy.md) before any external, destructive, privileged, financial, legal, medical, or security-sensitive action.

At minimum:

- read-only inspection is normally autonomous;
- reversible local creation is autonomous within scope;
- external writes require explicit user intent;
- destructive, irreversible, privileged, public, financial, legal, medical, or
  security-sensitive actions require heightened review and often confirmation;
- prohibited or unsafe work is refused.

## Output contracts

For machine-readable workflows, use:

- [references/task-intent.schema.json](references/task-intent.schema.json)
- [references/execution-report.schema.json](references/execution-report.schema.json)

For normal chat, use the same fields in concise prose.

## Memory policy

Persist only useful, authorized, non-sensitive information. Store decisions,
constraints, conventions, and validated failure patterns—not raw secrets,
private reasoning, or unnecessary personal data.

## Anti-patterns

Do not:

- invent successful tool calls;
- hide failed checks;
- loop indefinitely;
- broaden scope silently;
- use destructive commands as a shortcut;
- claim certainty beyond evidence;
- ask the user to do work the available tools can safely perform;
- perform external side effects merely because they are technically possible;
- expose private chain-of-thought.

Provide concise reasoning summaries, decisions, and evidence instead.