There's no official AGENTS.md template. The agents.md site describes the file as "a README for agents" and says there are no required fields: "Use any headings you like; the agent simply parses the text you provide." The template below is a starting convention built from the sections agents.md lists as popular choices (project overview, build and test commands, code style, testing instructions, security considerations), plus a definition of done and hard stops. Copy it, replace every placeholder, and delete any section you don't need. No tool checks these headings. They're context the agent reads.
Who this is for
You want an AGENTS.md in your repo today and don't want to start from a blank file.
The template
# AGENTS.mdProject overview <One or two sentences: what this repo is and who uses it.>
Build and test commands - Install: `<install command>` - Build: `<build command>` - Test: `<test command>` - Lint: `<lint command>`
Code style - <Language/framework conventions that differ from defaults> - <Naming rule the code doesn't make obvious>
Testing instructions - <Where tests live and how to run one file> - <What must pass before a change is done>
Security considerations - Reference secrets by environment variable name only: `<ENV_VAR_NAME>`. - <Data or systems the agent must not touch>
Definition of done - <e.g. tests pass, lint clean, change summarized in the PR description>
Hard stops - Ask before: <deploying, deleting data, sending messages, spending money> - Never: <edit generated folders, commit secrets> ```
How to fill it in
| Section | Fill with | Skip if |
|---|---|---|
| Project overview | One or two sentences | Never; keep it short |
| Build and test commands | Exact commands you run | The repo has no build |
| Code style | Only rules that differ from defaults | A linter already enforces them |
| Testing instructions | How to run tests and what must pass | No tests yet (add later) |
| Security considerations | Env var names, off-limits systems | Never |
| Definition of done | Checkable conditions | Never |
| Hard stops | Actions that need a human | Never |
For where the file lives in a monorepo and how nested files combine, see the project-structure guide rather than this template.
Pitfalls
- Leaving placeholders in. An agent can't act on `<test command>`.
- Treating hard stops as enforcement. They're instructions. If something must never happen, back it with a hook or permission setting too.
- Pasting a style guide. Cursor's rules guidance says to use a linter instead of copying entire style guides; the same logic keeps AGENTS.md short.
- Duplicating README.md. Human onboarding belongs there. See AGENTS.md vs README.
How to check it
- Search the file for `<` and confirm no placeholders remain.
- Run every command in "Build and test commands" and confirm each works.
- Ask an agent what counts as done in this repo and confirm it quotes your definition.
- Ask it to do something on your hard-stop list and confirm it asks first.
Where ShipKits fits
If you want more than one file, the Operator Pack ($47) is markdown seats + skills + install.sh — not a hosted app, not a chatbot. Seven named seats. Three skills. Ops playbook + token-cost playbook. Done means a file, PR, or URL. The zip includes "snippets for AGENTS.md + CLAUDE.md." For a free starting point, use /free. Cheat Sheet for the skim checklist mindset.
Soft next step
Paste the template, fill in the commands and hard stops, and run the four checks today. Free starter files are at /free. When you want the full set of templates, seats, and skills, the Operator Pack ($47) has them.