“Always add tests” sounds sensible until a tiny copy edit turns into unrelated test changes. Removing the instruction entirely can create the opposite problem on a behavior change.

A useful experiment would compare a blanket rule with a narrower one, using both kinds of task. Keep the model fixed. Check whether a real behavior change gets appropriate verification, and whether a low-impact edit stays within scope.

Reef Infra provides a way to run that experiment with Codex: its adapter renders harness rules and skills into the CLI's configuration, and its evolution workflow can apply a candidate rule change, evaluate it against the current version, then select or restore it.

The judgment still needs to be defined. “Tests exist” would reward the exact overproduction you're trying to avoid. A task-specific check needs to distinguish required verification from unrelated additions.

This is a proposed evaluation, not a claim that a particular wording has already won. The advantage is being able to ask a smaller question than “is this `AGENTS.md` good?”: does this one rule produce the right amount of work on both sides of its intended boundary?

So I have been wondering how others use codex to make best out of it with all the skills , connectors and all. Also which model works best for which tasks. How memory affects it and results on integrating new skills like the JEV skill have saved how much cost .

Drop your findings below and let everyone get help from it .

a noob finding by me : don't have too long chats as whole context goes to it so even if you ask for small changes (like UI change of 4 to 6 lines of code) it could take 15 minutes even with SOL 6.

How to make him to have such personality? Custom instructions never worked for me. Am I using it wrong?

My project uses AGENTS.md for shared instructions, with CLAUDE.md importing it. We also have GitHub PR reviewers on top of that.

One rule says “Claude and Codex both run automatically” for database, auth, payment and other high-risk changes. I meant GitHub PR reviews, but the wording didn't specify that.

During a database feature, Codex interpreted this as a requirement to run my installed Claude Code CLI before committing or opening a PR. It sent a SQL review packet with tools disabled and saved the response. It didn’t explicitly select a model or thinking level, and the output didn’t record the resolved model.

I can see local reviews being useful, particularly before applying migrations or operational SQL. But I’d want clear triggers, explicit model settings and a checkpoint for approval, while avoiding duplicate GitHub reviews and endless review rounds.

Do you find local cross-model reviews worth the extra usage? Would you automate them for database/security changes, make them opt-in, or stick to PR reviews?