Exact commands
Use copyable install, test, lint, and build commands—never “run checks when possible.”
Choose a repository shape. Compare the vague version with an operational file, see why each section exists, then copy the stronger example.
Improved example
# Repository instructions This repository is a user-facing web application built with React, TypeScript, and a server-side API. Preserve existing route, component, data-access, authentication, and design-system patterns. ## Start here - Read the target route, component, server handler, schema, and tests before editing. - Reuse installed UI primitives, tokens, and data clients before adding alternatives. - Keep the change scoped to the requested user flow. - Preserve user changes, the package manager, and the existing lockfile. ## Commands - `pnpm install --frozen-lockfile`: install dependencies. - `pnpm dev`: start the local application. - `pnpm test`: run tests. - `pnpm lint`: run lint checks. - `pnpm build`: type-check and create the production build. ## Interface rules - Use semantic HTML and accessible names for every interactive control. - Preserve keyboard access, visible focus, readable contrast, reduced motion, and narrow-screen layouts. - Include loading, empty, error, disabled, and success states when the flow can reach them. - Keep client state close to its consumer and derive values during render when possible. ## Server, data, and security - Validate untrusted input and enforce authorization at the server boundary. - Do not expose secrets, internal errors, or personal data in client bundles, responses, or logs. - Reuse established transaction and data-access patterns. - Do not create or apply migrations unless the task explicitly includes a reviewed schema change. ## Validation - Add focused coverage for the changed success and failure branches. - Run the narrowest relevant test first, then lint and the production build. - Verify the complete browser-to-server-to-data flow when a feature crosses those boundaries. ## Definition of done - The requested flow works end to end with keyboard, pointer, and touch where relevant. - Tests, lint, types, and the production build pass. - Authorization and data behavior are correct for both allowed and denied users. - The handoff states the behavior changed, checks run, and any deployment or migration risk.
Anatomy of a useful file
AGENTS.md has no required schema. The useful structure is the one that removes repository-specific guessing and makes completion observable.
Use copyable install, test, lint, and build commands—never “run checks when possible.”
Name the directories and packages that own behavior so new code lands in the right place.
Call out secrets, authorization, migrations, generated files, and destructive operations explicitly.
Keep root guidance broad and add nested files only where a subtree needs different rules.
Require the behavior, checks, and final evidence that prove the task is actually complete.
Delete generic advice the agent already knows; keep rules it cannot infer reliably from the code.
Stack-specific examples
Next.js
AGENTS.md template for Next.js
FastAPI
AGENTS.md template for FastAPI
React + Vite
AGENTS.md template for React + Vite
Turborepo
AGENTS.md template for a Turborepo monorepo
Django
AGENTS.md template for Django
Go
AGENTS.md template for Go
Rust
AGENTS.md template for Rust
Laravel
AGENTS.md template for Laravel
No. The official format is plain Markdown with no required fields. Use headings that make repository facts and rules easy to scan.
Start at the repository root. Add nested AGENTS.md files only when a subdirectory needs more specific instructions; the closest file to the edited code takes precedence.
README.md introduces the project to people. AGENTS.md holds operational details a coding agent needs before changing the repository, such as exact commands, boundaries, and validation.
No. Replace every assumed command, path, tool, and risk boundary with facts from your repository, then run the checker to find gaps.