Codex repo instructions examples
Examples of repo instructions that help Codex respect architecture, tests, security rules and product constraints.
Quick answer
Good Codex repo instructions describe architecture boundaries, commands, security rules, formatting expectations and what files the agent must not touch.
Examples
Include rules for auth ownership, env access, migrations, tests, copy constraints, deployment commands and generated files.
Risk check
Instructions become harmful when they are vague, outdated or conflict with the actual package scripts.
FAQ
What should repo instructions include?
They should include the working commands, architecture rules, security constraints and project-specific no-touch zones.
Write repo instructions
Related guides
CLAUDE.md: A Guide for Every Developer
One markdown file that makes AI coding assistants actually understand your codebase. Here's what to put in it.
There's a reason Claude Code writes great code in some projects and generic boilerplate in others. It's not the model. It's CLAUDE.md . It is one part of my Claude Code workflow: project conventions reduce guesswork, but they do not guarantee a speedup or remove the need to review the change. What it is CLAUDE.md is a plain markdown file that Claude Code reads at the start of every session. Think of it as the onboarding doc you'd give a senior contractor on day one: stack, conventions, rules, context. Without it, Claude infers patterns from what it sees in the codebase. Sometimes it infers correctly. Often it doesn't especially for implicit conventions your team just "knows". With a good CLAUDE.md , Claude outputs code that follows your rules without being told each time. What to put in it 1. Stack and versions Simple but important. Claude will use the right…
Read the guideClaude Code Agents: When to Use Them
Claude Code Agents (subagents) let you spawn isolated work threads from the main session. Full guide: what they are, when to use them, how to write a custom one, and the patterns that actually ship.
Claude Code is great when you're driving one thread of work. When you need to run three threads in parallel, or want a fresh pair of eyes on a decision, or need to scope out a large refactor without polluting your main session that's what Agents are for. This is what Claude Code Agents actually are, when to use them, and how to write your own. What Claude Code Agents actually are An Agent (sometimes called a subagent) is an isolated work thread you spawn from the main Claude Code session via the Agent tool. It has its own context fresh, with no visibility into your conversation. You hand it a self contained prompt; it does the work; it returns a single message at the end. Three things make this different from just asking Claude another question: 1. Isolated context. The agent doesn't see what you've been doing. It can't…
Read the guideClaude Code MCP: Connect Servers & Tools
Claude Code MCP (Model Context Protocol) lets you plug external tools and data into Claude. Full guide: how to add an MCP server, list available ones, and the patterns that work.
A Claude Code conversation can only do so much with the tools shipped in the box. The moment you want Claude to touch Notion, Stripe, your AWS account, a specific database you need MCP. MCP (Model Context Protocol) is the standard that connects Claude to external tools. Here's what it is, how to add servers, and the patterns that don't waste your time. What MCP actually is MCP is an open protocol. A small server process (the "MCP server") exposes a set of tools. Claude Code (the "MCP client") talks to it over stdio or HTTP. When Claude needs to call one of those tools, it sends a JSON RPC request; the server runs the function and returns the result. Three pieces: MCP server the process that exposes tools. Usually npx installable. Examples: filesystem, GitHub, Notion, Stripe, Postgres. MCP client Claude Code itself. It manages connections, surfaces tools to the…
Read the guide