Codex Review Yolo

codex-review-yolo

Use this skill when the user wants an independent review from the locally installed codex CLI using the exact yolo profile. The artifact can be code, a doc, a plan, a rollout, or a completion state. This is the deliberate external-profile lane: its value is the pinned profile, clean process context, and captured final/event artifacts. An ordinary same-host Codex review should use a clean native child instead.

Read ../_shared/agent-orchestration-policy.md before dispatch. This skill's transport is intentionally external and its starting context is intentionally clean; it does not redefine the suite-wide transport or context policy.

This skill is intentionally narrow in mechanism, not in review subject. It teaches the invocation pattern, the prompt shape that makes codex read the named artifacts directly, and how to consume the verdict. It does not wrap every possible codex use case.

When to use

• The user says run codex -p yolo, names the yolo profile, or explicitly asks for an external Codex review with its captured receipt shape.
• The user has a substantial artifact or completion target and specifically wants the pinned yolo model/effort/tier or its external receipt contract before the next step.
• The user wants an adversarial external Codex audit and chooses the yolo profile as the independent reviewer.

When not to use

• The user wants codex to write code, not review it. This skill is review-only.
• The user wants an ordinary same-host Codex review and does not need the exact yolo profile or external receipts. Use a clean native reviewer under the shared policy.
• The user wants a quick yes/no on a one-line change — the setup cost exceeds the value.
• The user has not yet produced a concrete artifact or completion target to review. Don't spin up codex on vapor.
• codex is not installed on the host — which codex returns nothing. Stop and tell the user.

Non-negotiables

• Run codex with -p yolo explicitly. The profile carries gpt-6-astra + xhigh reasoning + fast service tier + danger-full-access sandbox. Any other profile changes the contract.
• Use codex exec (non-interactive), not codex (interactive TUI). You are orchestrating, not babysitting a session.
• Brief codex like a colleague who just walked in. It has no memory of your session. Name the review goal, work root, exact user-named artifacts or target paths, hard constraints, and the verdict contract.
• Apply $prompt-authoring to the actual populated review brief. Preserve the user's requested decision and approval bar. Do not turn the parent's diagnosis, preferred repair, or selected evidence path into the review conclusion; label a materially useful lead as challengeable.
• Require a structured verdict block at the end. Without it, codex drifts into narrative and you cannot act on the result.
• Treat the prompt examples as examples. Adapt the sections to the actual review objective instead of cargo-culting one review mode.
• Never pass secrets in the prompt. If codex needs FIGMA_ACCESS_TOKEN or similar, source .env into the codex env and instruct codex to read it from the environment.
• Run in the background for non-trivial audits. Codex at xhigh takes minutes. Normal audits often take 5+ minutes, and broad xhigh audits can reasonably take 20-40 minutes. Kick it off with background execution so you can keep working.
• Namespace every run's files. Derive one run-specific directory or prefix and keep the prompt, final output, and stream log inside it so concurrent runs on the same machine never clobber each other.
• Capture output to a file. The final-message file is the consumable deliverable; the stream log is diagnostic.
• Trust but verify. Codex can be wrong. Spot-check any blocking finding by reading the cited file before acting on it.
• Keep the external cost deliberate. A separate Codex process adds lifecycle, integration, and shared SQLite/WAL contention cost. Do not create parallel yolo reviewers merely as a speed reflex; choose the fanout that the concrete review benefit and current host state justify. This is a cost judgment, not a ban or fixed process limit.
• Keep external topology parent-owned. The review prompt lets Codex use its own native sub-agents and tells it not to start external agents. The parent verifies and integrates the verdict.
• Verify the review-only boundary from repository state. The yolo profile grants danger-full-access; a no-edit prompt is guidance, not an enforced capability boundary. Record the reviewed repository's status and diff before launch, compare them after the process exits, and account for any change before trusting or integrating the verdict.

First move

1. Confirm codex exists and inspect the standalone V2 yolo profile: YOLO_PROFILE="${CODEX_HOME:-$HOME/.codex}/yolo.config.toml"; which codex && test -f "$YOLO_PROFILE" && rg -n '^(model|model_reasoning_effort|service_tier|sandbox_mode)[[:space:]]*=' "$YOLO_PROFILE". Require gpt-6-astra, xhigh, fast, and danger-full-access.

2. Identify the exact review objective and user-named artifacts or target paths: commit SHA(s), branch, file paths, doc paths, commands to inspect current state, or plan phases. Write them down in the prompt.

3. Create a namespaced run directory once and reuse it for every file in that invocation. Example:

   REVIEW_SLUG="phase-b-completion"
   RUN_TS="$(date -u +%Y%m%dT%H%M%SZ)"
   RUN_DIR="$(mktemp -d "/tmp/codex-review-${REVIEW_SLUG}-${RUN_TS}-XXXXXX")"
   PROMPT_PATH="$RUN_DIR/prompt.md"
   FINAL_PATH="$RUN_DIR/final.txt"
   STREAM_PATH="$RUN_DIR/stream.log"
   

4. If the review needs API tokens, confirm .env has them and plan to set -a; source .env; set +a before invoking.

5. Draft the prompt to $PROMPT_PATH and apply $prompt-authoring to the populated brief before launch (never inline — prompts get long and multi-line is inevitable).

6. Note that this dispatch is a new clean external review with no continuation handle. Tell the reviewer not to edit files and not to start external agents; its own native sub-agents are fine. Record the current repository status and diff before launch; this is required because the profile has danger-full-access even though the role is review-only.

7. Invoke via codex exec -p yolo -C <repo-root> --json -o "$FINAL_PATH" < "$PROMPT_PATH" > "$STREAM_PATH" 2>&1, in background.

8. Continue other work while Codex reasons; when it completes, compare the repository status and diff with the pre-launch snapshot, account for any change, then read $FINAL_PATH, verify important claims, and relay the verdict to the user.

Workflow

1. Shape the prompt

A good prompt for codex review preserves independent judgment and has these sections in this order:

1. Role + posture. One line. "You are auditing X. Be skeptical. If the work is wrong, say so plainly."
2. Review objective and work root. State what approval means for this review and where codex should run.
3. User-named artifacts or target paths. Point codex at the concrete artifacts the user named.
4. Verdict block requirement. Demand a specific footer format so the result is machine-ish-readable.

See references/prompt-template.md for the full skeleton.

2. Invoke codex

Example pattern, adjust the repo root, review slug, and paths:

REVIEW_SLUG="phase-b-completion"
REPO_ROOT="$(pwd)"
RUN_TS="$(date -u +%Y%m%dT%H%M%SZ)"
RUN_DIR="$(mktemp -d "/tmp/codex-review-${REVIEW_SLUG}-${RUN_TS}-XXXXXX")"
PROMPT_PATH="$RUN_DIR/prompt.md"
FINAL_PATH="$RUN_DIR/final.txt"
STREAM_PATH="$RUN_DIR/stream.log"

# If the audit needs API tokens, source them into the codex environment.
if [ -f "$REPO_ROOT/.env" ]; then set -a; source "$REPO_ROOT/.env"; set +a; fi

codex exec -p yolo \
  -C "$REPO_ROOT" \
  --json \
  -o "$FINAL_PATH" \
  < "$PROMPT_PATH" \
  > "$STREAM_PATH" 2>&1

Key flags:

• -p yolo — the profile. Non-negotiable.
• -C <dir> — the working root. Use the repo root (or the submodule root if that's the reviewed unit).
• --json — writes live Codex event JSONL to stream.log while the child works.
• -o <file> — writes the final assistant message to this file. This is what you Read at the end.
• < prompt.md — feeds the prompt via stdin. Keeps command lines sane and lets you iterate on prompts in a file.
• > stream.log 2>&1 — captures the full event stream. Use for diagnosis if codex errored or went sideways.
• $RUN_DIR/... — keeps one review invocation's artifacts isolated from every other invocation.

Run via the shell's background support for any audit you expect to take more than ~30 seconds. Poll stream.log and process status every few minutes, not every few seconds. The final-message file is created when codex exits.

3. Consume the verdict

When codex finishes:

1. Compare the reviewed repository's status and diff with the pre-launch snapshot. Treat unexplained changes as a failed review-only boundary and do not hide, revert, or absorb them silently.
2. Read the run's final output file, e.g. $FINAL_PATH.
3. Locate the VERDICT: / REQUIRED REPAIRS: / OBSERVATIONS: footer.
4. Relay findings to the user. Do not blindly trust — spot-check any required repair claim against the actual file before acting.
5. If codex found nothing actionable, say so directly. Don't manufacture issues to justify the invocation.

Output expectations

• A short summary to the user: what codex's verdict was, what blocking issues it found (if any), and whether you agree after verification.
• The full final-output file stays on disk in its namespaced run directory — mention the path so the user can read the full review if they want.
• Never claim codex said something it didn't. If the output is ambiguous, say "codex was ambiguous on X" and ask the user how to proceed.

Reference map

• references/prompt-template.md — full skeleton for the review prompt, plus clearly-labeled examples for diff review, implementation completion, plan review, and cross-repo review
• references/verdict-contract.md — the exact footer format and how to parse it
• references/troubleshooting.md — common failure modes (no output, rate-limit, truncation, codex can't find files)