consult-codex

Name: consult-codex
Author: tobihagemann

3installs29forks

How to install consult-codex?

tobihagemann/turbo/consult-codex

$npx -y skills add tobihagemann/turbo --skill consult-codex

Installs into the current project.

Summary

Multi-turn consultation with Codex CLI for second opinions, brainstorming, or collaborative problem-solving. Use when the user asks to \"consult codex\", \"ask codex\", \"get codex's opinion\", \"brainstorm with codex\", \"discuss with codex\", or \"chat with codex\".

Files · 1

View on GitHub

SKILL.md

1	# Consult Codex
2
3	Multi-turn consultation with Codex CLI. Maintains a conversation across multiple turns using session persistence, unlike single-shot `/codex-exec`.
4
5	## Step 1: Gather Context
6
7	Identify the 2-5 files most relevant to the problem. Formulate a clear, specific question. Include what has been tried and relevant constraints.
8
9	## Step 2: Start Session
10
11	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 or reading files outside the workspace.
12
13	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.
14
15	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.
16
17	Generate a random session tag at the start to keep files unique for parallel use:
18
19	```bash
20	CODEX_TAG=$(head -c 4 /dev/urandom \| xxd -p) && mkdir -p .turbo/codex
21	codex exec -s read-only -o ".turbo/codex/$CODEX_TAG.txt" "<question with full context>" < /dev/null
22	```
23
24	### Prompt Shaping
25
26	Structure the question using XML tags for clearer Codex responses:
27
28	- `<task>`: The concrete question and relevant context.
29	- `<compact_output_contract>`: Desired output shape and brevity requirements.
30	- `<structured_output_contract>`: Same purpose but for structured/schema responses.
31	- `<grounding_rules>`: When claims must be evidence-based (review, research, root-cause analysis).
32	- `<dig_deeper_nudge>`: Push past surface-level findings to check for second-order failures.
33	- `<verification_loop>`: When correctness matters — ask Codex to verify before finalizing.
34
35	Example prompt for a diagnosis question:
36
37	```
38	<task>Diagnose why the auth middleware rejects valid tokens after the session refactor.</task>
39	<compact_output_contract>Return: (1) most likely root cause, (2) evidence, (3) smallest safe next step.</compact_output_contract>
40	<grounding_rules>Ground every claim in the provided context or tool outputs. Label hypotheses explicitly.</grounding_rules>
41	```
42
43	For correctness-critical questions, add `<verification_loop>` asking Codex to verify its answer before finalizing.
44
45	Keep prompts compact, with tight output contracts. One clear task per Codex turn.
46
47	For long context that won't fit inline, write a context file and pipe it via stdin. The prompt stays as the argument, context pipes in as `<stdin>` automatically:
48
49	```bash
50	cat > ".turbo/codex/$CODEX_TAG-ctx.txt" << 'EOF'
51	<long context here>
52	EOF
53	cat ".turbo/codex/$CODEX_TAG-ctx.txt" \| codex exec -s read-only -o ".turbo/codex/$CODEX_TAG.txt" "<question>"
54	```
55
56	Parse the `session id:` line from the CLI output. This UUID is needed for follow-up turns.
57
58	The `session id:` line appears only in stdout chrome, never in the `-o` file. When a follow-up turn may be needed, do not pipe `codex exec` stdout through `head`/`tail` or any filter that drops early lines — that silently discards the session id and makes `resume` impossible. If stdout must be truncated, also `grep` for `session id:` so the id is always retained.
59
60	Run via the Bash tool as a foreground call (`timeout: 600000`, the Bash maximum; do not set `run_in_background`) per turn. A larger timeout is not honored: the harness backgrounds the call immediately and hard-kills codex at 600s, truncating its output. If a consult outlives a valid timeout, the harness force-backgrounds it and the run continues to completion — recover the answer by reading the `-o` file, then reading it again once the `<task-notification>` reports completion. For a backgrounded run the `session id:` is in the task's stdout output file rather than the immediate tool result, so `grep` that file for it when a follow-up turn is needed. Never wait with `Monitor`, and never return the task ID or an interim file snapshot as the result — each is a false-empty return.
61
62	## Step 3: Read and Evaluate Response
63
64	The `-o` file contains only Codex's response (cleaner than stdout, which includes CLI chrome and tool-use logs). Read from `.turbo/codex/$CODEX_TAG.txt`. If the output is too large for the Read tool, read stdout from the Bash tool result instead.
65
66	Assess whether:
67	- The answer is sufficient and actionable
68	- Follow-up questions woul

People who liked this also viewed

6 picks

Type

consult-codex

3installs29forks

View on GitHub

How to install consult-codex?

tobihagemann/turbo/consult-codex

$npx -y skills add tobihagemann/turbo --skill consult-codex

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Consult Codex
2
3	Multi-turn consultation with Codex CLI. Maintains a conversation across multiple turns using session persistence, unlike single-shot `/codex-exec`.
4
5	## Step 1: Gather Context
6
7	Identify the 2-5 files most relevant to the problem. Formulate a clear, specific question. Include what has been tried and relevant constraints.
8
9	## Step 2: Start Session
10
11	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 or reading files outside the workspace.
12
13	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.
14
15	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.
16
17	Generate a random session tag at the start to keep files unique for parallel use:
18
19	```bash
20	CODEX_TAG=$(head -c 4 /dev/urandom \| xxd -p) && mkdir -p .turbo/codex
21	codex exec -s read-only -o ".turbo/codex/$CODEX_TAG.txt" "<question with full context>" < /dev/null
22	```
23
24	### Prompt Shaping
25
26	Structure the question using XML tags for clearer Codex responses:
27
28	- `<task>`: The concrete question and relevant context.
29	- `<compact_output_contract>`: Desired output shape and brevity requirements.
30	- `<structured_output_contract>`: Same purpose but for structured/schema responses.
31	- `<grounding_rules>`: When claims must be evidence-based (review, research, root-cause analysis).
32	- `<dig_deeper_nudge>`: Push past surface-level findings to check for second-order failures.
33	- `<verification_loop>`: When correctness matters — ask Codex to verify before finalizing.
34
35	Example prompt for a diagnosis question:
36
37	```
38	<task>Diagnose why the auth middleware rejects valid tokens after the session refactor.</task>
39	<compact_output_contract>Return: (1) most likely root cause, (2) evidence, (3) smallest safe next step.</compact_output_contract>
40	<grounding_rules>Ground every claim in the provided context or tool outputs. Label hypotheses explicitly.</grounding_rules>
41	```
42
43	For correctness-critical questions, add `<verification_loop>` asking Codex to verify its answer before finalizing.
44
45	Keep prompts compact, with tight output contracts. One clear task per Codex turn.
46
47	For long context that won't fit inline, write a context file and pipe it via stdin. The prompt stays as the argument, context pipes in as `<stdin>` automatically:
48
49	```bash
50	cat > ".turbo/codex/$CODEX_TAG-ctx.txt" << 'EOF'
51	<long context here>
52	EOF
53	cat ".turbo/codex/$CODEX_TAG-ctx.txt" \| codex exec -s read-only -o ".turbo/codex/$CODEX_TAG.txt" "<question>"
54	```
55
56	Parse the `session id:` line from the CLI output. This UUID is needed for follow-up turns.
57
58	The `session id:` line appears only in stdout chrome, never in the `-o` file. When a follow-up turn may be needed, do not pipe `codex exec` stdout through `head`/`tail` or any filter that drops early lines — that silently discards the session id and makes `resume` impossible. If stdout must be truncated, also `grep` for `session id:` so the id is always retained.
59
60	Run via the Bash tool as a foreground call (`timeout: 600000`, the Bash maximum; do not set `run_in_background`) per turn. A larger timeout is not honored: the harness backgrounds the call immediately and hard-kills codex at 600s, truncating its output. If a consult outlives a valid timeout, the harness force-backgrounds it and the run continues to completion — recover the answer by reading the `-o` file, then reading it again once the `<task-notification>` reports completion. For a backgrounded run the `session id:` is in the task's stdout output file rather than the immediate tool result, so `grep` that file for it when a follow-up turn is needed. Never wait with `Monitor`, and never return the task ID or an interim file snapshot as the result — each is a false-empty return.
61
62	## Step 3: Read and Evaluate Response
63
64	The `-o` file contains only Codex's response (cleaner than stdout, which includes CLI chrome and tool-use logs). Read from `.turbo/codex/$CODEX_TAG.txt`. If the output is too large for the Read tool, read stdout from the Bash tool result instead.
65
66	Assess whether:
67	- The answer is sufficient and actionable
68	- Follow-up questions woul

People who liked this also viewed

6 picks

Type