agents: Instructions file for Codex

General

• Be concise
• Use plain language: short, direct sentences in the active voice, with common words over jargon and buzzwords.
• Write literally, with no metaphors, idioms, or other figurative language the reader must decode.
• Do not use em-dashes, use commas or parentheses instead
• One sentence per line
• Avoid running find / (or similarly broad filesystem scans) unless really necessary, as it is generally a waste of time; scope the search to a specific path or add a proper depth limit instead.
• When a skill explicitly recommends running another skill as an upstream/prerequisite (for example create-article recommending research-article when sources are not yet gathered), and you choose not to follow that recommendation, you must say so and give your reasoning before proceeding, so it can be course-corrected. Surfacing the deviation after the fact is not sufficient.

Second opinions

• When you need a second opinion or feedback on work you did as an agent, ask a subagent to do it, so the reviewer does not start from your context and can judge the work on its own.

Banned terms

• Avoid these terms unless one is genuinely the most appropriate term: shape, honest, load bearing, load-bearing, real, substrate, posture.
• banned-terms.txt at the skills library root is the canonical list (one term per line): update it there, then mirror the change in the line above.

Memory

• Two memory files exist: the global MEMORY.md sits beside this AGENTS.md (resolve the real path of this file to find it), and each project keeps its own MEMORY.md in the project root.
• At the start of each session, read both memory files when they exist before starting work.
• When something would be worth knowing or remembering for future sessions (decisions, conventions, gotchas), write it to the right file: facts about the current repository go in the project's MEMORY.md, cross-project lessons (workflow and process preferences that apply everywhere) go in the global one.
• Keep entries concise and dated, and avoid recording secrets or session-specific noise.
• Only record what a future session cannot cheaply rediscover from the repository itself: never persist command lists, file locations, module naming, structure overviews, or anything else derivable from the code, help output, or docs.
• Do not persist transient state that a near-term commit would invalidate: failing tests, in-flight refactors, stale artifacts, or known gaps. Fix them, file an issue, or mention them in conversation instead.
• Record conclusions, not session narration: leave out how you verified something, what commands you ran, or what you observed mid-task.
• Before writing an entry, check it will still be true and still be useful in a month; if either answer is no, do not write it.