Codex Conductor
Methodical end-to-end software delivery orchestrator for Codex CLI with dual project modes (greenfie
- Rating
- 4.8 (126 reviews)
- Downloads
- 14,853 downloads
- Version
- 1.0.0
Overview
Methodical end-to-end software delivery orchestrator for Codex CLI with dual project modes (greenfield for new.
Complete Documentation
View Source →
Codex Orchestrator
Coordinate Codex as a disciplined delivery system, not a one-shot generator.
Core Modes
Select both:
project_modegreenfield: build from scratchbrownfield: onboard and modernize an existing systemexecution_modeautonomous: proceed automatically when gates passgated: pause at every gate for user approval
Governing Principle: Spec-Driven Development
No code without a spec. This is non-negotiable.
Before any implementation, a written spec must exist with:
- What is being built
- Why it's needed
- Acceptance criteria (testable)
- Constraints and out-of-scope
- Guess at requirements
- Make assumptions about behavior
- Add unrequested features
- Invent abstractions not in spec
See references/spec-driven-development.md for full spec templates and enforcement rules.
Non-Negotiable Sequence
- Intake + planning questionnaire
- Spec creation + approval (specs written BEFORE any code)
- Docs scaffold + AGENTS.md contract
- Mode-specific pre-architecture work
- Architecture + ADR baseline (references specs)
- Build by vertical slices (each task references spec)
- Verification against spec acceptance criteria
- Security/quality gates
- Release readiness + handover
Required Resources
Read these references before running:
references/spec-driven-development.md(MANDATORY FIRST - governs all work)references/planning-questionnaire.mdreferences/modes.mdreferences/gate-checklists.mdreferences/testing-matrix.mdreferences/manual-test-templates.mdreferences/codex-runbook.mdreferences/gate-prompts.mdscripts/agent_exec.pyreferences/research-playbook.md(ifresearch_mode=true)
Scaffolding
Initialize project artifacts:
python scripts/init_project_docs.py --root <project-path> --mode <greenfield|brownfield>
This creates/updates:
AGENTS.md(project workflow contract)docs/*.mdplanning/architecture/test/progress/change docs- brownfield docs (when mode is brownfield)
.orchestrator/status.json(machine-readable state).orchestrator/context.json(project/execution/research mode context)
Planning Rules
Before anything else, ask the user which coding agent to use (codex | claude | opencode | pi) and fallback agent.
Then ask all required questions from references/planning-questionnaire.md.
Minimum required answers:
- mission
- top user journeys
- v1 scope
- hosting target
- stack preference (or explicit request for recommendation)
project_modeexecution_mode- definition of done
- acceptance tests
research_mode=true, produce docs/research-notes.md and architecture recommendation before G2.Mode-Specific Requirements
Greenfield
Must complete before G2:
- requirements + DoD clarity
- architecture baseline
- ADR-0001 with alternatives
- CI/test baseline plan
Brownfield
Must complete before G2 (and authored by coding agent, not orchestrator):
- as-is architecture and system inventory
- dependency map and risk register
- characterization-test baseline
- migration strategy + rollback approach
- compatibility boundaries documented
Gate Engine
Use gates G0 through G7 defined in references/gate-checklists.md.
Update gate state via script:
python scripts/gate_status.py set --root <project-path> --gate G3 --state PASS --note "slice-1 verified"
Validate status schema:
python scripts/gate_status.py validate --root <project-path>
Allowed states: PENDING | IN_PROGRESS | PASS | FAIL | BLOCKED.
By default, gate preconditions are enforced (sequence + mode-aware docs checks).
Validation Rules
Use references/testing-matrix.md.
Mandatory checks per progression:
- lint/type/build
- unit/integration/e2e (as applicable)
- API contract sanity (if API exists)
- security baseline
- docs sync verification
references/manual-test-templates.md.Documentation Rules
For each meaningful step:
- update
docs/tasks.md - update
docs/progress.md - append
docs/change-log.md - update
docs/traceability.md - record test evidence in
docs/test-results.md
python scripts/change_impact.py --root <project-path> --request "<change request>"
Then complete all TODOs it emits in impacted docs.
Codex Execution Pattern
Use PTY/background for long runs. Follow command patterns in references/codex-runbook.md.
Critical rule: each run executes ONE task, not a whole project in one prompt.
For G4, maintain docs/g4-task-plan.md checklist and process tasks one by one.
Generate gate-specific prompts with:
python scripts/generate_gate_prompt.py --gate <G1..G7> --agent <codex|claude|opencode|pi> --project-mode <greenfield|brownfield> --execution-mode <autonomous|gated> --research-mode <true|false> --task "<single task summary>" --spec-ref "<spec ref when applicable>"
update_docs_step.py is now a fallback utility for recovery/manual bookkeeping only.
Primary expectation: the coding agent updates docs directly during each task.
Required loop:
- verify spec exists for the task (no spec = no implementation)
- launch selected coding agent with spec-driven prompt template
- coding agent updates docs immediately after task completion (including handoff checklist)
- coding agent wakes OpenClaw with task summary + where verification steps are documented
- OpenClaw agent runs verification itself:
- CLI checks in terminal tools
- Browser/manual checks in browser tools (for web flows)
- verify output matches spec acceptance criteria
- if validations fail, OpenClaw sends exact failures back to coding agent and re-runs fix cycle
- write final gate status only after validations pass (or mark FAIL/BLOCKED)
run_gate.pyrequires--spec-reffor G3/G4 tasks (implementation gates).run_gate.pyrequires coding agent + fallback agent context.- Each task requires validation evidence (
--validate-cmdand/or--ui-review-note). - Tasks flagged with
--requires-browser-checkmust include--ui-review-note. status=PASSrequires at least one--validate-cmd.status=PASSis blocked when--agent-dry-runis used.- For G4, PASS is blocked until
docs/g4-task-plan.mdhas no unchecked tasks. - Validation output is recorded in
docs/validation-log.md. - Coding agent must update docs after every task, including
docs/agent-handoff.md. - In brownfield mode, G1/G2 fail if onboarding docs are not updated by the coding agent.
- Coding agent prompts MUST include spec preamble from
references/spec-driven-development.md. - Any implementation without spec reference = automatic FAIL.
- In autonomous mode, failed validations trigger automatic fix retries (default: 2) with failure details passed back to coding agent.
- Optional strict mode:
--auto-block-on-retry-exhaustauto-classifies gate as BLOCKED when retries are exhausted.
Progress Visibility
Generate a quick status board:
python scripts/progress_dashboard.py --root <project-path>
This summarizes current gate, completion %, blockers, and recent activity.
Run a single-task gate step with one command:
python scripts/run_gate.py --root <project-path> --gate G2 --agent codex --fallback-agent claude --project-mode brownfield --execution-mode gated --research-mode true --task "architecture baseline refined for API routing" --status IN_PROGRESS --validate-cmd "npm run -s typecheck" --ui-review-note "N/A for architecture-only task"
Mark PASS only after all gate-level checklist items are complete:
python scripts/run_gate.py --root <project-path> --gate G2 --agent codex --task "architecture gate complete" --status PASS --validate-cmd "npm run -s typecheck"
For web/UI tasks, require browser verification by OpenClaw agent:
python scripts/run_gate.py ... --requires-browser-check --ui-review-note "Verified login + CRUD manually in browser via OpenClaw browser tools"
Package distributable skill artifact:
python scripts/package_skill.py --skill-dir . --out dist
End-State Deliverables
At completion provide:
docs/progress.mdat 100%- final gate summary from
.orchestrator/status.json - test result summary + unresolved risks
- deployment + rollback notes
- next-iteration backlog
PARTIAL_COMPLETE with explicit blockers and owners.
Installation
openclaw install codex-conductor
💻Code Examples
python scripts/init_project_docs.py --root <project-path> --mode <greenfield|brownfield>
This creates/updates:
- `AGENTS.md` (project workflow contract)
- `docs/*.md` planning/architecture/test/progress/change docs
- brownfield docs (when mode is brownfield)
- `.orchestrator/status.json` (machine-readable state)
- `.orchestrator/context.json` (project/execution/research mode context)
## Planning Rules
Before anything else, ask the user which coding agent to use (`codex` | `claude` | `opencode` | `pi`) and fallback agent.
Then ask all required questions from `references/planning-questionnaire.md`.
Minimum required answers:
- mission
- top user journeys
- v1 scope
- hosting target
- stack preference (or explicit request for recommendation)
- `project_mode`
- `execution_mode`
- definition of done
- acceptance tests
If `research_mode=true`, produce `docs/research-notes.md` and architecture recommendation before G2.
## Mode-Specific Requirements
### Greenfield
Must complete before G2:
- requirements + DoD clarity
- architecture baseline
- ADR-0001 with alternatives
- CI/test baseline plan
### Brownfield
Must complete before G2 (and authored by coding agent, not orchestrator):
- as-is architecture and system inventory
- dependency map and risk register
- characterization-test baseline
- migration strategy + rollback approach
- compatibility boundaries documented
## Gate Engine
Use gates `G0` through `G7` defined in `references/gate-checklists.md`.
Update gate state via script:python scripts/gate_status.py validate --root <project-path>
Allowed states: `PENDING | IN_PROGRESS | PASS | FAIL | BLOCKED`.
By default, gate preconditions are enforced (sequence + mode-aware docs checks).
## Validation Rules
Use `references/testing-matrix.md`.
Mandatory checks per progression:
- lint/type/build
- unit/integration/e2e (as applicable)
- API contract sanity (if API exists)
- security baseline
- docs sync verification
Also execute manual test scripts from `references/manual-test-templates.md`.
## Documentation Rules
For each meaningful step:
- update `docs/tasks.md`
- update `docs/progress.md`
- append `docs/change-log.md`
- update `docs/traceability.md`
- record test evidence in `docs/test-results.md`
For user-requested changes, run:python scripts/change_impact.py --root <project-path> --request "<change request>"
Then complete all TODOs it emits in impacted docs.
## Codex Execution Pattern
Use PTY/background for long runs. Follow command patterns in `references/codex-runbook.md`.
Critical rule: each run executes ONE task, not a whole project in one prompt.
For G4, maintain `docs/g4-task-plan.md` checklist and process tasks one by one.
Generate gate-specific prompts with:python scripts/generate_gate_prompt.py --gate <G1..G7> --agent <codex|claude|opencode|pi> --project-mode <greenfield|brownfield> --execution-mode <autonomous|gated> --research-mode <true|false> --task "<single task summary>" --spec-ref "<spec ref when applicable>"
`update_docs_step.py` is now a fallback utility for recovery/manual bookkeeping only.
Primary expectation: the coding agent updates docs directly during each task.
Required loop:
1. verify spec exists for the task (no spec = no implementation)
2. launch selected coding agent with spec-driven prompt template
3. coding agent updates docs immediately after task completion (including handoff checklist)
4. coding agent wakes OpenClaw with task summary + where verification steps are documented
5. OpenClaw agent runs verification itself:
- CLI checks in terminal tools
- Browser/manual checks in browser tools (for web flows)
6. verify output matches spec acceptance criteria
7. if validations fail, OpenClaw sends exact failures back to coding agent and re-runs fix cycle
8. write final gate status only after validations pass (or mark FAIL/BLOCKED)
Enforcement:
- `run_gate.py` requires `--spec-ref` for G3/G4 tasks (implementation gates).
- `run_gate.py` requires coding agent + fallback agent context.
- Each task requires validation evidence (`--validate-cmd` and/or `--ui-review-note`).
- Tasks flagged with `--requires-browser-check` must include `--ui-review-note`.
- `status=PASS` requires at least one `--validate-cmd`.
- `status=PASS` is blocked when `--agent-dry-run` is used.
- For G4, PASS is blocked until `docs/g4-task-plan.md` has no unchecked tasks.
- Validation output is recorded in `docs/validation-log.md`.
- Coding agent must update docs after every task, including `docs/agent-handoff.md`.
- In brownfield mode, G1/G2 fail if onboarding docs are not updated by the coding agent.
- Coding agent prompts MUST include spec preamble from `references/spec-driven-development.md`.
- Any implementation without spec reference = automatic FAIL.
- In autonomous mode, failed validations trigger automatic fix retries (default: 2) with failure details passed back to coding agent.
- Optional strict mode: `--auto-block-on-retry-exhaust` auto-classifies gate as BLOCKED when retries are exhausted.
## Progress Visibility
Generate a quick status board:python scripts/progress_dashboard.py --root <project-path>
This summarizes current gate, completion %, blockers, and recent activity.
Run a single-task gate step with one command:Tags
Quick Info
Ready to Install?
Get started with this skill in seconds
Related Skills
4claw
4claw — a moderated imageboard for AI agents.
Aap Passport
Agent Attestation Protocol - The Reverse Turing Test.
Acestep Lyrics Transcription
Transcribe audio to timestamped lyrics using OpenAI Whisper or ElevenLabs Scribe API.
Adaptive Suite
A continuously adaptive skill suite that empowers Clawdbot.