Codex Skills Mode: Installing Skill Packs and an Autonomous Implementation Loop (cc-sdd)

Codex 跑長任務最怕「越做越歪、上下文污染」。
cc-sdd 的 Codex skills 模式給你一個解法：每個子任務都派一個全新的實作者，做完再由獨立審查者驗收，失敗就追根因自動除錯。
這篇教你裝起來，並把這個迴圈變成可貼的提示。

[ Log in to see the full prompt ]

## What it is, what problem it solves The most common failure mode when running Codex CLI through a long series of tasks is 'context contamination': by the fifth task, it's still carrying temporary assumptions from the first and second, drifting further off course, and even stuffing in workarounds just to make tests pass. cc-sdd's Codex skills mode offers two remedies aimed squarely at this: first, packaging reusable capabilities into SKILL.md files that load on demand (instead of cramming every instruction into one giant AGENTS.md); second, its `/kiro-impl` autonomous implementation loop deliberately adopts a structure of 'a fresh implementer per task, verified by an independent reviewer, with automatic root-cause debugging on failure.' This piece turns the install steps and that loop into a prompt you can paste straight to Codex. ## Why this source is worth using cc-sdd is an MIT-licensed, spec-driven development tool that works across Claude Code / Codex / Gemini / Cursor and more; it explicitly lists Codex as a Stable platform for skills mode, and the install command is simply `npx cc-sdd@latest --codex-skills`. What's worth borrowing isn't which documents it generates, but the execution discipline behind `/kiro-impl`: fresh implementer per task, independent reviewer pass, and auto-debug on failure with root cause investigation. These three are the key to keeping a long-running agent from falling apart, and we've extracted them into a general-purpose prompt. ## How to use it (steps) 1. Run `npx cc-sdd@latest --codex-skills` in your project root; it drops in on-demand SKILL.md skills and creates an AGENTS.md as Codex's project-level instruction file. 2. Prepare your task list (this can be the tasks.md it generates, or one you write yourself) — each task needs clear 'boundaries' and 'acceptance criteria,' which is the prerequisite for the reviewer to verify objectively. 3. Paste the execution prompt above to Codex, feeding it one task number at a time, and let it run through the full 'implement → boundary check → independent review → root-cause debug on failure → wrap-up' loop. 4. Check the 'files changed' and 'suggested next task' it lists at wrap-up, and confirm before moving to the next task. This 'pause and wait for confirmation' checkpoint is your hand on the brake, keeping it from running wild. ## When to use it When you have a broken-down task list and want Codex to implement it autonomously, task by task, without going off the rails partway through; or when you want to wire Codex into a dual role of 'implementer + self-reviewer' to reduce the manual review burden. For a single small change, or while you're still in the exploration phase (tasks not yet broken down), this is overkill — just interact with it directly. ## A practical caveat The 'independent reviewer' and the 'implementer' are actually the same model playing two roles, so it isn't really a second pair of eyes; its value is in forcing the model to switch to a perspective of 'only look at the diff against the acceptance criteria,' which does catch a fair number of out-of-scope edits and omissions, but it cannot replace real human or CI oversight. Treat it as the first filter, not the last line of defense. 📎 Source: gotalab/cc-sdd (by gotalab, MIT licensed) — this piece is a rewritten and reorganized version; see the link above for the original content.