Free CLAUDE.md templates for teams

# <Project name>

<One sentence: what this repo is and who uses it.>

## Commands
- Install: `<command>`
- Run locally: `<command>`
- Test (all): `<command>`
- Test (one file): `<command> <path>`
- Lint and format: `<command>` (must pass before any commit)
- Never run: `<command>` (<why: e.g. resets the shared dev database>)

## Layout
- `<folder>/`: <what lives here>
- `<folder>/`: <what lives here>
- Reference implementation for new <services/components/endpoints>: `<path>`

## Ownership
| Area | Owner | Reviews required |
|---|---|---|
| `<folder>/` | <team> | <n>, at least one from <team> |
| `<folder>/` | <team> | <n> |

## Rules
- Follow the pattern in `<reference path>` for new <things>. Do not invent a new structure.
- <Database> schema changes: write the migration and open a PR. Never apply it directly.
- Anything touching <billing/auth/data deletion>: stop and ask before writing code.
- Dependencies: patch upgrades are fine. Minor or major upgrades need a separate PR.
- If you can't verify something (a command, an API, a config value), say "I haven't verified this" and stop.

## Standards
- Test coverage on new code: <n>% minimum
- <Language>-specific: <e.g. no `any` in TypeScript, type hints on all public functions>
- Commit messages: <convention, e.g. Conventional Commits>
- PR size: under <n> lines changed where possible

## Glossary
- **<Term>**: <what it means here>. Not "<banned synonym>".
- **<Term>**: <what it means here>.

## Definition of done
- Tests pass locally and the linter is clean
- The change follows the reference implementation
- The PR description explains what changed and why, in plain language

# <Service name>

<One sentence: what this service does and who depends on it.>

## Commands
- Test this service only: `<command>`
- Run it locally: `<command>`

## Rules for this folder
- Copy the structure of `<path to reference file>` for new <handlers/jobs/components>.
- Use `<internal library>` for <logging/HTTP/database access>. Not `<popular alternative>`.
- Never call `<external API or other service>` directly. Go through `<client module>`.
- Public interfaces in `<path>` are used by <other teams>. Changing them needs a review from <owner>.

## Gotchas
- <A non-obvious fact that has caused bugs before, e.g. "timestamps in this service are stored in UTC">
- <Another one>

# My preferences

## How I like to work
- Keep explanations short. Show the change first, then one line on why.
- Ask before running anything that deletes files or touches a remote.
- When there are several reasonable options, recommend one instead of listing them all.

## My environment
- Editor: <editor>
- Shell: <zsh/bash/fish>
- Package managers I use: <npm/pnpm/uv/...>

## Don't
- Don't add comments that restate the code.
- Don't reformat files you didn't otherwise change.

{
  "permissions": {
    "allow": [
      "Bash(<test command> *)",
      "Bash(<lint command> *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(<destructive command> *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}