/consult-codex

name: consult-codex
description: "Multi-turn consultation with Codex CLI for second opinions or brainstorming. Use when the user asks to \"consult codex\", \"ask codex\", \"get codex's opinion\", or \"brainstorm with codex\"."

Consult Codex

Multi-turn consultation with Codex CLI. Maintains a conversation across multiple turns using session persistence.

Step 1: Gather Context

Identify the 2-5 files most relevant to the problem. Formulate a clear, specific question. Include what has been tried and relevant constraints.

Step 2: Start Session

Run `codex exec` with `-o` to capture the response cleanly. Default to `-s read-only` for safety. Use `-s workspace-write` when the consultation requires running code, inspecting an artifact passed by path, or reading files outside the workspace, and tell Codex to keep any scratch files it writes under `.turbo/`. Pass the same `-s` value on every resume turn of the consultation: a resume turn takes its sandbox from its own command line, and without the flag it falls back to the codex config, where a trusted project runs workspace-write.

Omit `-m`, leaving the consultation on codex's configured model. When the user named a model for this consultation, add `-m <model>` to every `codex exec` command in this skill, resume turns included, and pass the name verbatim.

**All `codex` Bash calls require `dangerouslyDisableSandbox: true`** (network access to OpenAI API). Use `.turbo/` as the temp directory — it is in the working directory (sandbox-writable), gitignored, and avoids `$TMPDIR` path mismatches between sandbox and non-sandbox mode.

**Every `codex exec` invocation requires `--skip-git-repo-check`**, resume turns included. Outside a git repository codex aborts before doing any work, printing `Not inside a trusted directory and --skip-git-repo-check was not specified.`, and never writes the `-o` file.

**Non-piped `codex exec` invocations require `< /dev/null`** to avoid hanging on stdin. Codex reads from stdin whenever stdin is non-TTY, and in subprocess contexts the harness leaves stdin connected to a pipe that never EOFs — codex blocks forever, printing only `Reading additional input from stdin...`. The piped form (`cat file | codex exec "..."`) is safe — `cat` closes the pipe after the file.

Generate a random session tag at the start to keep files unique for parallel use, and print the absolute path prefix it produces:

CODEX_TAG=$(head -c 4 /dev/urandom | xxd -p) && mkdir -p "$PWD/.turbo/codex" && echo "$PWD/.turbo/codex/$CODEX_TAG"

Substitute the printed value for `<prefix>` in every later command of this consultation. Shell variables do not survive between Bash tool calls, and an earlier `cd` in a compound command leaves the session in a different directory, so a relative path resolves against that directory instead.

Number the `-o` file by turn — `<prefix>-1.txt` for the first, `<prefix>-2.txt` for the next, and so on. A turn that reuses the previous turn's path finds that turn's complete answer waiting there, so a read landing before the current turn finishes returns the wrong answer with nothing to mark it as stale.

codex exec --skip-git-repo-check -s read-only -o "<prefix>-1.txt" "<question>" < /dev/null

Prompt Shaping

Structure the question using XML tags for clearer Codex responses:

• `<task>`: The concrete question and relevant context.
• `<compact_output_contract>`: Desired output shape and brevity requirements.
• `<structured_output_contract>`: Same purpose but for structured/schema responses.
• `<grounding_rules>`: When claims must be evidence-based (review, research, root-cause analysis).
• `<dig_deeper_nudge>`: Push past surface-level findings to check for second-order failures.
• `<verification_loop>`: When correctness matters — ask Codex to verify before finalizing.
• `<merit_only>`: When a recommendation is wanted, bar answers that appeal to scope.
• `<verdict_line>`: When the consultation runs until Codex approves, fix the line that ends every response and terminates the loop.
• `<style_constraints>`: When the answer must follow a house style, name the shapes that style forbids.

Example prompt for a diagnosis question:

<task>Diagnose why the auth middleware rejects valid tokens after the session refactor.</task>
<compact_output_contract>Return: (1) most likely root cause, (2) evidence, (3) smallest safe next step.</compact_output_contract>
<grounding_rules>Ground every claim in the provided context or tool outputs. Label hypotheses explicitly.</grounding_rules>

For correctness-critical questions, add `<verification_loop>` asking Codex to verify its answer before finalizing.

When Codex must judge claims against a source, state in `<grounding_rules>` whether the material provided is the complete source or an excerpt. When a verdict can turn on something being absent, provide the complete relevant sections: given an excerpt, Codex reports what the excerpt leaves out as unverifiable or missing. Pass the complete source, or its path for Codex to read, whenever it fits. When an excerpt is unavoidable, confirm before running that every passage the claims under judgment rest on made it into the material provided.

When the consultation concerns an artifact Codex can inspect itself, pass its path and let Codex choose how to inspect it, rather than attaching excerpts or other material extracted from it.

When a recommendation is wanted, add `<merit_only>`: state that "out of scope" or "leave it alone" is not an acceptable argument on its own, and that recommending no change must be justified on technical merit. Pair it with `<compact_output_contract>` demanding one pick per decision, the reasoning, and the strongest counterargument to that pick, with hedging across options ruled out. When the question lists options, state in that contract that the pick may be a named alternative outside the list when it is sounder than every listed option.

When the consultation runs unti