CoDriDe — Codex CLI Instructions

Generated by /meta:generate-target codex from this project's canonical Claude Code source (CLAUDE.md + .claude/rules/*.md). Do not hand-edit this file — re-run the generator instead, since any manual change here is lost on the next regeneration (full overwrite, never merged).

From CLAUDE.md

CoDriDe

CoDriDe is a Context Driven Development (CDD) framework: a set of Skills (native to Codex CLI here, under .agents/skills/) meant to be copied into another project's repo to structure how features get discovered, specified, built, and shipped. CoDriDe's canonical source is authored for Claude Code and generated into other tools' native formats — see "Multi-LLM support" below — but nothing about using it here requires Claude Code.

CoDriDe on Codex CLI works differently from Claude Code in two structural ways, both explained fully in "What's different" in the upstream guide at https://github.com/edilson-silva/codride/blob/main/docs/llm-guides/codex.md (a relative link doesn't work here — docs/ isn't part of what gets copied into an adopting project, only .agents/ and this file are): there is no sub-agent delegation at all (every skill that used to invoke a separate agent has that agent's logic inlined directly into it), and there is no formal argument-substitution syntax (a skill reads what it needs from your natural-language request, not from a templated placeholder).

The framework treats master docs as the project's "DNA": living documents (business context + technical context) that every feature gets checked against, both before it's built (product-validate) and after (the ADR/master-docs checks inlined into engineer-validate).

Project management runs through GitHub Issues, via the gh CLI.

For full command-by-command documentation, best practices, and adoption instructions, see README.md.

Pipeline

warm-up
   │
   ├─ (new or unfamiliar project) engineer-doctor ─── pre-flight check: gh auth, default branch,
   │                                                     test suite, master docs, labels, monorepo shape
   │
   ├─ (once, optional) engineer-discover ─── scans ADRs + whichever domains are present (backend/
   │                                            frontend/mobile), writes docs/technical-context/project-briefing.md,
   │                                            checks existing code against those ADRs (inlined, no separate agent)
   │
   ├─ Product track
   │     product-collect      ─ capture a raw idea/bug as a GitHub issue
   │     product-refine       ─ turn it into a WHY/WHAT/HOW requirement doc
   │     product-spec         ─ expand into a full PRD; writes docs/business-context/features/<slug>.md
   │     product-validate     ─ validate against master docs
   │     product-brainstorm   ─ structured exploration for open-ended decisions
   │     product-sync-github  ─ sync docs/business-context/features/*.md (from spec/quick-spec) with GitHub Issues
   │     product-quick-spec   ─ create a fully-specced issue directly from a task description; also writes features/<slug>.md
   │
   └─ Engineering track
         engineer-context      ─ interview → context.md for one unit of work
         engineer-architecture ─ design → architecture.md, cross-checked against context.md
         engineer-plan         ─ phased plan.md (2-hour-sized phases)
         engineer-work         ─ execute a phase, ADR-guided, syncs the GitHub issue
         engineer-pre-pr       ─ orchestrator: runs the 4 below, all sequentially — Codex has no
              engineer-validate   ─  branch vs. master docs        concurrency mechanism at all,
              engineer-review     ─  code review                   not just "sequential instead of
              engineer-sync-docs  ─  update project docs           parallel" the way Gemini is
              engineer-coverage   ─  missing test coverage
         engineer-pr           ─ commit, open PR, move the issue, handle review-bot comments
         engineer-bump         ─ semver bump (pyproject.toml or package.json)
         engineer-adr          ─ draft a new Architecture Decision Record

Each of engineer-validate, engineer-review, engineer-sync-docs, and engineer-coverage also runs standalone — use engineer-pre-pr for the full sweep before a PR, or run just the one you need.

engineer-context and engineer-architecture aren't just for features — run them for a fix, a chore, or anything substantial enough to benefit from a written plan, even before a full product-track spec exists.

Three practices are woven into the pipeline rather than bolted on as separate commands: product-spec writes BDD acceptance criteria (Given/When/Then) per user story; engineer-work implements test-first against them (red-green-refactor); engineer-architecture has an optional DDD domain-model section for features where the domain is complex enough to warrant one. See README.md for the optional MCPs (Context7, a Playwright MCP) that pair with these — MCP itself works the same way on Codex CLI as on Claude Code.

Example: one feature, end to end

product-collect "customers want to export their order history as CSV"
# → creates GitHub issue #42

product-refine 42
# → issue #42 updated with WHY/WHAT/HOW

product-validate "CSV export of order history, issue #42"
# → confirms it doesn't violate any master doc

product-spec 42
# → issue #42 becomes a full PRD

engineer-context feat/csv-order-export
# → .codex/work/feat/csv-order-export/context.md

engineer-architecture feat/csv-order-export
# → .codex/work/feat/csv-order-export/architecture.md, cross-checked against context.md

engineer-plan feat/csv-order-export
# → .codex/work/feat/csv-order-export/plan.md (phased)

engineer-work .codex/work/feat/csv-order-export
# → implements Phase 1, syncs issue #42 to "in progress", repeat per phase

engineer-pre-pr
# → engineer-validate, engineer-review, engineer-sync-docs, engineer-coverage
#   run one after another, all against the branch

engineer-pr
# → tests run, commit, PR opened, issue #42 moved to "in review"

Artifacts for an in-progress unit of work live in .codex/work/<type>/<slug>/ (context.md, architecture.md, plan.md) — not just features: <type> follows Conventional Commits (feat, fix, docs, chore, refactor, test, perf, build, ci, style, revert), so a bug fix lives at .codex/work/fix/<slug>/ and a docs update at .codex/work/docs/<slug>/, following the same type/slug shape as the branch name. This is a Codex-CLI-specific location — it doesn't share work items with a .claude/work/ from Claude Code or a .gemini/work/ from Gemini CLI, even on the same project.

Doc-generation utilities live under the bootstrap-* skills (bootstrap-tech-docs, bootstrap-business-docs, bootstrap-index) for bootstrapping the multi-file master-docs architecture in a new project from scratch.

What ran as separate agents on Claude Code, here

Claude Code has 8 core sub-agents, each a separate delegatable file. Codex CLI has no sub-agent delegation mechanism at all, so none of these exist as separate files here — 6 are inlined directly into the one skill that used to invoke them, and 2 (with no single fixed caller on Claude Code either) are their own standalone skills:

Add project- or stack-specific skills the same way meta-create-agent describes, rather than editing this set — keep the framework's own skill roster generic. Skill names have no subdirectory-based namespace collision protection here (a flat .agents/skills/<name>/ per skill), so CoDriDe's own skills use a <namespace>-<name> prefix (engineer-validate, product-validate) to stay collision-free; follow the same convention for anything you add.

Adopting CoDriDe in a project

1. Copy .agents/ (and this file, merged with any project-specific instructions) into the target repo.
2. Run engineer-doctor — confirms gh auth, the real default branch, whether a test suite exists, and what's already there on an existing project, before anything else runs on assumptions.
3. Run meta-preferences — one-time (re-runnable) setup for project-level preferences: the language docs//.codex/work/ artifacts get written in (not conversational language, which the model already mirrors automatically), extensible for more later. Writes docs/PROJECT_PREFERENCES.md — sibling to docs/business-context/ and docs/technical-context/, not nested inside either, since this isn't business/product content. (Claude Code's version of this command also configures Artifacts publishing — that feature doesn't exist on Codex CLI, so it's absent here.)
4. Run engineer-discover once to generate docs/technical-context/.
5. Write master docs under docs/business-context/ (use bootstrap-business-docs and bootstrap-tech-docs to bootstrap them).
6. From there, follow the pipeline above.

Multi-LLM support

(This subsection is reworded from CLAUDE.md's own "Multi-LLM support" section for a Codex CLI reader, rather than folded verbatim like the rest of this file — the underlying facts are the same, the framing is adapted.)

This file (AGENTS.md) and .agents/skills/ were generated from CoDriDe's canonical Claude Code source (.claude/commands/, .claude/agents/, CLAUDE.md, .claude/rules/*.md), maintained in the upstream CoDriDe repository — not in this project. You don't need Claude Code, or the generator command, to use CoDriDe here: everything in .agents/skills/ and this file is self-contained and native to Codex CLI. If this project's copy ever looks out of date relative to a newer CoDriDe release, ask whoever maintains your copy of CoDriDe to regenerate it — that's not something to do from inside this project.

See README.md for the full walkthrough.

From .claude/rules/product-agent.md

PM Assistant — Master Prompt

Professional identity

You are a hybrid AI assistant combining three critical functions:

• Product Owner: defines and prioritizes features with a focus on customer value.
• Delivery Manager: ensures on-time delivery and efficient project management.
• Solution Architect: specifies technical solutions and implementation architecture.

Core traits

• Logical and analytical: always ground recommendations in data and concrete evidence.
• Direct and concise: get straight to the point, no unnecessary preamble.
• Constructively challenging: question assumptions and propose alternatives when you spot weak points.
• Independent: take the initiative to propose complete solutions without needing micro-direction.
• Strategic: always consider long-term impact, not just the immediate fix.

Communication style

• No fluff: skip unnecessary pleasantries, go straight to value.
• Structured: use bullets, numbering, and clear information hierarchy.
• Evidence-based: always explain the "why" with solid reasoning.
• Honest feedback: if something doesn't make sense or carries risk, say so clearly.
• Proactive: anticipate next steps and likely problems.

Core principle

Always raise your hand when something is unclear. Always confirm your understanding before proceeding.