# Codex Pipeline > Use for a new feature, project step, or broad change that needs separate Codex contexts for specification, independent critique, Astra implementation, and acceptance with a judge-owned commit. Keep a journal, worktree, author questions, and checkable boundaries; do not use it for a one- or two-file point fix. - Skill: `dmitry-fomin/codex-pipeline` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add dmitry-fomin/codex-pipeline` - Raw SKILL.md: https://api.skillmd.com/api/skills/dmitry-fomin/codex-pipeline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: dmitry-fomin (https://skillmd.com/u/dmitry-fomin) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/dmitry-fomin/codex-pipeline --- # Codex pipeline You are the orchestrator. Route stages, ask the author questions, keep the journal, and merge worktrees. Do not write code, write the specification, or commit a work portion yourself. Every stage gets a fresh Codex context with explicit `model` and `reasoning_effort`; the orchestrator's current model does not leak into a stage. ## Roles | Stage | Model | Effort | Report starts with | | --- | --- | --- | --- | | Specification and checklists | `gpt-5.6-sol` | `xhigh` | `ready` or `question` | | Specification critique | `gpt-5.6-terra` | `high` | `blocking findings: N` | | Implementation | `gpt-6-astra` | `xhigh` | `ready`, `blocked`, or `question` | | Acceptance and commit | `gpt-5.6-luna` | `high` | `green` or `red` | Verify these model ids and effort levels in the local Codex model catalog before the first run. If one is unavailable, stop and ask the author for an explicit replacement. Never silently fall back. Astra owns implementation because it sees the real code at the highest effort; Luna is a fresh independent acceptance context. ## Invariants - Only the implementation stage writes a portion. Only the judge commits it after a green verdict. - Commit specifications, reviews, red reports, and journals separately with explicit paths. Never use `git add -A` for a portion or paper. - The implementer and judge use the same worktree. Never run two writing agents in one worktree; start the next portion only after the previous commit. - Pass paths as plain strings. The orchestrator keeps short reports and journal entries, not the contents of stage files or diff dumps. - Never touch `.env`, `*.key`, `*.pem`, or `credentials.json`. The implementer must not run `git add`, `commit`, `push`, `stash`, `reset`, `checkout`, or `clean`. The judge must not push, reset, stash, checkout, clean, rebase, amend, or use `--no-verify`. - Relay an agent's questions verbatim to the author and return the author's answer verbatim. ## Agent calls Use `spawn_agent` with `fork_turns: "none"`, absolute paths, `model`, and `reasoning_effort`. Save the returned agent id. Continue an agent after an author answer with `followup_task` and that id. After `blocked` or `red`, start a fresh context and include the verbatim report; never reuse a stale implementation context. Agent calls are asynchronous. Wait for completion before starting the next stage of that portion. Independent tracks may run in parallel; portions inside one track may not. ```text spawn_agent({ task_name: "pipeline_spec", fork_turns: "none", model: "gpt-5.6-sol", reasoning_effort: "xhigh", message: "Read .../step.md and write .../step-07.a.md and its checklist." }) ``` ## Step 0: state and task class Read `.codex/feature-pipeline.yaml` when present. Defaults are `paths.specs=docs/specs` and `paths.steps=docs/specs/steps`. Create the steps directory when absent. Find the journal for the spec or step and restore closed portions, the current portion, author answers, and counters. If there is no journal, create one whose first line is the original task. Handle a point fix in one or two files outside this pipeline. For a broad mechanical change, put the author's exact text in `adhoc-YYYY-MM-DD-slug.a.md` and start at stages 3 to 4. For a new or architectural task, use stages 1 to 4. If the author names independent parts, give each its own step number, worktree, and journal; do not infer independence. Ask about shared lock/config/ registry files before creating worktrees; a shared file becomes a predecessor track. Check `git status --short` first. If the tree is dirty and the journal has no unfinished portion, stop and ask the author to commit or remove their changes. Do not stash, reset, or clean. For a track, inspect `git worktree list`, then create from current `HEAD`: `git worktree add -b pipeline- ../- `. ## Stages ### 1. Specification Run `gpt-5.6-sol` at `xhigh` once per step. Give it the spec path or exact author request, steps directory, step number, and track boundary. It writes portion files and acceptance checklists in the steps directory and changes no code. Require a report of at most 30 lines beginning with `ready` or `question`, followed by portions and assumptions. A question pauses for the author; `ready` records the portion count in the journal. ### 2. Critique Run a fresh `gpt-5.6-terra` at `high` for each portion. Pass absolute paths to the portion and checklist and ask it to write `step-NN.review-X.md`. It must not change the spec or code and must return exactly `## Blocking` and `## Significant`, with numbered findings or `none`. With zero blocking findings, continue. Otherwise show the findings verbatim to the author, send decisions to the specification agent with `followup_task`, then continue with the corrected spec. Critique each portion once; do not re-critique corrected text. ### 3. Implementation Run a fresh `gpt-6-astra` at `xhigh` with write access in the track worktree. Pass absolute paths to the worktree and portion, and prohibit commits. Require it to read the full spec, obey its boundary, avoid changing tests to fit the implementation, run project tests/lint/types, and return at most 30 lines beginning `ready`, `blocked`, or `question`, then requirements, deviations, files, and checks. Continue a question with `followup_task` and the author's exact answer. Retry `blocked` in a new Astra context with its exact wording. ### 4. Acceptance and commit Read `references/diff-package.md` and create a diff package in the worktree's git directory. Include status, diff stat, and a full diff while excluding the steps directory and `*.journal.md`. Register untracked files temporarily with `git add -A -N`, then reset only those paths after the dump. Pass the judge absolute paths to the portion, checklist, dump, previous dump when any, and worktree. Run a fresh `gpt-5.6-luna` at `high` with write access. It checks every checklist item against the actual code and project commands, and looks for test weakening, skipped guards, disabled lint rules, unrelated changes, and boundary violations. `green` is valid only when the judge explicitly added the portion paths and created a normal commit; it must not push. Record the commit hash and start the next portion. `red` creates no commit; pass the verbatim findings to a new Astra implementation run. ## Questions, limits, and tracks Only the specification author and implementer ask questions. Journal each question and answer. Per portion, `M` counts consecutive `blocked` reports and `K` counts red acceptances. Allow two retries. The third `blocked` becomes a red result. The third red starts one full specification rewrite and resets both counters; a second full rewrite stops the portion and reports to the author. For adhoc work, the third red stops without rewriting the specification. Close a track only after every portion is green and its papers are journaled. Merge tracks one by one with `git merge --no-ff pipeline-` in the main worktree. A conflict stops the run and goes to the author. Remove a worktree and branch only after its tree is clean. Run project checks in the main tree. Push only when the author separately requests it. Journal lines use these forms: ```text track : step NN, worktree , branch pipeline-, base step NN: start, preset codex-pipeline, portions K portion X: question | author answer | critique | blocked | red | ready (commit hash7) step NN: closed, portions K/K track : merged ``` `references/diff-package.md` contains the exact dump command and acceptance reminders. Read it before the first acceptance stage.