I seem to be doing very well with codex and perhaps it is my agents.md files. They are customized per project but here is the main gist:
– Push back when what the user is saying is wrong or doesn’t match your understanding.
– Use characterization to expose the current behavior before and after architecture work. Do not use characterization as a reason to avoid building the mature mechanism when the mechanism is already understood.
– Explain architecture and representation changes in enough detail for the user to assess direction without reading code. Summaries should include the mechanism being changed, assumptions being made, what is intentionally not changing, and any risks of drift such as storage handles or diagnostics becoming model logic.
– Do not move at “tiny step” pace by default. Small edits are useful when they reduce risk without changing the architecture, but architecture work should land as a complete mechanism.
– Prefer clean, single-purpose implementation shapes over keeping alternate paths, duplicate trace fields, or unused helpers “just in case.” We use git;
recreate removed code later if a real need returns.
– If an implementation is intentionally temporary, call it a scaffold explicitly, record what mature mechanism it is standing in for, and treat it as a debt item to remove or replace. Do not keep scaffolds merely because they are convenient, easy to test, or already present.
– Default to the most mature implementable mechanism. If the mature mechanism
cannot be implemented yet, state the missing dependency explicitly and add it to `TODO.md` rather than quietly building a narrower substitute.
– If the mature mechanism is blocked by a structural dependency, make removing or fixing that blocker the next implementation task. Do not land a bounded,
partial, or proxy version of the mechanism unless the user explicitly asks for that scaffold after the blocker is explained.
– Speak precisely about verification level. Do not say a mechanism “works”, “is fixed”, or “is done” for an architecture goal when only an isolated unit
test or controlled diagnostic passes. State the actual level of evidence: unit mechanism, subsystem diagnostic, full text pipeline, or full hierarchy
pipeline.
– Choose production-grade dependencies and designs instead of local-only hacks or proof-of-concept shortcuts.
– Production may move from shared hosting to a VM when OS-level dependencies are the right production solution.
– Do not add fallback paths unless explicitly requested.
– Do not add database migrations unless explicitly requested.
– Prefer characterization before new architecture.
– Do not tune thresholds just to make a test pass.
– When tests fail in a revealing way, report what the failure says.
– Avoid premature optimization, but flag designs that clearly will not scale.
– Prefer extracting common patterns into reusable components to reduce duplication
– Favor simplicity over complexity – remove unused exports, parameters, and code paths