---
topic: examples
source_keys:
  - agents-md-official
  - context7-websites-agents-md
  - context7-agentsmd-agents-md
---

## Minimal Project Example

A practical AGENTS.md covering setup, code style, testing, and PR conventions for a pnpm monorepo:

```markdown
# AGENTS.md

## Setup commands
- Install deps: `pnpm install`
- Start dev server: `pnpm dev`
- Run tests: `pnpm test`

## Code style
- TypeScript strict mode
- Single quotes, no semicolons
- Use functional patterns where possible

## Dev environment tips
- Use `pnpm dlx turbo run where <project_name>` to jump to a package instead of scanning with `ls`.
- Run `pnpm install --filter <project_name>` to add the package to your workspace so Vite, ESLint, and TypeScript can see it.
- Check the `name` field inside each package's `package.json` to confirm the right name.

## Testing instructions
- Find the CI plan in the `.github/workflows` folder.
- Run `pnpm turbo run test --filter <project_name>` to run every check defined for that package.
- From the package root you can just call `pnpm test`. The commit should pass all tests before you merge.
- Fix any test or type errors until the whole suite is green.
- Add or update tests for the code you change, even if nobody asked.

## PR instructions
- Title format: [<project_name>] <Title>
- Always run `pnpm lint` and `pnpm test` before committing.
```

## Monorepo Nested Structure

Place AGENTS.md files at each scope level. Agents read the nearest file automatically:

```
my-monorepo/
├── AGENTS.md              # Root-level: applies to the whole repo
├── packages/
│   ├── api/
│   │   └── AGENTS.md      # API-specific instructions; overrides root for this package
│   ├── web/
│   │   └── AGENTS.md      # Web app-specific instructions
│   └── shared/
│       └── AGENTS.md      # Shared library instructions
```

Each sub-AGENTS.md can focus on the specifics of that package (framework, test runner, build tool) without repeating root-level conventions.

## What Agents Do with AGENTS.md

Agents actively use the file — they attempt to run listed test commands and fix failures before completing a task. Treat the instructions as live directives, not documentation. Keep the file updated as tooling and conventions change.