AGENTS.md / CLAUDE.md Generator — 20+ Ready-Made Templates
Generate project configuration files for Claude Code / Codex / Cursor / Windsurf / Gemini / GitHub Copilot with a single click from 20+ practical templates (Next.js / React / Vue / Django / FastAPI / Rails / Laravel / Go / Rust and more). Supports all 6 formats: AGENTS.md / CLAUDE.md / .cursor/rules/main.mdc / .windsurfrules / GEMINI.md / copilot-instructions.md with bulk zip download.
▶ 📦 Pick a template — instant generate
▶ 🎛 Operational Rule Packs 0 / 28
Add practical behavior rules for AI agents—such as "Get approval before touching production," "Always cite sources," and "Log progress"—with ON/OFF toggles. These are appended to the relevant section of the output file.
Commands
Code style
Anti-patterns
Important files / dirs
Testing
Other notes
📚 Template catalog
Show all 24 templates
📄 Generated config file
AGENTS.md
📍 Where to place
- AGENTS.md / CLAUDE.md / GEMINI.md → repo root
- Cursor → .cursor/rules/main.mdc
- Windsurf → .windsurfrules (root)
- Copilot → .github/copilot-instructions.md
📖 Where people get stuck
Generates project configuration files for Claude Code, Codex, Cursor, Windsurf, Gemini and GitHub Copilot from more than twenty templates, covering the six formats AGENTS.md, CLAUDE.md, .cursor/rules/main.mdc, .windsurfrules, GEMINI.md and copilot-instructions.md, downloadable together as a zip. Everything runs in the browser. A template, however, knows nothing about your repository — and an instruction file that is wrong produces worse outcomes than none at all. The agent follows it without doubting it, so a statement that does not match reality comes back to you as a wrong implementation.
| Case | What happens | What to do |
|---|---|---|
| Left as a template, it instructs things that are not true | A generated skeleton contains concrete statements that are not true of your project — it says tests run with npm test when you actually use pnpm, it describes a directory layout that does not exist, it lists conventions for libraries you do not use. An agent trusts the instruction file over the code — so it retries a documented command that does not work, and creates files in places that do not exist. The other waste is writing down what the code already shows — the framework in use and the folder names are things an agent can discover for itself in seconds. Every character spent there dilutes the information that actually matters. |
Write only what cannot be learned by reading the code. Concretely: the commands that actually work — the exact line for test, build, deploy and lint, the traps you have hit before and why, what must not be touched and why, and which of several possible approaches this project chose. Writing the why is the highest-value part — because a reason generalizes to situations you did not write down. In terms of process, you will get a better file by starting from an empty one and writing ten lines than by starting from a template. And the surest validation is to have an agent actually do some work and watch whether it followed the instructions — adding one line each time it hits a mistake is the realistic way to grow the file. |
| Emitting all six formats and letting them drift apart | Each tool reads a different file, so a team using several of them ends up with the same content in several places. The problem is that those copies invariably drift — someone updates only CLAUDE.md while .cursor/rules stays three months old, and the agent behaves differently depending on which tool you use. Worse, there is no mechanism that tells you they have diverged — both remain syntactically valid and CI still passes. The differences in how they are loaded matter too: some are read in full every time, some are consulted in part per request, some look only at the repository root while others also read subdirectory copies, and that difference surfaces as "for some reason only this tool ignores the instructions". |
Choose one canonical file. In practice the workable shape is to treat AGENTS.md as canonical and make the other formats short files that merely point at it — reducing CLAUDE.md to a single line saying to read AGENTS.md already eliminates the duplication (a symlink also works where the tool supports it). You do not need to emit every format — place only the ones for tools you actually use. And keep the canonical file at the repository root, under Git — put it in a personal settings directory and it becomes a rule that does not exist for anyone else on the team. Making it reviewable is what lets someone else check that its contents still match reality. |
| The longer it gets, the less it works | An instruction file consumes context on every single request — five hundred lines of rules means five hundred lines less room to read the actual code. And the longer it is, the more likely it contradicts itself: if "prefer the simplest implementation" and "always abstract" appear in the same file, which one wins is unpredictable. Another common failing is writing down aspirations — the state where the file says tests are mandatory while the repository contains no tests at all is very common. That contradiction confuses the agent, because it cannot decide whether to follow the existing code or the rule. And a rule that is visibly not followed lowers the credibility of every other rule. | Write it short, concrete, and in a form that can be checked. As a guideline, start with something that fits on one screen and add a line only when a problem occurs — trying to be comprehensive from the outset guarantees lines that never get used. Favour rules whose observance can be verified: "write readable code" cannot be checked, whereas "do not modify src/legacy/" can. And delete any rule the repository does not actually follow — if you want to state an ideal, bring the code to that state first, then write it down. Periodic review is needed too: if the build command changed and the file did not, the agent gets stuck at that point every single time — so when you change a command, fix this file in the same commit. |
Write this kind of file on the assumption that outsiders may read it. On a public repository anyone can, and even on a private one, it is transmitted to the model provider the moment you hand it to an agent — do not write internal hostnames, how your authentication works, or plans you have not announced. There is also a security property worth naming: an instruction file is an input that changes agent behaviour — an outsider who adds one line to it in a pull request can steer what your agents do afterwards. On a repository that merges external pull requests, always put diffs to these six files under review — they are less conspicuous than code changes and broader in effect. One operational note to close on: this file is not finished when you write it; it is something you update when the agent repeats the same mistake. When you notice you keep giving the same correction, that correction is the line that belongs in this file.
❓ Frequently Asked Questions
AGENTS.md vs CLAUDE.md?
What is Cursor MDC?
What if a template misses something?
Security?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.