Claude Code templates — what they are and how to use them

What people actually mean by "Claude Code templates"

The phrase covers three different things that are often conflated, and picking the wrong one wastes time.

CLAUDE.md is a Markdown file that Claude Code reads automatically at the start of every session. It's the place for facts that don't change: your stack, your coding conventions, your test commands, constraints Claude should never forget. Without it, Claude starts every session blind — not knowing your framework, your naming patterns, or how to run your tests.

Slash commands (also called custom commands or skills) are reusable prompt templates stored as Markdown files in .claude/commands/ or .claude/skills/. You trigger them by typing /name in the chat. Unlike CLAUDE.md, they're not always in context — they only load when you call them. That makes them the right home for repeatable procedures: a code-review checklist, a PRD draft, a release-notes generator.

Project starter kits are full directory structures — a scaffold that includes a pre-written CLAUDE.md, a set of commands, and sometimes hooks and settings — designed so you can clone them into a new project and immediately have a configured Claude Code environment instead of building one from scratch.

Most of the confusion online ("what goes in CLAUDE.md vs a skill?") comes from treating these as alternatives. They're not. A well-configured project uses all three.

CLAUDE.md: the persistent context file

Every Claude Code project should have a CLAUDE.md at its root. When Claude starts a session, it reads this file first. Anything you'd normally spend the first message explaining — your stack, your preferred patterns, commands Claude needs to know — belongs here.

The key structural insight from Anthropic's own best practices: CLAUDE.md holds facts, not procedures. If a section of your CLAUDE.md is starting to look like a step-by-step runbook ("first run X, then check Y, then..."), that section belongs in a skill instead.

A practical CLAUDE.md for a Next.js project looks like this:

## Stack
Next.js 15, TypeScript, Tailwind v4, Postgres via Drizzle.
 
## Commands
- `pnpm dev` — start dev server (port 3000)
- `pnpm test` — run Vitest suite
- `pnpm db:push` — push schema to local DB
 
## Conventions
- Use server components by default; mark `"use client"` only when needed
- Route handlers live in `src/app/api/`; never put business logic in them
- All DB access goes through `src/lib/db.ts`
 
## Never do
- `npm` or `yarn` — this project uses `pnpm`
- Modify `src/app/layout.tsx` without checking the auth flow

This is short, specific, and immediately useful — Claude reads it and knows your project without a single explanatory message. Contrast that with a 500-line CLAUDE.md stuffed with generic advice about writing clean code: Claude already knows how to write clean code. That line adds no value; it just inflates token cost every session.

Three scope levels matter: global (at ~/.claude/CLAUDE.md — rules for every project you ever work on), project (at .claude/CLAUDE.md in your repo root — shared with anyone who clones the repo), and local (at .claude/CLAUDE.local.md — personal overrides that stay gitignored). Keep global lean; be specific in project scope.

Slash commands: reusable prompts by name

Custom slash commands let you package a long, specific prompt into a short trigger. Store a Markdown file at .claude/commands/review.md and /review becomes available in every session on that project. Teammates who clone the repo get the same commands automatically.

Where CLAUDE.md is always active, a slash command is on-demand. That's its purpose: procedures you run sometimes, not facts Claude needs every session.

A few command types that consistently deliver value for makers and PMs:

Pre-commit check (.claude/commands/precommit.md): "Scan the staged diff for TODOs, commented-out code, hardcoded secrets, and test flags. List each finding with a file and line number. Don't fix — just report." Running this before every commit catches things that pass linting but are still bad practice.

PRD from notes (.claude/commands/prd.md): "Read the contents of notes/feature-brief.md and produce a structured PRD: problem statement, user stories, success metrics, open questions. Use our standard template in templates/prd-template.md." For a PM, this turns scattered meeting notes into a shareable document in under a minute.

Release notes (.claude/commands/release-notes.md): "Read `git log --oneline $(git describe --tags --abbrev=0)..HEAD` and produce a changelog for this release. Group changes into Added, Changed, Fixed. Write for an end user, not a developer." Most release notes are written by developers for developers; this prompt forces a reframe.

The practical limit of custom commands is discoverability. A project with 15 slash commands that nobody documented requires every new teammate to run /help and guess. The commands that actually get used are the ones that have an obvious name and a one-line comment at the top of the Markdown file explaining what they do and when to use them.

Project starters: configured environments you clone

Starting a new project with Claude Code typically means 20–30 minutes setting up your CLAUDE.md, your first few commands, your hooks, and your settings before you can write any real code. Project starters compress that to under a minute.

The most-used community starters are on GitHub under the claude-code-template topic. A starter typically includes:

• A pre-written CLAUDE.md with placeholder sections for your stack and conventions
• A .claude/commands/ folder with a baseline set of commands
• A settings.json with a sane set of tool permissions
• Sometimes hooks that run automatically on file changes or before commits

The Claude Code Mastery Starter Kit and the aitmpl.com component library (400+ agents, commands, settings, hooks) are the two most referenced community resources. The community platform lets you pick individual components rather than taking an entire starter wholesale — useful when you already have a project structure and want to add specific commands without rebuilding from scratch.

One gotcha: the best starters are stack-specific. A generic starter that covers all frameworks hedges everything and excels at nothing. If you're building a Next.js app, find a Next.js-specific starter; the pnpm dev vs npm run dev distinction alone saves you correcting Claude in the first message of every session.

What makers and PMs actually put in templates

The use patterns differ noticeably by role.

Makers (indie hackers, solo devs, technical founders) tend to front-load CLAUDE.md with the things that take longest to re-explain: the architecture decisions ("we use server actions, not API routes, because..."), the environment quirks ("the local DB needs a seed before tests pass"), and the things Claude tends to get wrong on this specific project ("the user table has an external_id column that's not the primary key — always use id for joins"). The return on this investment compounds: a well-tuned CLAUDE.md gets better every week as you add gotchas.

PMs tend to get more value from slash commands than from CLAUDE.md, because their use of Claude Code is more episodic: "draft a PRD," "summarize this research," "write release notes." A PM who never writes code can still have a powerful Claude Code setup with five well-designed commands and a CLAUDE.md that holds the product context — the business model, the target user, the tone.

The crossover skill: both groups underestimate how much value comes from pointing Claude at real files rather than describing them in prose. "Read notes/sprint-16.md and draft a standup update" produces better output than "Write a standup update based on these features I'm about to describe." Templates that reference real files in the repo are substantially more useful than templates that rely on ad-hoc descriptions.

Where templates fall short

Templates solve the input side of the problem well. They don't solve the output side.

A slash command that generates a PRD doesn't tell you what to do with the PRD after it exists. It's sitting in your terminal. If a stakeholder needs to read it and leave feedback, your options are: export it to a doc, paste it into Slack, screenshot it, or email it as text. None of those options let the reviewer point at a specific line and leave a note — which means feedback comes in as vague "looks good to me" or "can you change the second section?" messages that require you to re-locate the right part yourself.

The same pattern appears with any template that produces a real deliverable: a design brief, a competitive analysis, a feature spec. Templates get the generation right; the review loop is still an afterthought.

The pattern worth building: template generates the artifact, the artifact gets pushed to a link, stakeholders annotate specific spots, the agent reads the annotations and ships a revision. Templates handle step one. A review layer handles step two.

The one thing most CLAUDE.md files get wrong

The most common mistake is filling CLAUDE.md with general best practices — "write clean, maintainable code," "add comments to complex logic," "prefer composition over inheritance." Claude already knows these. Every token spent on general advice is a token not spent on something Claude actually can't know: your project's specific structure, your deployment commands, the decisions your team made that aren't obvious from the code.

Andrej Karpathy's CLAUDE.md template (5,000+ GitHub stars, widely copied) illustrates the inverse: it contains no generic advice about code quality, only project-specific facts and constraints. The template's popularity is partly a signal: developers recognize that specificity is the return, not volume.

The practical test: read each line of your CLAUDE.md and ask "could this be Claude's default behavior?" If the answer is yes, delete the line. What remains should be the things Claude can only know because you told it.