The AGENTS.md checklist - rules every Codex session should follow

Audit your current AGENTS.md — check what you have and what needs upgrading

On Days 8 and 9 you built an AGENTS.md with six sections covering: About the project, How to communicate, Before touching any file, What not to change, After you finish, and Reusable skills. Today you are upgrading that foundation by strengthening the most important rules — particularly around identity, design protection, and how Codex validates its own work. Open your file and check each section: is it present, Are the rules inside it specific and active, or still vague placeholders, For each section, mark it as: Present and strong / Present but vague / Missing.

Compare weak rules to strong rules — then rewrite yours

Here are three before-and-after examples of weak rules becoming strong ones: Weak: "Be careful with files." Strong: "Do not change any file unless I name it in the current prompt. If you think you need to change an unlisted file, ask me first and wait." Weak: "Keep the design looking good." Strong: "Do not change any color value, font name, spacing value, or CSS class name that exists in the current design. If a layout change is required, describe it in plain English and wait for approval before editing." Weak: "Tell me what you did." Strong: "At the end of every task, list: (1) every file changed, (2) what changed in plain English, (3) anything you are not confident about, (4) the one next step I should take." Using these as a guide, rewrite the vague rules you found in Step 1. One specific rule is better than three vague ones.

Add the full five-section block if any sections are missing

If your audit found missing sections, add them now using this reference block. Copy only the sections you are missing — do not overwrite sections that already exist: ## Identity I am the sole owner of this project. I am not a developer. My role is to describe what I want in plain English and review what Codex does before approving it. Codex's role is to suggest, plan, and execute — never to decide alone. ## Safety rules - Write a plan and list every file you intend to change before touching anything. - Wait for me to say "go ahead" before making any edits. - Do not change files I did not mention in the current prompt. - If something goes wrong, say so immediately. Do not try to fix it silently. ## Design quality rules - Do not change any color, font, spacing, or layout unless I explicitly ask. - Do not rename CSS classes, design tokens, or component names. - If a design change is required to make something work, describe the trade-off and ask. ## Validation - After each task, show me the result in plain English: what changed and how I can see it. - If the task was a visual change, tell me where to look in the browser to verify it. - If you are not fully confident in a change, flag it with "REVIEW NEEDED." ## Final report At the end of every session, write: 1. Every file changed and what changed in plain English. 2. Anything you are not confident about. 3. The one next step I should take. 4. Anything I should NOT do until I review the changes.

Test the upgraded file — ask Codex to explain your rules back to you

The only way to know if your AGENTS.md rules are clear enough is to test them. Open a new Codex session. Paste the entire content of your updated AGENTS.md as the first message. Then type: "I have just given you my project rules in AGENTS.md. Before we do any work, explain back to me in plain English: (1) what you are not allowed to do without my permission, (2) what you must always do before editing a file, (3) what you must always include in your final report." Read the answer. If Codex explains all three correctly, your rules are clear. If it misses or softens a rule, that rule needs to be more direct.

Ask Codex to audit AGENTS.md and identify the one weakest rule

Open a fresh Codex session. Paste your full AGENTS.md content and then paste the prompt below exactly. Do not add extra context — let Codex read the file and make an honest assessment. The point is to get an outside view of your rules from the tool that will actually follow them. A rule that sounds strong to you may be ambiguous to Codex.