codex-multi-cli-orchestrator

Files (2)

• SKILL.md
• openclaw-models.md · references/

SKILL.md (first lines)

# Codex Multi-CLI Orchestrator

## Goal

Codex App + GPT 5.4 is the primary planner, reviewer, and acceptance gate.

Default operating mode:

```text
analyze
  -> plan
  -> assign the shortest clear prompt to each worker
  -> collect worker outputs
  -> verify against real repo/runtime state
  -> if done, stop this round
  -> if failed or incomplete, re-dispatch the next smallest task
  -> if all worker attempts fail, fallback to Codex direct execution
```

Use this skill when Codex should:

- break one objective into smaller tasks
- decide which external CLI should execute each task
- keep risky decisions centralized in Codex
- use cheaper or specialized models for low-risk execution

Codex remains the source of truth. Other CLIs are workers.

## Target Delivery Chain

Use this deployment chain as the default control flow:

```text
GitHub Actions / ansible
  -> Docker Compose / SSH deploy
  -> Docker Host
     - APISIX (standalone)
     - Caddy
     - App containers
  -> Cloudflare DNS
```

Interpretation:

- `GitHub Actions` builds and prepares release inputs
- `ansible` is the only deploy actuator
- `Docker Compose` is the only app runtime path
- `APISIX` and `Caddy` are host-side traffic components
- `Cloudflare DNS` is last-step cutover only

## Command Role Split

Use Codex App + GPT 5.4 for:

- task decomposition
- risk review
- deciding execution order
- checking whether a worker result is trustworthy
- final migration readiness judgment

Use `ollama` for:

- cheap local or cloud-backed review passes
- smoke-check prompts
- short fix proposals
- repeated verification loops
- APISIX / Caddy / compose file review

Use `opencode` for:

- repo-aware coding or editing tasks when you want a second coding agent
- low-risk implementation or mechanical refactors
- bounded file changes with explicit output format
- ansible role or workflow edits within a fixed path boundary

Use `gemini` for:

- short read-only audits
- alternative diagnosis
- summarization of current state
- release checklist cross-checks and command review

Do not let worker CLIs make final production decisions.

## Default Execution Contract

For future execution rounds, use this contract unless the user overrides it:

1. Codex does not execute worker CLIs on the user's behalf by default.
2. Codex only:
   - analyzes the current objective
   - creates the plan
   - assigns the shortest clear prompt to each worker
   - collects and summarizes worker outputs provided by the user
   - decides whether the round is complete or needs re-dispatch
3. The user executes:
   - `scripts/orchestration/run_worker.sh opencode "<prompt>"`
   - `scripts/orchestration/run_worker.sh ollama "<prompt>"`
   - `scripts/orchestration/run_worker.sh gemini "<prompt>"`
4. Codex remains the only final acceptance gate.
5. If all worker attempts fail, or all worker results are incomplete or untrustworthy, Codex may execute the smallest necessary direct validation or implementation step itself.

Use this exact round structure:

1. Analyze
2. Plan
3. Worker prompt assignment
4. User executes workers
5. Codex summarizes worker results
6. Codex checks whether completion criteria are met
7. If complete, end the round
8. If failed or incomplete, dispatch the next smallest follow-up prompts
9. If all worker paths fail, fallback to Codex direct execution for the smallest necessary step

## Model Selection

Read [references/openclaw-models.md](references/openclaw-models.md) before dispatching.
Use [../orchestration-run-task/SKILL.md](../orchestration-run-task/SKILL.md) when turning a subtask into a concrete `run_worker.sh` command.

From haitaopanhq/.github, Apache-2.0.

More from haitaopanhq/.github