Exemples d'instructions repo pour Codex
Exemples d'instructions repo qui aident Codex à respecter architecture, tests, règles sécurité et contraintes produit.
Reponse rapide
De bonnes instructions repo Codex décrivent frontières d'architecture, commandes, règles sécurité, formatage attendu et fichiers à ne pas toucher.
Exemples
Inclue les règles d'ownership auth, accès env, migrations, tests, contraintes copy, commandes de déploiement et fichiers générés.
Vérification du risque
Les instructions deviennent nocives quand elles sont vagues, obsolètes ou en conflit avec les scripts réels du package.
FAQ
Que doivent inclure les instructions repo ?
Elles doivent inclure commandes de travail, règles d'architecture, contraintes sécurité et zones spécifiques à ne pas toucher.
Écrire des instructions repo
Guides associés
CLAUDE.md : le guide de tout développeur
Un fichier markdown pour donner à Claude Code les conventions réelles de ton codebase et obtenir du code cohérent dès la première session.
Claude Code peut écrire du code propre dans un projet, puis sortir du code générique dans le suivant. Dans mon expérience, la différence vient souvent de CLAUDE.md . C'est le fichier qui évite de répéter les mêmes conventions à chaque session, et c'est une grosse partie de mon gain avec Claude Code. Ce que c'est CLAUDE.md est un fichier markdown que Claude Code lit au début de chaque session. Pense y comme le doc d'onboarding que tu donnerais à un prestataire senior le premier jour : stack, conventions, règles, contexte. Sans ça, Claude infère les patterns depuis ce qu'il voit dans le codebase. Parfois il tombe juste. Souvent non, surtout pour les conventions implicites que ton équipe connaît sans les avoir écrites. Avec un bon CLAUDE.md , Claude produit du code qui suit tes règles sans avoir besoin de le répéter à chaque fois. Quoi y mettre 1. Stack et…
Lire le 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…
Lire le 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…
Lire le guide