Free templates

CLAUDE.md templates and examples

A CLAUDE.md file tells Claude Code how your project works: the commands to run, where code lives and the rules to follow. Here is a blank template plus five annotated examples. Save them as AGENTS.md for Codex and Cursor. No signup.

Blank CLAUDE.md template

Blank CLAUDE.md template

# [Project name]

One sentence: what this project is and who it is for.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `[command]`
- Dev server: `[command]`
- Test: `[command]`
- Lint and typecheck: `[command]`

## Structure
- `[folder]/`: [what lives here]
- `[folder]/`: [what lives here]

## Conventions
- [Language, framework and version the agent must assume]
- [Naming, formatting or file layout rules the linter doesn't catch]
- [How data is read and written: one helper, one client, one place]

## Rules
- Run the tests and typecheck before saying a task is done.
- Ask before adding a dependency.
- Do not edit: [generated files, migrations already applied, vendored code]
- Never commit secrets. Env vars live in [.env.local], documented in [.env.example].

## Gotchas
- [The thing that broke last time, and what to do instead]

What goes in a CLAUDE.md file

Six short sections. Leave out anything the agent can learn by reading the code or that a linter already enforces.

  1. 1

    One-line summary

    What the project is, plus a pointer to docs/PRD.md so the agent plans from your scope.

  2. 2

    Commands

    Exact install, dev, test and lint commands. The agent runs these instead of guessing.

  3. 3

    Structure

    The few folders that matter and the single place each kind of code lives.

  4. 4

    Conventions

    Only what a linter can't enforce: versions, data access, formats.

  5. 5

    Rules

    What the agent must do before calling a task done, and what it must ask about first.

  6. 6

    Gotchas

    The mistake that already cost you an hour. Add one each time it happens again.

5 CLAUDE.md examples

Each one is filled in for a small, realistic project and points to a PRD in docs/PRD.md. The notes under each file explain the lines that matter most.

Next.js SaaS

App Router, Postgres, Stripe and auth. The most common indie SaaS setup.

CLAUDE.md: Next.js SaaS

# Invoice chaser

A SaaS that emails polite payment reminders for overdue freelance invoices.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `pnpm install`
- Dev server: `pnpm dev` (http://localhost:3000)
- Test: `pnpm test`
- Lint and typecheck: `pnpm lint && pnpm tsc --noEmit`
- DB migration: `pnpm db:migrate` (never edit a migration that has already run)

## Structure
- `app/`: routes (App Router). Server components by default.
- `app/api/`: route handlers. Webhooks live in `app/api/webhooks/`.
- `lib/db.ts`: the only database client. Import it; don't create another.
- `lib/stripe.ts`: Stripe client and price IDs.
- `emails/`: email templates.

## Conventions
- TypeScript strict. No `any`.
- Add `"use client"` only to components that need state or browser APIs.
- Validate every request body with zod before it touches the database.
- Money is stored in cents as integers.

## Rules
- Run lint, typecheck and tests before saying a task is done.
- Ask before adding a dependency.
- Verify the Stripe signature on every webhook before reading the payload.
- Never commit secrets. Env vars live in `.env.local`, documented in `.env.example`.

## Gotchas
- Stripe can send the same webhook event more than once. Handlers must be idempotent (check the event ID).
  • "The only database client" stops the agent from creating a second connection pool in a new file.
  • Money in cents and idempotent webhooks are the two bugs agents write most often in billing code.
  • The migration rule protects the one kind of file you can't safely regenerate.

Python CLI

A command line tool packaged with uv, typed, tested with pytest.

CLAUDE.md: Python CLI

# csvdiff

A command line tool that shows row-level differences between two CSV files.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `uv sync`
- Run: `uv run csvdiff a.csv b.csv`
- Test: `uv run pytest`
- Lint and format: `uv run ruff check . && uv run ruff format .`
- Typecheck: `uv run mypy src`

## Structure
- `src/csvdiff/cli.py`: argument parsing only. No logic here.
- `src/csvdiff/core.py`: the diff logic, pure functions.
- `tests/`: one test file per module. Fixtures in `tests/data/`.

## Conventions
- Python 3.12. Type hints on every function.
- Standard library first. Ask before adding a dependency.
- Errors go to stderr with a non-zero exit code. Output goes to stdout so it can be piped.

## Rules
- Write a failing test before fixing a bug.
- Run pytest, ruff and mypy before saying a task is done.
- Don't change the output format without asking: people pipe it into other tools.

## Gotchas
- Large files: stream rows, never load a whole file into memory.
  • Splitting cli.py from core.py keeps the logic testable without spawning a process.
  • "Output goes to stdout" matters because agents tend to print status messages that break piping.
  • Pinning the Python version stops the agent from reaching for syntax your users can't run.

Chrome extension

Manifest V3 with a service worker, content script and popup.

CLAUDE.md: Chrome extension

# Tab timer

A Chrome extension that shows how long each tab has been open and closes stale ones on request.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `npm install`
- Build: `npm run build` (outputs to `dist/`)
- Watch: `npm run dev`, then load `dist/` at chrome://extensions with Developer mode on
- Test: `npm test`

## Structure
- `src/background.ts`: the service worker. Event listeners only.
- `src/content.ts`: runs in web pages. Keep it small.
- `src/popup/`: the popup UI.
- `manifest.json`: Manifest V3.

## Conventions
- Manifest V3 only. No background pages, no remote code.
- The service worker can stop at any time: keep state in `chrome.storage`, not in variables.
- Messages between scripts use one typed message format defined in `src/messages.ts`.

## Rules
- Ask before adding a permission to manifest.json. Every permission shows a warning to users and slows store review.
- Never load scripts from a CDN. Chrome Web Store policy blocks remotely hosted code.
- Run the build and tests before saying a task is done.

## Gotchas
- A listener registered inside an async callback may never fire after the worker restarts. Register listeners at the top level.
  • The permissions rule is the one that saves you: agents add "tabs" and "<all_urls>" by default.
  • Service workers losing in-memory state is the most common Manifest V3 bug.
  • Naming the store's remote-code policy keeps the agent from pulling a library from a CDN.

MCP server

A TypeScript Model Context Protocol server with a few tools.

CLAUDE.md: MCP server

# linear-lite MCP

An MCP server that lets an AI agent search, create and close issues in a small issue tracker.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `npm install`
- Build: `npm run build`
- Test: `npm test`
- Try it: `npx @modelcontextprotocol/inspector node dist/index.js`

## Structure
- `src/index.ts`: server setup and transport (stdio).
- `src/tools/`: one file per tool, each exporting its schema and handler.
- `src/api.ts`: the only HTTP client for the tracker's API.

## Conventions
- Uses the official `@modelcontextprotocol/sdk` package.
- Every tool has a zod input schema and a one-line description written for the model.
- Tool names are verbs: `search_issues`, `create_issue`, `close_issue`.
- Return short, structured text. Don't dump raw API responses.

## Rules
- With stdio transport, never write to stdout except through the SDK. Logs go to stderr.
- Tools that change data must say so in their description.
- Read the API key from an env var. Never hard-code it or log it.
- Run the build and tests before saying a task is done.

## Gotchas
- A stray `console.log` corrupts the stdio stream and the client disconnects without a clear error.
  • The stdout rule is the most common reason a new MCP server "just doesn't connect".
  • Descriptions written for the model decide whether the agent picks the right tool.
  • Short, structured returns keep tool output from filling the model's context.

Mobile app (Expo)

React Native with Expo Router, for iOS and Android from one codebase.

CLAUDE.md: Mobile app (Expo)

# Plant water log

An iOS and Android app that reminds you when each plant needs water.
Read docs/PRD.md before planning. Build only what is in its MVP scope.

## Commands
- Install: `npx expo install` (use this, not npm install, for native packages)
- Dev: `npx expo start`
- Test: `npm test`
- Typecheck: `npx tsc --noEmit`

## Structure
- `app/`: screens (Expo Router, file-based routes).
- `components/`: shared UI.
- `lib/storage.ts`: local data. The only place that reads or writes it.
- `lib/notifications.ts`: scheduling reminders.

## Conventions
- TypeScript strict.
- Works offline. Local storage is the source of truth; there is no backend in v1.
- Styles with StyleSheet. Respect the safe area on every screen.

## Rules
- Ask before adding a package with native code. It may need a new development build.
- Test on both iOS and Android before saying a UI task is done.
- Don't touch `ios/` or `android/` folders by hand if they exist; change app.json instead.

## Gotchas
- Scheduled notifications need permission first. Ask at the moment the user sets their first reminder, not on launch.
  • "expo install" picks package versions that match your Expo SDK. Plain npm install often doesn't.
  • Stating "no backend in v1" stops the agent from setting up a server you didn't plan for.
  • The permission-timing note is an App Store review and conversion detail that agents skip.

How to write a CLAUDE.md file

  1. 01

    Start small

    Run /init in Claude Code or copy a template below, then cut every line that isn't specific to your project. The file is read at the start of every session, so every line costs context.

  2. 02

    Write commands the agent can run

    Exact commands beat descriptions. "pnpm test" is better than "run the tests", and it lets the agent check its own work.

  3. 03

    Point it at the PRD

    One line, "Read docs/PRD.md before planning. Build only what is in its MVP scope", keeps the agent working on your plan instead of its own ideas.

  4. 04

    Turn repeated corrections into rules

    When you correct the agent the same way twice, write the correction down. That is what the Rules and Gotchas sections are for.

  5. 05

    Keep it in git

    Commit the file so everyone on the project, and every agent session, gets the same instructions. Review changes to it like code.

One file for Claude Code, Codex and Cursor

Codex, Cursor and several other agents read AGENTS.md. Claude Code reads CLAUDE.md. To keep one set of instructions, put everything in AGENTS.md and make CLAUDE.md a single line:

@AGENTS.md

Setting up the rest of the toolchain? aistack.sh, our directory of AI dev tools, lists the MCP servers, skills and plugins people pair with Claude Code.

Questions

What is a CLAUDE.md file?

CLAUDE.md is a Markdown file that Claude Code reads automatically at the start of a session. It holds project instructions: commands, structure, conventions and rules, so you don't have to repeat them in every prompt.

Where do I put CLAUDE.md?

In the root of your repository for project instructions that you commit and share. A CLAUDE.md in ~/.claude/ applies to all your projects, and a CLAUDE.md inside a subfolder adds instructions when Claude works in that folder.

What is the difference between CLAUDE.md and AGENTS.md?

They do the same job for different tools. AGENTS.md is a shared format read by Codex, Cursor and other coding agents; Claude Code reads CLAUDE.md. To keep one source of truth, write AGENTS.md and make CLAUDE.md a single line: @AGENTS.md, which imports it.

How long should a CLAUDE.md be?

As short as it can be while still being specific. Each template on this page is under 50 lines. Long files use up context and bury the rules that matter; move detailed docs into separate files and import them with @path when needed.

Can Claude Code write the CLAUDE.md for me?

Yes. Run /init in your project and Claude Code drafts one from your codebase. Treat it as a first draft: cut the generic lines and add your rules and gotchas.

Do these templates work with Cursor or Codex?

Yes. Save the same content as AGENTS.md. Nothing in the templates is specific to Claude Code.

Get new templates by email
Optional. One email when we publish a new free template or checklist.