메뉴
Use when spawning, steering, or auditing Agent Orchestrator workers, especially when the user specifies exact AO parameters such as codex, runtime, project, claim-pr, or PR targets.
Use when proving, rejecting, or deleting backend adjustment registry entries with real LLM evidence and independent disabled-adjustment worktrees.
Checklist for dispatching AO workers — python venv, commit discipline, branch drift, and post-push CodeRabbit verification
Use when dispatching work through the Hermes gateway with /claw, especially when the task may resolve slash commands or hand off into AO worker orchestration.
Dispatch independent adversarial reviews for ZFC, ZFC leveling, and root-cause-first without duplicating their standards.
Run the Dark Factory DOT pipeline runner against a goal. Slash command: /factory. Implements StrongDM's Attractor pattern as an external Python runner — .dot files are the versioned artifact, sealed holdouts live in a separate repo, every step is recorded to CXDB, and the Healer clusters failures into diagnoses. Use when you want the goal_harness idea executed as a reproducible external pipeline instead of in-Claude subagent dispatch.
Run disk usage analysis and cleanup preview on the local Mac. Always validate snapshot coverage before quoting. Never delete without user approval.
| name | ao-operator-discipline |
| description | Use when spawning, steering, or auditing Agent Orchestrator workers, especially when the user specifies exact AO parameters such as codex, runtime, project, claim-pr, or PR targets. |
AO parameters are commitments. If the user asks for Codex workers, PR-specific workers, a certain runtime, or a specific project, you must pass those parameters explicitly and then verify that AO actually honored them.
The failure pattern this skill prevents is simple: a worker exists, but it is the wrong worker.
Use this skill when:
aoao spawn, ao send, ao session claim-pr, or ao statusDo not use this skill for tiny read-only checks like a one-off ao status.
Before evaluating any --agent value, read the active AO config:
head -20 ~/.hermes/agent-orchestrator.yaml # check defaults.agent and installed plugins
--agent values are resolved against the config, not against AO package plugin directories. If <X> in --agent <X> is not a well-known CLI name (codex, claude, claude-code, gemini), look it up in the config before concluding it's unsupported.
Known shorthands on this machine:
agy / antigravity → ~/.local/bin/agy (Google Antigravity / Gemini CLI) — this is the default agentminimax → claude CLI + MiniMax API redirectwafer → claude CLI + Wafer API redirectNever scan packages/agent-*/ as a substitute for reading the config.
Treat user-specified AO parameters as hard requirements:
--agent--runtime--project--claim-prNever rely on AO defaults when the user asked for something specific.
After every ao spawn, verify the spawned session before trusting it.
If the verified session does not match the request, kill or replace it. Do not proceed with the wrong worker.
For Codex workers, use an explicit agent override:
unset GITHUB_TOKEN
ao spawn --project <project> --agent codex --claim-pr <pr> "<task>"
If the user specified another runtime too, pass it explicitly:
unset GITHUB_TOKEN
ao spawn --project <project> --agent codex --runtime tmux --claim-pr <pr> "<task>"
Immediately after spawn, inspect the session file under ~/.agent-orchestrator/.../sessions/<session> and confirm:
agent=codex when Codex was requestedpr=<expected PR URL> when a PR was specifiedruntimeHandle.data.launchCommand contains the expected CLI and modelExample verification:
python3 - <<'PY'
from pathlib import Path
p = Path("~/.agent-orchestrator/<hash>-<project>/sessions/<session>").expanduser()
print(p.read_text())
PY
For Codex requests, expected launch shape:
agent=codex
launchCommand=...'codex' ... --model 'gpt-5.4' ...
If you see gemini, claude, MiniMax, or another unexpected launcher, the spawn is wrong.
After verification, check the tmux pane with at least 20 lines:
tmux capture-pane -pt <tmux-session>:0.0 -S -40
Look for:
Do not accept a welcome screen, generic prompt, or stale queued message as evidence the worker is on task.
If a worker was launched with the wrong agent or runtime:
ao session kill <session>
ao spawn --project <project> --agent codex --claim-pr <pr> "<task>"
Then re-run the verification checklist.
--agent codex because “the config probably defaults correctly”ao status only, instead of session metadataDo not report success on AO setup until you have all of: