--- name: writing-codex-briefs description: Use when composing the task brief and acceptance criteria for a Codex dispatch (invoked from dispatching-to-codex). Covers the self-contained brief format and how to write acceptance checks that actually protect you — weak checks are the sneakiest way a dispatch goes wrong. --- # Writing Codex Briefs Codex sees **zero** chat history. The brief is the only channel. Anything not in it does not exist for Codex. ## The Acceptance File — `.codex/ACCEPTANCE.md` Written and committed BEFORE dispatch. This is the frozen bar the judge will enforce. ``` GOAL: CHECKS (all must pass, exact commands): - `` exits 0 and prints - `` exits 0 - `` exits 0 CONSTRAINTS: - Only edit . Do not modify . ``` **Writing checks that protect you** (the judge is only as strong as these): - Prefer commands with **exit codes** over "the code should look right". - Include at least one check that **fails before the work is done** (red → green) — a check that passes on the untouched repo proves nothing. - Name the *specific* tests, not "run the tests" (slow suites make the judge cry wolf; flaky checks are worse than none). - Vacuous bars ("typecheck passes") let bad work through with a green light. Ask: *could a lazy stub pass these checks?* If yes, tighten them. ## The Brief ``` GOAL: CONTEXT: DO: VERIFY: REPORT: DO NOT: commit anything; touch .codex/ACCEPTANCE.md; edit unrelated files; delete or weaken tests; add silent fallbacks or fake/stubbed results. ``` The `DO NOT` block is mandatory and always includes those five items — they are the exact ways executor models paper over failure. ## Common Mistakes - **Context by reference** ("as discussed above") — Codex has no "above". Inline it. - **Goal drift** — brief GOAL ≠ ACCEPTANCE GOAL means the judge enforces a different bar than Codex aimed at. - **Kitchen-sink briefs** — one dispatch, one goal. Two unrelated goals = two dispatches.