These aren't drop-in files — they're real structural starting points for three project types that come up constantly on client work. Copy the shape, replace every placeholder with what's actually true for your project, and delete anything that doesn't apply.
No build step, no framework — the most common shape for a template-based client site
# Project: [Client Name] — Static Site
## Commands
- No build step — files are served as-is
- Lint/audit: python3 seo_tools/seo_audit.py (checks titles, meta, broken links)
- Deploy: wrangler pages deploy . --project-name [project-name]
## Conventions
- One HTML file per page, no templating engine
- Shared styles in /css/style.css — don't duplicate CSS inline
- Images go in /assets/img, always with real alt text
## Do Not Touch
- /legacy/old-landing.html — kept live for an existing ad campaign, do not modify or remove
## Client-Specific
- [Real conventions: brand colors, tone of copy, anything a newcomer wouldn't know]Real commands for tests, migrations, and environment setup
# Project: [Client Name] — API
## Commands
- Install: npm install
- Test: npm run test (runs against a local test DB, not production)
- Migrate: npm run migrate:up / npm run migrate:down
- Dev server: npm run dev (port 3001)
## Conventions
- Routes live in /src/routes, one file per resource
- All new endpoints need a corresponding test in /src/routes/__tests__
- Environment variables documented in .env.example — update it when adding a new one
## Do Not Touch
- /src/legacy-auth — old auth system still used by the mobile app, migration not started
## Client-Specific
- [Real conventions: naming patterns, required review process, deployment approval steps]Core-file boundaries and staging/production distinctions that don't exist on the other two
# Project: [Client Name] — WordPress
## Commands
- Local environment: [real local dev tool — e.g. Local, wp-env, Docker setup]
- No automated tests currently — manual QA on staging before any production push
## Conventions
- All custom code lives in the child theme (wp-content/themes/[theme]-child)
- Never edit the parent theme directly — changes there are lost on theme update
- Custom functionality goes in mu-plugins where possible, not functions.php
## Do Not Touch
- /wp-admin, /wp-includes, and any WordPress core files — no exceptions
- Do not touch active plugins without checking with [client/team] first — several are tied to paid licenses
## Client-Specific
- [Real conventions: staging URL, production deploy process, plugin approval process]The static site's CLAUDE.md is almost entirely about conventions, since there's no build process or dependency management to document. The API's is built around real commands — tests, migrations, environment variables — because those are the things that break silently if skipped. WordPress's is dominated by "do not touch," because the real risk there isn't a missing convention, it's editing something that gets silently overwritten or breaks a licensed plugin. Matching the file's shape to the project's real risk profile matters more than following one template exactly.
CLAUDE.md is one piece — hooks, subagents, MCP, and Skills all solve different problems. The free guide covers the fundamentals first if you're still getting oriented.
Get the Free Guide →No — they're structural starting points, not drop-in files. Replace every placeholder (commands, paths, conventions) with what's actually true for your project. A CLAUDE.md with commands that don't exist is worse than no CLAUDE.md.
Because the real constraints are different — a static site has no build step to document, an API has migrations and environment variables, a WordPress site has core-file boundaries that don't exist elsewhere. Copying one template's structure onto a different project type usually means documenting things that don't apply and missing the things that do.
Only what changes how the code should be written — a compliance requirement, a domain term with a specific meaning, a legal constraint. General business context that doesn't affect the actual work is better left out; it's not what CLAUDE.md is for.
Whenever something in it stops being true — a command changes, a convention shifts, a previously off-limits file becomes fair game. Treat it like any other piece of project documentation that goes stale if ignored.