If I have to explain the same repository boundary every time I open a coding session, that information belongs beside the code. The assistant needs to know which project it is changing, what owns the behaviour and how I expect the result to be checked.
By late 2025, Codex supported repository instructions in AGENTS.md, while Claude Code used CLAUDE.md. They are useful places for working conventions. They are not a replacement for filesystem permissions, a test suite or reading the diff.
Write down the facts that prevent wrong turns
Start with the details someone new to the project would struggle to infer: the source directory, generated output, the real build command and the route to a test environment. A folder full of sites needs a clear instruction to locate the intended repository before editing anything.
# Working on this project
Locate the requested application before changing files.
Read the instructions in that application's directory.
Check git status and preserve unrelated changes.
Edit source files, then use the documented build command.
Run the checks relevant to the behaviour being changed.
Report what was changed, checked and left unresolved.
Follow the existing deployment instructions.This example is a starting point, not a universal configuration. Add actual commands after checking them in your project. A convincing but obsolete command in an instruction file can waste more time than a missing one.
Keep both tools aligned
I would keep the shared working rules in one short project document and tell each tool to read it through its own instruction file. Alternatively, maintain two small files together. Do not assume Claude automatically reads a Codex-specific file, or that both tools resolve instructions in precisely the same way.
Keep task-specific requests in the task. A permanent rule saying to optimise every file you touch can turn a small bug fix into an unreviewable rewrite. A permanent rule explaining which directory contains generated assets is useful on almost every visit.
Describe a check, not an aspiration
My December 2025 WordPress work included escaping JSON emitted into page markup. That is a useful example of the difference between “make it secure” and a concrete verification instruction. Identify where the value enters the page, use the appropriate encoding for that context, and inspect the resulting output with a value that would otherwise break the markup.
The commit records the code change. It does not establish which assistant was involved or prove every surrounding page was tested. Keep those distinctions in the agent's report too.
Make larger tasks resumable
For work spanning several sessions, use a small progress document: the objective, decisions made, evidence collected and next action. OpenAI's October 2025 planning example already described keeping a plan with the repository. A useful handover should let a fresh session continue without reconstructing the entire conversation.
Review instructions when they cause repeated confusion. Remove duplicates, correct stale commands and keep the important boundaries easy to find. Then use a clear brief to describe the particular job.