Claude Code Templates: CLAUDE.md, Rules, Skills, and Whole Projects

People searching for claude code templates want one of four things: a CLAUDE.md to copy, rules files for a language or framework, a skill to teach the agent a workflow, or a whole project that comes with all three already in place. They get mixed together in every list, so this page takes them one at a time, says what each one is for, and gives you something you can paste.

The four kinds, and which one you are looking for

A CLAUDE.md worth copying

The most common mistake is putting everything in it. CLAUDE.md is loaded on every turn, so every line costs context on every turn, and a two-page file gets skimmed the way a two-page email does. Keep the things that are true for the whole repository and cannot be found by reading code:

## Project

pnpm monorepo. Apps live in `apps/*`, shared packages in `packages/*`.

## Commands

- `pnpm dev` starts every app. Do not start it: it is already running in another terminal.
- `pnpm --filter <app> test` runs one app's tests. Run these freely.
- `pnpm typecheck` at the root after any change to a shared package.

## Rules that are not negotiable

- Never use `as any`. Find the type.
- Never wrap backend logic in try/catch. The error middleware owns errors.
- Commit messages follow `feat: 🎸 <subject>` / `fix: 🐛 <subject>`.

## Where things are

- Backend routes: `apps/backend/src/routes`. Business logic: `apps/backend/src/features/<domain>/modules`.
- Frontend data fetching goes through HyperFetch clients in `apps/frontend/src/api`.

Everything longer than that belongs in a rules file scoped to the folder it is about.

Rules files that change behaviour

A rule file that says "write clean code" changes nothing. A rule file that names the mechanism does. This is the shape that works, taken from the backend rules the template ships:

---
paths:
  - "apps/backend/**/*.ts"
---

## Backend error handling

Errors are handled centrally by `src/middleware/error/error-middleware.ts`.

- Do NOT use try/catch in routes, features, modules, queries or mutations.
- Throw `ApplicationError`, `AuthError`, `AuthorizationError` or `ValidationError` with the matching code enum.
- A catch block that only logs is wrong. That error should reach the middleware, which is what reports it to Sentry.

The one exception: cleanup with rethrow (delete the temp file, then `throw error`).

Three things make that rule work where "handle errors properly" fails. It names the file that owns the behaviour. It says what to do instead, with the exact identifiers. And it is scoped, so it costs nothing when the agent is editing a React component.

Skills, for the things you do more than twice

A skill is a SKILL.md in its own folder with a name and a description in the frontmatter. The description is what the agent reads to decide whether to use it, so it should say when, not what:

---
name: preflight
description:
  Ship gate. Run before any push to main, or when asked "is this safe to ship". Detects what kind of change is in the
  tree, runs the typecheck, tests and e2e lanes that change needs, and records the verified tree.
---

1. Detect the change kind from `git diff --name-only origin/main`.
2. App or package code: root `pnpm lint`, `pnpm typecheck`, `pnpm test`.
3. A new or changed pack: also that pack's e2e lane.
4. Record the verified tree hash so the push hook lets main through.

You do not have to write these from scratch. The skills.sh directory has a few hundred, installed with one command, and the template's create pulls eight of them into .agents/skills during scaffolding: design guidelines, React performance patterns, a planner that interrogates a plan against the docs, a teacher that explains the change it made. Claude Code reads them through a .claude/skills link, and Codex, Cursor and Copilot read the same folder directly.

The whole-project template

Here is the part the lists leave out. A CLAUDE.md template from a gist describes somebody else's repository. The rules worth having describe your architecture, and the architecture has to exist before anyone can write rules for it. So a Claude Code template that actually changes how the agent behaves is a project: a codebase with a shape, and the rules, skills and tooling written against that shape.

That is what Hype Stack is. A full-stack TypeScript app (React 19, TanStack Router, Hono, Prisma and Kysely on Postgres) that comes with the rules already written for its own conventions, in every editor's format at once: Claude Code gets .claude/rules/*.md with paths frontmatter, Cursor gets .cursor/rules/*.mdc, Codex and OpenCode get an AGENTS.md, Copilot gets .github/instructions. Pick the editors you use and create writes all of them.

What is not in the box: your product. The template knows how a route is written and how an organization owns its records. It does not know what your app does, and the rules it ships will not write your domain for you. That part is still the agent and you, working in a repo where the boring decisions are already made and enforced.