Codex Prompting Skill

What this skill is for

Use this when the request is any of the following:

• "send to codex"
• "prompt codex"
• "use codex"
• "ask codex"
• "delegate to codex"
• "delegate this to codex"
• "run this in codex"
• "run in codex"
• "handoff to codex"
• "handoff this to codex"
• "codex this"

The job is to produce a high-signal Codex request that gets directly executed with minimal ambiguity.

Required model default

• Codex tasks must set model to gpt-5.4 when unspecified.
• Use an explicit model override only when user explicitly requests another.

Local runtime defaults (Panda)

• Global defaults live in ~/.codex/config.toml:
  • approval_policy = "never"
  • sandbox_mode = "danger-full-access"
  • allow_login_shell = false
• Hard safety rails live in ~/.codex/rules/safety.rules:
  • forbid force/mirror pushes
  • forbid obvious filesystem root wipe commands
  • forbid disk-destruction primitives (diskutil eraseDisk, mkfs, dd)
• pi-tools codex extension defaults to:
  • --ask-for-approval never
  • --sandbox danger-full-access
  • full_auto = false (opt-in legacy mode)
• Expected behavior:
  • normal git commit and git push should run without permission friction
  • blocked commands fail fast with explicit forbidden decision

System shape to anchor Codex prompts

• Orchestrated by packages/system-bus and durable Inngest functions.
• Event bridge and notifications flow through Redis, gateway, and Telegram.
• Observability is required: OTEL -> Typesense (otel_events) -> Convex/UI surfaces.
• CLI-first operations are expected; prefer joelclaw, slog, and skill commands instead of direct daemon/db/process pokes.

Always-follow execution contract (from OpenAI Codex prompting guide)

1. No preamble, no plans, and no “I’ll do X then Y” narration.
2. Preserve strict action-first output:
   • do exactly what the user asked
   • include only necessary confirmation
   • return direct results.
3. Keep prompts structured and executable.
4. Preserve one clear objective and constrained scope.
5. Prioritize safe shell/tool actions and explicit failure handling.
6. Use parallel tool calls whenever independent work can run concurrently.
7. Use durable workflow patterns in Codex loops:
   • explicit IDs
   • explicit rollback/retry context
   • structured outputs for downstream steps.

Canonical request format for Codex handoff

Use this exact shape unless the user already provided a better one:

• Goal: <single concrete outcome>
• Context: <repo/path/runtime facts>
• Constraints: <time/risk/tool limits>
• Do:
  • <task 1>
  • <task 2>
• Deliver:
  • <artifact paths>
  • <verification commands + expected signals>
• Rollback:
  • <quick recovery command>

If asking Codex to operate this repo, include absolute paths and the owning system paths (apps/web, packages/system-bus, etc.).

Skill routing reminders

When Codex output needs deeper execution, remind Codex to use these local/system skills first:

• inngest and inngest-durable-functions for durable work definitions and retries
• gateway and gateway-diagnose for session/event bridge and Telegram path checks
• o11y-logging for telemetry-first implementations
• joelclaw-system-check for full environment health checks
• skill-creator when defining/expanding skill content
• joelclaw CLI (status, runs, logs, etc.) for validation

If context is web work, add:

• joelclaw-web, frontend-design, and any relevant next-* skill.

Do NOT poll codex_tasks

After dispatching a codex task, do not poll codex_tasks in a loop. The widget shows live status automatically. Polling every 2-3 seconds wastes tokens, clutters the conversation, and adds no value.

Instead:

• Dispatch the task
• Do other useful work (read files, update ADRs, prepare next steps)
• Check codex_tasks once after ~60 seconds, or when the widget shows completion
• If the task is still running after 60s, check once more at ~120s
• Never poll more than 3 times total for a single task

The task result is reported back automatically when it finishes. Trust the widget.

What to include in prompts

For any Codex-requested operational run:

• exact paths
• exact command(s) to run
• expected signals for success/failure
• idempotency strategy
• rollback command.

For any code change:

• file targets (absolute or repo-relative)
• compatibility constraints
• observability check to prove behavior.

Mac volume mounting note

• Do not assume this is solved universally.
• Treat macOS volume mount failures as environmental and include explicit mount/permission checks before retries.
• If failures recur, route through retry + diagnostic signal collection before reattempt.

Trigger and detection notes

• This is an intent skill: treat natural language variants as valid.
• If user includes any of:
  • "send to codex"
  • "prompt codex"
  • "use codex"
  • "ask codex"
  • "delegate to codex"
  • "run in codex" then route here first.
• If phrasing is vague, ask one minimal clarification and keep the response minimal.

Quick command patterns

rg -n "toolName\\\":\\\"codex\\\"|send to codex|prompt codex|use codex|ask codex|delegate to codex|delegate this to codex|run this in codex|run in codex|handoff to codex|handoff this to codex|codex this" ~/.pi/agent/sessions
joelclaw status
joelclaw runs --count 10 --hours 24
joelclaw otel stats --hours 24