What to provide
Repository structure, stack, commands, architecture, approval rules, release targets, and existing instruction files.
What you will get
A root AGENTS.md, scoped instruction plan, compatible CLAUDE.md, validation checklist, and maintenance rules.
Example: Codex uses AGENTS.md. Claude Code commonly uses CLAUDE.md, so keep detailed rules in one source and make the other file a short compatibility guide.
Copy the full prompt
Customize the bracketed fields.
Use approved business information and have a person review the result before acting.
Help create repository instructions for both Codex and Claude Code.
Repository and stack: [details]
Important folders and owners: [paths and responsibilities]
Install, build, test, lint, and run commands: [commands]
Architecture and data flow: [summary]
Release targets and branches: [details]
Approval boundaries: [database, secrets, production, destructive actions, or other rules]
Existing AGENTS.md, CLAUDE.md, README, or policy files: [paths or approved excerpts]
First inspect the existing repository instructions and resolve conflicts without discarding stricter rules. Treat AGENTS.md as the detailed source for Codex. Create a concise CLAUDE.md for Claude Code that restates only the essential entry instructions and directs maintainers to the same canonical repository rules, rather than maintaining two divergent copies. Recommend scoped AGENTS.md files only where a subdirectory needs different commands or constraints.
Draft:
1. A root AGENTS.md covering product purpose, source-of-truth order, repository map, setup commands, architecture constraints, coding standards, security and data rules, approval boundaries, testing, runtime evidence, release procedure, documentation, and definition of done.
2. Any necessary scoped AGENTS.md files, with their paths and inherited rules.
3. A short compatible CLAUDE.md that explains the canonical rules and Claude-specific commands only when they truly differ.
4. A maintenance checklist that prevents conflicting instructions and stale commands.
Do not invent commands, paths, permissions, environments, or policies. Mark unknowns [TO CONFIRM]. Do not install tools, change configuration, create credentials, modify databases, or deploy. Return proposed file contents and explain which file owns each rule before implementation.
Response requirements:
- Begin with a short summary of the goal, confirmed facts, assumptions, and missing information.
- Ask focused clarification questions before completing the work when a missing answer would materially change the result.
- Use clear headings, tables, checklists, or numbered steps where they make the output easier to use.
- Keep source facts separate from recommendations. Quote or cite supplied evidence when the task depends on source material.
- Mark unsupported details, decisions, owners, dates, costs, credentials, and commitments as [TO CONFIRM].
- Identify the three most important risks, failure conditions, or quality checks.
- End with a practical next-action checklist that names the responsible role and the evidence needed to confirm completion.
- Include a final self-review: check the answer against this prompt, list any unmet requirement, and correct it before responding.
- Do not claim that you accessed a system, verified an external fact, completed an action, or tested the result unless evidence in this conversation proves it.Version 1.0 · Updated 2026-10-10 · Free starter template. Evaluate the output in your approved environment.