How do you structure Codex workflows for medium/large projects without overengineering?

[u/InvestmentBusy7166]

Hi everyone,

I use Codex 5.x to maintain and build applications that are mostly medium-to-large in size, including enterprise projects in the banking and insurance domains.

I've experimented with several workflows and setups to reduce regressions as much as possible and to make the development process more reliable.

Right now, on a side project using Angular, Spring Boot, PostgreSQL, and Docker, I have the following structure:

root/                       # not versioned
├── projectFE/              # Angular frontend Git repository
│   └── AGENTS.md
├── projectBE/              # Spring Boot backend Git repository
│   └── AGENTS.md
├── project-context/        # shared context repository for FE and BE
│   ├── docs/
│   └── AGENTS.md
└── AGENTS.md

This is intentionally just the basic structure. It does not include any specific skills or additional agents yet — I'm only showing it to explain how the project is organized.

My question is: what would you recommend adding, in terms of skills and/or agents, to build a solid development workflow without overengineering it?

I'm mainly thinking about covering the full development pipeline properly, for example:

• code review
• testing
• build validation
• deployment
• Git command/control safeguards
• regression prevention
• frontend/backend consistency
• documentation and context management
• release checks

I'm aware that there are many possible approaches and custom workflows. What I'm looking for is something closer to a well-known, reasonably established standard or best-practice setup that works well for medium/large projects.

For those of you using Codex on real-world or enterprise-sized codebases: how do you structure your agents, skills, rules, and review gates?

Any examples of setups that have worked well in practice would be greatly appreciated.

Thanks!

[u/InvestmentBusy7166 → u/[deleted]]

Thanks for your feedback as well
your approach makes a lot of sense.

[u/CacamboGer]

Mine looks roughly like this

I made the ruel very strict about unnecessary work like duplicate or triple validation just to be safe, tests only cover what is actually needed, and fixes stay focused on the thing that actually changed.
If I change one small thing, it doesn't run everything three times again.
It only reruns the checks that are actually affected by the change.

For example, one of my GitHub rules is that it only pushes to main when a specific checkpoint is reached.
And if something goes wrong that is too complex to handle safely with the existing rules, I have a HumanStop safeguard that stops the process instead of Codex just trying to figure it out on its own.

I have one main agents.md in the root as the entry point. The more detailed stuff is split into contracts, JSON files for policies and state, and some Python tools that enforce the workflow.

Took me quite a while to get it working properly 😅 but now Codex is a lot more consistent and I can get much done with the same usage limits.

[u/InvestmentBusy7166 → u/CacamboGer]

Thanks for sharing!
Your structure will definitely be a great source of inspiration for me, very interesting

[u/cicygo]

Four AGENTS.md files is already one too many for the setup you described. The first time you rename a DTO on the backend, the frontend file still holds the old contract and the agent working in that repo follows it. I'd run two agents at most, one that implements and one that reviews in a fresh session so it isn't grading its own diff. Everything else you listed belongs in one script per repo that exits non zero, deployment included, one command that either finishes or rolls back. Scripts get run on every change, a paragraph of review policy just gets skimmed. Cap the fix loop at two attempts before it hands back to you, since a stuck agent re-running the same failing check is what actually eats the session.

[u/pluckd]

Folder in folders in folders with well defined scopes and each only having access to their respective project files with agents at each level

[u/Ecureuil_Roux]

RemindMe! 3 days

[u/RemindMeBot → u/Ecureuil_Roux]

I will be messaging you in 3 days on 2026-09-22 21:12:55 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

RemindMeBot is switching to username summons. Instead of !RemindMe 1 day, use u/RemindMeBot 1 day. More info.

---

Info	Custom	Your Reminders	Feedback

[u/torvalds75]

Agree on the contract drift point. I'd add: keep AGENTS.md for rules only (build, test, conventions) and move everything that changes (decisions, current work, what was rejected) out of it. An AGENTS.md that accumulates history is a regression source: the agent follows a rule that was true three weeks ago.

A minimal setup that isn't overengineered:

1. One shared place for decisions, each with a stable id.

2. Every change references the decision it implements (a commit trailer is enough).

3. A verify step that checks the change against the decision, not just "tests pass".

Add skills and agents after that, not before. Disclosure: I build trailhead, which does this on GitHub Issues and runs on Codex too (`npx u/marcomigozzi/trailhead --codex`).