brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
writing-codex-briefsUse 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.
Independent GitHub snapshot · Automated classification · Original documentation governs
Codex sees zero chat history. The brief is the only channel. Anything not in it does not exist for Codex.
.codex/ACCEPTANCE.mdWritten and committed BEFORE dispatch. This is the frozen bar the judge will enforce.
GOAL: <one sentence: what "done" means>
CHECKS (all must pass, exact commands):
- `<command>` exits 0 and prints <expected>
- `<build/typecheck command>` exits 0
- `<specific test command>` exits 0
CONSTRAINTS:
- Only edit <files/dirs>. Do not modify <test files / this file / unrelated code>.
Writing checks that protect you (the judge is only as strong as these):
GOAL: <same one sentence — must match ACCEPTANCE.md>
CONTEXT: <repo path, key files, constraints — everything Codex needs, it cannot ask you>
DO: <numbered, concrete steps>
VERIFY: <run the exact CHECKS above and show their real output>
REPORT: <what to return: diff summary + which checks passed>
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.