codex-agents

Installation
SKILL.md

Codex agents — the Codex CLI as peer, builder and reviewer

Codex is a peer, same standing as Claude. Not a formatter, not a gate, not an authority. It runs on the newest model the Codex CLI offers, at its highest reasoning effort (xhigh, the wrapper's default on every turn).

It can build, and what it builds is reviewed by someone else. Hand it a build stage — the goal, the decisions that bind it, the files it will touch — and read the diff that comes back before believing it: a delegated diff is unreviewed code. The session that wrote code never clears it; an independent review (the independent-review skill, or whatever the project uses) does, and Codex can be that reviewer for code it didn't write (§ Reviewer). Deciding what the product should do, accepting or rejecting a review finding, anything that touches a real system, development included (any database, even one only you use, a server, a setting), and judging that a stage is done stay with the session agent; the brief says so, and asks for each real-system step as one command the session agent runs. Without the Codex CLI, or while it is out of usage (§ Resume or start fresh), the session agent builds the stage itself.

Delegate only what is worth the hand-off; the test is size, not time. If the brief would be nearly as long as the diff, write the diff: a stage small enough to describe precisely is small enough to write, and handing it over only buys a wait. A build round that has made no writes on a small change (check git status) is stopped, its leftover process killed, and the change written in-session rather than waited on. What stays with the session agent is unchanged, and its diff still gets the independent review. (2026-09-22, a builder sat twelve minutes on a fifteen-line change with zero writes and a clean tree.)

The way the human manages Claude (goal + context, not step-by-step; trust judgment; push back on disagreement) is how Claude manages Codex.

Codex can write code AND generate images directly (multimodal output) — don't assume deliverables must be HTML/code. If the goal is a PNG, say that. Don't translate it to "an HTML file we'll screenshot."

Core discipline (read before every session)

  1. Peer, not tool. Same standing as Claude. Trust its judgment on path, structure, format, fonts, dimensions, libraries — Codex picks those. If it picks something you wouldn't have, that's a useful disagreement to surface, not a defect. Codex's view is not binding — push back where warranted.

  2. Early, not late. Bring Codex in at ideation and framing, not only as a pre-publish gate. The cheapest wins are at the start: choosing the angle, naming the load-bearing claim, deciding what to cut. Late peer-review is the least valuable use.

  3. Strategic context, not step-by-step. Hand over the goal, the facts, and the reasoning behind non-obvious choices. Do not prescribe paths, filenames, fonts, dimensions, libraries, chart types, or step-by-step procedures unless they are hard requirements.

Installs
9
GitHub Stars
241
First Seen
6 days ago