Claude Code templates: the 5 files I'd copy into every project

When people ask me for Claude Code templates, they usually want one magic file. There isn't one. A working setup is a handful of small files, each with a narrow job, and most of the value is in what you write inside them.

Below are the five templates I would copy into any new project, in the order I would add them. Every example is a starting point. Swap my placeholders for your own business before you use it.

Which Claude Code templates do you actually need?

You need five Claude Code templates: CLAUDE.md, a skill, a subagent, settings.json and .mcp.json. That covers memory, procedures, delegation, safety and access. You do not need all five on day one.

The split matters because each file loads at a different moment. CLAUDE.md is always there. A skill loads only when a task matches. A subagent runs somewhere else entirely. Mixing them up is the most common reason a setup feels slow or forgetful.

What goes in a CLAUDE.md template?

A CLAUDE.md template should hold what is true on every task: what this is, who it serves, where things live, how to run things and what never to do. Nothing more. If a line only matters for one task, it belongs in a skill.

Running /init gives you a first draft based on the code. It does not know your customers or your rules. This is the structure I start from:

# Project: <name>

## What this is
<One paragraph. What the business or project does and for whom.>

## Where things live
- content/      Articles and pages
- scripts/      Small tools, run with python3
- clients/      One file per client with notes and contacts

## Commands
- npm run build   Build and validate. Must pass before anything goes live.
- npm run dev     Local preview

## How we work
- American English. Short sentences. No jargon.
- Drafts only. A human sends, publishes and deletes.
- When unsure about a fact, ask. Never invent numbers or quotes.

## Never
- Touch .env or anything in .secrets/
- Push to main or deploy without being asked

Two things make this work. Keep it short, because it is read on every request. And write it about your work, not about Claude. "Be helpful and thorough" adds nothing. "Prices are in content/site.ts, never hardcode them" saves you a correction every week.

You can also keep a personal ~/.claude/CLAUDE.md for things that are true in every project, like your writing style or the tools you use. If you want to see how far that memory can go in a business, here is my own setup.

What does a good skill template look like?

A good skill template is a folder with a SKILL.md file: a name and a description in the frontmatter, then numbered steps. The description decides whether Claude ever uses it, so it must say what the skill does and when.

---
name: meeting-prep
description: Prepares a one-page brief before a call. Use when asked to prep for a meeting, a call or a specific person.
---

# Meeting prep

1. Find the person or company in clients/ and in recent email.
2. Summarize what was agreed last time and what is still open.
3. Write the brief using brief-template.md in this folder.
4. End with three questions I should ask.
5. Under 300 words. No guessing: mark anything you could not verify.

Custom slash commands now live inside skills, so this file also gives you a /meeting-prep command. Descriptions, limits and common mistakes get their own piece: how to write a skill that gets used.

What does a subagent template look like?

A subagent template is a single Markdown file in .claude/agents/ with a name, a description, the tools it may use and optionally a model, followed by its instructions. Use one when a task needs a lot of reading that should stay out of your main session.

---
name: inbox-scanner
description: Reads recent email and returns only what needs a reply today. Use when asked to check, triage or summarize the inbox.
tools: Read, Grep, Glob
model: haiku
---

You triage email. Read the messages you are given.
Return a list with: sender, one-line summary, and whether it needs a reply today.
Do not draft replies. Do not open attachments. Under 200 words.

Notice the tools line. This one can only read. Start every subagent that narrow and widen it only when a task proves it needs more. For when a subagent beats a skill, read when to use subagents.

What should settings.json contain?

Your .claude/settings.json should contain two things: permissions that say what Claude may do without asking and what it may never do, and hooks that run your own commands at fixed moments. This is the file that keeps a good setup safe.

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.secrets/**)",
      "Bash(git push:*)"
    ]
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

The allow list removes the permission prompts for safe, boring commands. The deny list is a hard line: secrets stay unread and nothing gets pushed without you. The hook formats every file Claude edits, so you never ask for it again.

The difference with CLAUDE.md is important. "Never push to main" in CLAUDE.md is an instruction Claude will usually follow. The same rule in a deny list is enforced. For anything that would hurt if it went wrong, use settings, not prose. Overly broad access is a failure pattern I keep seeing; I list it with four others in this breakdown of production failures.

Personal overrides go in .claude/settings.local.json, which stays out of git.

How do you template MCP servers for a team?

You template MCP servers for a team with a .mcp.json file in the project root, which lists the servers everyone on the project should have. Commit it, and each person approves the servers the first time they open the project.

{
  "mcpServers": {
    "tasks": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

Keep tokens out of this file. Use environment variables or let each person log in through /mcp. Add one server at a time, and only ones you would trust with the data behind them. For scopes and safety, see connecting business tools with MCP.

Why do copied templates often disappoint?

Copied templates disappoint because they carry someone else's process, not yours. The file format is the easy part. The content is the work.

The data backs up how big that gap is. Stack Overflow's 2025 Developer Survey found that 84% of developers already use AI tools or plan to. Yet 46% of them distrust what those tools produce. And in a July 2025 study by METR, experienced open-source developers took 19% longer on tasks when they were allowed to use AI tools, even though they believed it made them faster. Tools without the right context and checks do not automatically save time.

Templates help with exactly that, but only once you fill them in. A few rules I follow:

1. Copy the structure, write the content. Delete every placeholder line you cannot fill with something true.
2. Add from corrections. Every time you correct Claude on the same thing twice, that correction goes into CLAUDE.md or a skill.
3. Enforce, don't ask. Rules that protect money, data or customers go in settings.json, not in a sentence.
4. Keep one source per fact. Prices, team members and tone live in one file. Everything else points to it.
5. Review monthly. A template that describes last quarter's process is worse than none.

Where can you get Claude Code templates to start from?

You can start from Anthropic's documentation, which shows the format of every file above, or from a setup someone has already used in practice. I share mine for free: the Claude Code Library and a task review skill are on my free resources page.

Whatever you start from, the order stays the same. CLAUDE.md and settings.json today. One skill this week for the task you repeat most. A subagent or an MCP server when a real task asks for it, not before.