--- title: Free AGENTS.md Generator slug: agents-md-generator last_reviewed: 2026-08-09 author: editorial source: LemAudit Free Tools --- ## Intro `AGENTS.md` is a plain markdown file at the root of a repository that tells coding agents how to work in it: how to install, how to run the tests, what the house style is, and which paths to leave alone. It is the same idea as a README, aimed at a different reader. A README explains the project to a person deciding whether to use it. AGENTS.md explains the project to something that is about to change it. The convention spread quickly because the alternative is worse. Without it, an agent infers your conventions from whatever files it happened to read, which means it will find one class component in a hooks codebase and write three more. With it, the rules are stated once and applied consistently. This generator asks a handful of questions and returns a structured file. It runs entirely in your browser; nothing you type is uploaded. ## What belongs in the file **Commands, above all.** The install, dev, test and build commands are the highest-value lines in the file, because they let an agent verify its own work instead of handing you code it never ran. If you include nothing else, include the test command. **A short summary.** Two or three sentences on what the project is and what it must not break. An agent uses this to judge whether a change is in scope. **Conventions.** State the decisions a newcomer could not infer safely. Not general advice — your specific rules. "All colours come from tokens in index.css" is useful. "Write clean code" is not. **Boundaries.** Generated directories, migration folders, vendored code, anything with a deployment side effect. Naming these prevents the most expensive category of mistake. **A pull-request checklist.** Agents follow explicit checklists far more reliably than prose. Four or five boxes covering tests, build, secrets and scope catches most of what reviewers would otherwise catch by hand. ## What to leave out Do not restate your README. If the file is long, the parts that matter get diluted. Do not include secrets, internal hostnames or anything you would not put in a public repository. The file is committed, and it is read by tools you may not control. Do not write aspirational rules. If half the codebase violates a convention, an agent reading the file will see the contradiction and follow the code, not the file. Fix the code or drop the rule. ## Nesting and precedence AGENTS.md applies to its own directory and everything below it. A file deeper in the tree overrides the one above it for that subtree, which is how monorepos give each package its own commands while sharing repository-wide conventions at the root. A direct instruction from a human beats both. The file sets defaults; the person in the conversation sets the task. ## AGENTS.md, llms.txt and robots.txt These three are often confused because all three are plain text files aimed at machines. They do different jobs. `robots.txt` tells crawlers which URLs they may fetch. It is about access. `llms.txt` tells language models which pages on your site are worth reading and how your content is organised. It is about discovery and citation. Our [llms.txt generator](/tools/llms-txt-generator) builds that one. `AGENTS.md` tells coding agents how to work in your repository. It is about contribution, and it lives in the repo rather than on the web. A public product might reasonably have all three, serving three different audiences. ## Keeping it accurate The failure mode of this file is staleness. A test command that changed six months ago is worse than no test command, because an agent will run it, see it fail, and start debugging your instructions instead of the task. Treat it like any other configuration: when the commands change, update the file in the same pull request. A short accurate file beats a thorough stale one every time. ## FAQ ### Is AGENTS.md a standard? It is a convention rather than a specification. Several agent tools read it, and more keep adopting it because the format is simple and there is no competing proposal. Nothing breaks if a tool ignores it. ### Do I need one for a small project? If any agent touches the repository, yes, and it can be short. Ten lines with the test command and three conventions already prevents most of the guessing. ### Should I commit it? Yes. Its value comes from travelling with the code, so every contributor and every tool sees the same rules. ### Can I have several in a monorepo? That is the recommended pattern. One at the root for shared rules, one per package for its own commands. The closest file to the code being changed wins. ### Will agents actually follow it? Mostly, and they follow concrete instructions far better than vague ones. Commands and checklists are followed almost always; broad stylistic principles less reliably. Write rules that can be checked. ### How is this different from a contributing guide? Same intent, different reader. A contributing guide explains process to humans: how to open an issue, how review works, the code of conduct. AGENTS.md gives an agent the operational facts it needs to make a correct change. Keep both if you have both audiences.