skills/codex-implement/SKILL.md
Implement features via Codex MCP. Use when: writing new code from specs, implementing features, Codex-driven development. Not for: code review (use codex-code-review), architecture advice (use codex-architect). Output: implemented code + review loop.
npx skillsauth add sd0xdev/sd0x-dev-flow codex-implementInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
/codex-architect)/codex-review-fast)/bug-fix)Parse args → Decompose → Collect context → Iterate items → Review loop → Done
↕
codex → diff → confirm
↕
reject/modify → codex-reply
--spec provided: Read spec/request doc, extract individual items.
Arguments without --spec: Use directly as single item.
No arguments: Ask user for requirement, target file, reference files.
Break into implementation items — each one logical unit (interface, method, endpoint), implementable in dependency order, small enough for one Codex call.
Present plan before starting:
| # | Item | Target File | Depends On |
|---|-------------------|----------------------|------------|
| 1 | Define interfaces | src/interface/x.ts | - |
| 2 | Core logic | src/service/x.ts | 1 |
| 3 | Controller/Route | src/controller/x.ts | 2 |
Proceed?
Claude researches the codebase before calling Codex:
.claude/CLAUDE.md (fallback CLAUDE.md) — tech stack, conventions, test commandsSummarize as PROJECT_CONTEXT for Codex.
Implement one item at a time, in dependency order.
See references/codex-prompts.md for the full prompt template.
Call mcp__codex__codex with sandbox: 'workspace-write', approval-policy: 'on-failure'.
Save the returned threadId.
After each Codex call: git diff → ask user:
| Choice | Action |
|--------|--------|
| Accept | Proceed to next item (3c) |
| Reject | git checkout . affected files, re-attempt (max 2 retries, then ⛔) |
| Modify | codex-reply with feedback → loop back to 3b |
Use mcp__codex__codex-reply with saved threadId. See references/codex-prompts.md.
Repeat 3b → 3c until all items done.
git diff full changeset → user confirms.
⚠️ @CLAUDE.md auto-loop: fix → re-review → ... → ✅ PASS ⚠️
| Step | Command | On fail |
|------|---------|---------|
| 1 | /codex-review-fast | codex-reply to fix → re-review |
| 2 | /precommit | codex-reply to fix → re-run |
Issues found → use same Codex thread to fix (not manual). See references/codex-prompts.md for fix prompt.
Max 3 rounds per step. Still failing → report blocker.
| Change Type | Required Tests | |-------------|---------------| | New service/provider | Unit (happy + error + edge) | | New API endpoint | Unit + integration | | Modified logic | Existing pass + new logic tests | | Bug fix scenario | Regression test |
If Codex omitted tests → codex-reply to request them.
## Codex Implementation Report
### Implementation Items
| # | Item | Target File | Status |
|---|------|-------------|--------|
| 1 | ... | ... | ✅/❌ |
### Change Summary
| File | Operation | Description |
|------|-----------|-------------|
| ... | Create/Modify | ... |
### Review Result
<codex-review-fast output>
### Gate
✅ Complete / ⛔ Needs modification
/codex-review-fast passed/precommit passed/codex-implement "Add a method to calculate fees"
/codex-implement "Implement wallet service" --spec docs/features/wallet/2-tech-spec.md
/codex-implement "Add getUserBalance method" --target src/service/wallet.service.ts
/codex-implement "Implement cache logic" --target src/service/cache.ts --context src/service/redis.ts
documentation
Rewrite the previous reply in Traditional Chinese
development
Monitor GitHub Actions CI runs until completion. Use when: watching CI after push, checking build status, monitoring PR checks, waiting for CI completion, user says 'watch CI', 'check CI', 'CI status', 'monitor build', or /watch-ci. Not for: pushing code (use push-ci), creating PRs (use create-pr). Output: per-run verdict (pass/fail/timeout).
development
Verification loop — lint -> typecheck -> unit -> integration -> e2e
development
Research current code state then update corresponding docs, ensuring docs stay in sync with code.