We use cookies to enhance your experience on the site
CodeWorlds
Back to collections
Guide24 min read

Claude Code Templates, a catalogue of ready components

Claude Code Templates is a catalogue of agents, commands, and configs for Claude Code, installed with one command. How it works and what to avoid.

Claude Code Templates, a catalogue of ready components

Claude Code Templates is a project collecting ready made configuration pieces for Claude Code: specialised agents, commands, hooks, settings, and connections to MCP servers. You install them with one command and pick them from a catalogue on the site. The davila7/claude-code-templates repository carries over thirty thousand stars under an MIT licence.

What this actually is

The name misleads, since it suggests project templates in the sense of ready starter code. It is something else: a catalogue of configuration, meaning files telling the agent how to work rather than code that lands in your application.

The pieces fall into several kinds worth distinguishing, because they solve different problems. Agents are specialised roles with their own task description, for security review or for work with a particular framework. Commands are recorded procedures invoked by a shortcut. Hooks are rules executed automatically on given events. Settings are prepared permission and behaviour configurations. Entries connecting MCP servers round it out, along with skills, meaning packaged procedural knowledge in the standard format, which happens to be the catalogue's largest category. Plugins form a separate category, since they add a mechanism to the tool rather than another instruction: claude-mem records the course of a session, compresses it with a model, and supplies the notes on the next launch, so the agent does not start every day from a blank page. What survives that compression is decided by a model, though, so the notes need reading now and then instead of being trusted as a faithful record.

In practice you browse the catalogue on the project's site, assemble the set you need, and receive a finished command to paste into a terminal.

Code
Bash
npx claude-code-templates@latest

The package also installs a shorter cct alias, so day to day use does not require typing the full name.

When this makes sense, and when it does not

Honestly: this accelerates a start rather than solving a problem. The value is greatest in two situations.

The first is beginning with the tool, when you do not yet know what can be configured. Browsing the catalogue is then a faster way to learn the possibilities than reading documentation, because you see concrete examples instead of a description of mechanisms.

The second is a need somebody has already met. A configuration for a specific framework or an agent reviewing code for security issues is not worth writing from scratch when a working starting point exists.

It stops making sense once you start installing pieces speculatively. Every additional agent and command occupies context and competes for the model's attention when choosing a tool. Twenty installed pieces of which you use three degrade performance rather than improving it.

It also stops making sense as a substitute for your own configuration. What matters most to an agent is knowledge of your repository: how tests are run, where migrations live, what must not be touched. No catalogue holds that, because it is local knowledge, and it is precisely what produces the largest improvement.

What to watch when installing somebody else's components

This project writes files into your configuration directory, and it is worth understanding what happens then, because not every kind of component carries the same risk.

Agents and commands are text carrying instructions. The worst they can do is point the agent down a wrong path, which you will notice on first use. Hooks and permission settings are a different category, since they execute automatically or change the scope of what the agent does without asking. A component loosening permissions is convenient right up until it is not. A hook intercepting the end of a run is what the Ralph loop is built on: it blocks the exit and feeds the agent the same instruction again until the task is finished. That suits dull, verifiable work such as migrating syntax across hundreds of files, while without an explicit exit condition the loop keeps turning and spends budget on every further pass.

The practical rule matches the one for code dependencies: read the file before installing it, particularly if it contains anything executable. That takes a minute, and the catalogue holds thousands of community submitted entries, so not all of them have passed anyone's review.

The second matter is housekeeping. Components install easily and are therefore easy to forget. It pays to review the configuration directory periodically and remove what you do not use, otherwise six months later you hold a set nobody on the team can explain. Keeping that directory in the project repository rather than in user configuration makes such changes visible during code review.

Relation to the Agent Skills standard

It is worth placing this project in a wider context, because since December 2025 an open standard for packaging agent knowledge exists, described in Agent Skills. The same directory holding a SKILL.md file is read today by dozens of tools from different vendors.

The difference is that the standard describes a format portable between tools, while this project is a catalogue: alongside skills in the standard format it collects pieces specific to one tool, including some with no equivalent in the specification, hooks and permission settings among them. The two approaches coexist rather than competing.

The practical conclusion when planning: record procedural knowledge you want to move between tools in the standard format. Keep tool specific configuration where that tool looks for it. Mixing the two layers ends in duplication, where the same instruction lives in two places and diverges after the first change.

What are Claude Code Templates?

The catalogue describes itself as a set of ready-made configurations for Claude Code, and that is its actual scope: components install into that tool's configuration directory. This section, by contrast, talks more broadly about context files themselves, since the pattern is shared across several assistants. It covers the CLAUDE.md file, a project rule in Cursor's case, the directory structure, and a description of conventions, the things that raise a model's effectiveness when generating and modifying code.

A good template is not just starter code - it is primarily context for AI. When Claude Code understands the project architecture, naming conventions, and the technology stack in use, it can generate code that immediately fits the rest of the application.

Philosophy behind templates

AI coding assistants are only as good as the context you provide them. Without information about the project, Claude will generate code in a "default" style that may not fit your project. With a good CLAUDE.md, the AI:

  • Understands the project structure and knows where to place new files
  • Knows naming conventions (camelCase vs snake_case, components vs hooks)
  • Knows which libraries and patterns to use (e.g., Prisma instead of raw SQL)
  • Generates consistent code that matches the rest of the codebase
  • Avoids duplication and leverages existing utility functions

Difference between CLAUDE.md and Cursor rules

Both files serve a similar purpose, but for different tools:

AspectCLAUDE.mdCursor rules
ToolClaude CodeCursor
FormatMarkdownMarkdown with frontmatter in .mdc files, or a plain AGENTS.md
Location./CLAUDE.md or ./.claude/CLAUDE.md in the project, ~/.claude/CLAUDE.md for personal settingsthe .cursor/rules/ directory, or AGENTS.md in the project root
LengthNo limit, though the whole file enters context on every sessionThe documentation suggests keeping a rule under five hundred lines
ContextLoaded at session startAlways, by path pattern, at the model's discretion, or by an @-mention in chat

Mind the filename: a .cursorrules file in the project root is a historical form that Cursor's current documentation no longer lists. The current mechanisms are project rules in .cursor/rules/, team rules managed from the dashboard, user rules, and an AGENTS.md file. If an old file sits in your repository, move its contents into one of those.

You can keep both sets in a project, for different tools.

Why use templates?

1. Immediate productivity

Instead of spending time explaining the project structure to Claude with every task, a template does it once and does it well. Every session starts with full context.

2. Code consistency

The AI generates code in the same style as the rest of the project. No mixing of different conventions in one codebase.

3. Fewer corrections

Code generated with good context requires fewer manual corrections. The AI immediately knows:

  • Where to import components
  • Which hooks to use
  • How to name variables
  • How to handle errors

4. Documentation as a side effect

CLAUDE.md simultaneously serves as project documentation. New developers (and AI) quickly understand the architecture.

5. Reproducibility

The same instructions produce similar results. A team can share a template and get consistent code.

Template structure

Basic project structure

Code
TEXT
project-template/
β”œβ”€β”€ CLAUDE.md              # Main configuration file for Claude
β”œβ”€β”€ .cursor/
β”‚   └── rules/             # Cursor rules as .mdc files
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ components/        # React components
β”‚   β”œβ”€β”€ hooks/             # Custom hooks
β”‚   β”œβ”€β”€ lib/               # Utilities and configurations
β”‚   β”œβ”€β”€ types/             # TypeScript types
β”‚   └── app/               # Next.js App Router pages
β”œβ”€β”€ docs/
β”‚   β”œβ”€β”€ ARCHITECTURE.md    # Detailed architecture description
β”‚   └── API.md             # API documentation
β”œβ”€β”€ scripts/
β”‚   └── setup.sh           # Setup script for new devs
β”œβ”€β”€ .env.example           # Environment variables template
└── package.json

Recommended CLAUDE.md sections

  1. Overview - Short project description (2-3 sentences)
  2. Tech Stack - List of technologies with versions
  3. Directory Structure - Folder map with descriptions
  4. Commands - Basic npm/yarn commands
  5. Conventions - Coding rules
  6. Common Tasks - Instructions for frequent tasks
  7. Architecture Decisions - ADRs and rationale

CLAUDE.md Template - complete example

Next.js App Router Template

Code
Markdown
# Project: [Project Name]

## Overview
[Name] is [short description - 1-2 sentences]. The application serves [main purpose].

## Tech Stack
- **Framework**: Next.js 15 (App Router)
- **Language**: TypeScript 5.x (strict mode)
- **Database**: PostgreSQL + Prisma ORM
- **Auth**: NextAuth.js v5 (Auth.js)
- **Styling**: Tailwind CSS + shadcn/ui
- **State**: React Query (TanStack Query) + Zustand
- **Testing**: Vitest + Testing Library
- **Deployment**: Vercel

## Directory Structure
\`\`\`
src/
β”œβ”€β”€ app/                    # Next.js App Router
β”‚   β”œβ”€β”€ (auth)/            # Auth group (login, register)
β”‚   β”œβ”€β”€ (dashboard)/       # Protected dashboard pages
β”‚   β”œβ”€β”€ api/               # API routes
β”‚   β”‚   β”œβ”€β”€ auth/         # NextAuth endpoints
β”‚   β”‚   └── trpc/         # tRPC router (if used)
β”‚   └── layout.tsx         # Root layout
β”œβ”€β”€ components/
β”‚   β”œβ”€β”€ ui/                # shadcn/ui components
β”‚   β”œβ”€β”€ forms/             # Form components
β”‚   └── [feature]/         # Feature-specific components
β”œβ”€β”€ hooks/                  # Custom React hooks
β”œβ”€β”€ lib/
β”‚   β”œβ”€β”€ prisma.ts          # Prisma client singleton
β”‚   β”œβ”€β”€ auth.ts            # Auth configuration
β”‚   └── utils.ts           # Utility functions
β”œβ”€β”€ types/                  # TypeScript type definitions
└── server/                 # Server-side code
    β”œβ”€β”€ actions/           # Server Actions
    └── db/                # Database queries
\`\`\`

## Commands
\`\`\`bash
npm run dev          # Start dev server (port 3000)
npm run build        # Production build
npm run test         # Run tests with Vitest
npm run lint         # ESLint check
npm run db:push      # Push Prisma schema to DB
npm run db:studio    # Open Prisma Studio
npm run db:seed      # Seed database
\`\`\`

## Conventions

### Naming
- **Components**: PascalCase (UserProfile.tsx)
- **Hooks**: camelCase with "use" prefix (useAuth.ts)
- **Utils**: camelCase (formatDate.ts)
- **Types**: PascalCase with "I" prefix for interfaces (IUser)
- **Constants**: SCREAMING_SNAKE_CASE

### Components
- Use functional components with TypeScript
- Prefer Server Components where possible
- Keep components under 150 lines
- Extract logic to custom hooks
- Use composition over props drilling

### Imports
- Use absolute imports with @/ alias
- Group imports: react β†’ next β†’ external β†’ internal β†’ types
- Prefer named exports over default exports

### Error Handling
- Use Result pattern for expected errors
- Throw only for unexpected errors
- Always handle loading and error states in UI
- Use error boundaries for component errors

### Database
- Use Prisma transactions for multi-step operations
- Soft delete where appropriate (deletedAt column)
- Index foreign keys and commonly queried fields

## Common Tasks

### Adding a new page
1. Create file in `src/app/(group)/page-name/page.tsx`
2. Add metadata export for SEO
3. Create Server Component, fetch data at top level
4. Use Client Components only for interactivity

### Adding a new API endpoint
1. Create `src/app/api/[endpoint]/route.ts`
2. Export named functions (GET, POST, PUT, DELETE)
3. Use Zod for request validation
4. Return NextResponse.json() with proper status codes

### Adding a Server Action
1. Create in `src/server/actions/[feature].ts`
2. Add "use server" directive at top
3. Use revalidatePath/revalidateTag for cache invalidation
4. Return { success: boolean, data?: T, error?: string }

### Creating a form
1. Use react-hook-form + zod for validation
2. Create schema in `src/lib/validations/[feature].ts`
3. Use Server Action for submission
4. Show loading state during submission
5. Display validation errors inline

### Database changes
1. Update `prisma/schema.prisma`
2. Run `npm run db:push` (dev) or create migration
3. Update related TypeScript types
4. Update affected components

## Architecture Decisions

### Why App Router over Pages Router?
- Better DX with Server Components
- Built-in layouts and loading states
- Improved data fetching patterns
- Future-proof architecture

### Why Prisma over raw SQL?
- Type-safe queries
- Auto-generated types
- Easy migrations
- Great DX with Prisma Studio

### Why Zustand over Redux?
- Simpler API for this project size
- Less boilerplate
- Works well with Server Components
- TypeScript support out of the box

## Environment Variables
Required variables (see .env.example):
- DATABASE_URL - PostgreSQL connection string
- NEXTAUTH_SECRET - Auth.js secret
- NEXTAUTH_URL - Base URL for auth callbacks

## Notes for AI
- Always use TypeScript strict mode
- Prefer async/await over .then()
- Use early returns for guard clauses
- Add JSDoc comments for exported functions
- Consider mobile responsiveness
- Follow accessibility best practices (ARIA, semantic HTML)

NestJS Backend Template

Code
Markdown
# Project: [API Name]

## Overview
[Name] API is a backend service for [description]. It handles [main functionalities].

## Tech Stack
- **Framework**: NestJS 10.x
- **Language**: TypeScript 5.x (strict)
- **Database**: PostgreSQL + TypeORM
- **Cache**: Redis
- **Queue**: Bull (Redis-based)
- **Auth**: JWT + Passport
- **Docs**: Swagger/OpenAPI
- **Testing**: Jest + Supertest

## Directory Structure
\`\`\`
src/
β”œβ”€β”€ modules/               # Feature modules
β”‚   β”œβ”€β”€ auth/
β”‚   β”‚   β”œβ”€β”€ auth.module.ts
β”‚   β”‚   β”œβ”€β”€ auth.controller.ts
β”‚   β”‚   β”œβ”€β”€ auth.service.ts
β”‚   β”‚   β”œβ”€β”€ strategies/    # Passport strategies
β”‚   β”‚   β”œβ”€β”€ guards/        # Auth guards
β”‚   β”‚   └── dto/           # Data Transfer Objects
β”‚   β”œβ”€β”€ users/
β”‚   └── [feature]/
β”œβ”€β”€ common/
β”‚   β”œβ”€β”€ decorators/        # Custom decorators
β”‚   β”œβ”€β”€ filters/           # Exception filters
β”‚   β”œβ”€β”€ guards/            # Global guards
β”‚   β”œβ”€β”€ interceptors/      # Interceptors
β”‚   └── pipes/             # Validation pipes
β”œβ”€β”€ config/                # Configuration modules
β”œβ”€β”€ database/
β”‚   β”œβ”€β”€ entities/          # TypeORM entities
β”‚   β”œβ”€β”€ migrations/        # Database migrations
β”‚   └── seeds/             # Seed data
└── main.ts
\`\`\`

## Commands
\`\`\`bash
yarn start:dev       # Start with hot reload
yarn build           # Production build
yarn start:prod      # Start production server
yarn test            # Run unit tests
yarn test:e2e        # Run E2E tests
yarn migration:run   # Run pending migrations
yarn migration:create # Create new migration
\`\`\`

## Conventions

### Module Structure
Each feature module contains:
- `.module.ts` - Module definition
- `.controller.ts` - HTTP endpoints
- `.service.ts` - Business logic
- `/dto` - Request/Response DTOs
- `/entities` - TypeORM entities (if needed)

### Naming
- **Modules**: singular (user.module.ts, not users)
- **Controllers**: plural endpoints (/users, not /user)
- **Services**: singular (UserService)
- **Entities**: singular, PascalCase (User)
- **DTOs**: CreateUserDto, UpdateUserDto, UserResponseDto

### Error Handling
- Throw NestJS HttpExceptions
- Use global exception filter for consistency
- Log errors with correlation ID
- Return standardized error response:
\`\`\`json
{ "statusCode": 400, "message": "...", "error": "Bad Request" }
\`\`\`

### Validation
- Use class-validator on all DTOs
- Use class-transformer for type conversion
- Enable whitelist to strip unknown properties
- Use custom validation decorators when needed

## API Response Format
\`\`\`typescript
// Success
{
  "data": T,
  "meta": { "page": 1, "total": 100 }
}

// Error
{
  "statusCode": number,
  "message": string,
  "error": string,
  "timestamp": string,
  "path": string
}
\`\`\`

## Common Tasks

### Adding a new module
\`\`\`bash
nest g module modules/[name]
nest g controller modules/[name]
nest g service modules/[name]
\`\`\`

### Adding a new endpoint
1. Add method to controller with decorators
2. Create DTO in `/dto` folder
3. Implement logic in service
4. Add Swagger decorators for docs
5. Write tests

### Database migration
1. Make changes to entity
2. Run `yarn migration:generate src/database/migrations/[name]`
3. Review generated SQL
4. Run `yarn migration:run`

## Environment Variables
- DATABASE_URL
- JWT_SECRET
- JWT_EXPIRES_IN
- REDIS_URL
- CORS_ORIGINS

Fullstack Monorepo Template

Code
Markdown
# Project: [Monorepo Name]

## Overview
A monorepo containing a frontend (Next.js), backend (NestJS), and shared packages.

## Tech Stack
- **Monorepo**: Turborepo + pnpm workspaces
- **Frontend**: Next.js 15, TypeScript, Tailwind
- **Backend**: NestJS 10, TypeScript, PostgreSQL
- **Shared**: TypeScript types, validation schemas
- **API**: REST + tRPC (optional)

## Workspace Structure
\`\`\`
/
β”œβ”€β”€ apps/
β”‚   β”œβ”€β”€ web/               # Next.js frontend
β”‚   β”‚   β”œβ”€β”€ src/
β”‚   β”‚   └── package.json
β”‚   └── api/               # NestJS backend
β”‚       β”œβ”€β”€ src/
β”‚       └── package.json
β”œβ”€β”€ packages/
β”‚   β”œβ”€β”€ ui/                # Shared React components
β”‚   β”‚   β”œβ”€β”€ src/
β”‚   β”‚   └── package.json
β”‚   β”œβ”€β”€ db/                # Database client (Prisma)
β”‚   β”‚   β”œβ”€β”€ prisma/
β”‚   β”‚   └── package.json
β”‚   β”œβ”€β”€ types/             # Shared TypeScript types
β”‚   β”‚   β”œβ”€β”€ src/
β”‚   β”‚   └── package.json
β”‚   └── config/            # Shared configs (ESLint, TSConfig)
β”‚       β”œβ”€β”€ eslint/
β”‚       └── typescript/
β”œβ”€β”€ turbo.json             # Turborepo config
β”œβ”€β”€ pnpm-workspace.yaml    # Workspace definition
└── package.json           # Root package.json
\`\`\`

## Commands (root level)
\`\`\`bash
pnpm install         # Install all dependencies
pnpm dev             # Start all apps in dev mode
pnpm build           # Build all packages and apps
pnpm lint            # Lint everything
pnpm test            # Run all tests
pnpm db:push         # Push Prisma schema
pnpm db:generate     # Generate Prisma client
\`\`\`

## Workspace-specific commands
\`\`\`bash
# Run command in specific workspace
pnpm --filter web dev
pnpm --filter api test
pnpm --filter @repo/ui build
\`\`\`

## Inter-package imports
\`\`\`typescript
// In apps/web
import { Button } from "@repo/ui"
import { User } from "@repo/types"
import { prisma } from "@repo/db"
\`\`\`

## Conventions

### Package naming
- Apps: web, api, admin, mobile
- Packages: @repo/[name] (ui, types, db, config)

### Shared code rules
- Types that both frontend and backend use β†’ @repo/types
- Validation schemas (Zod) β†’ @repo/types
- React components β†’ @repo/ui
- Database client β†’ @repo/db

### Dependency management
- Shared deps in root package.json
- App-specific deps in app's package.json
- Use workspace:* for internal packages

## Notes for AI
- Check which workspace you're in before making changes
- Use correct package names in imports
- Consider if code should be shared or app-specific
- Run commands from root with --filter for specific apps

Cursor rules template

Cursor prefers shorter instructions. Save a rule as an .mdc file under .cursor/rules/; the frontmatter decides when it loads. Here is an always-applied version:

Code
Markdown
---
alwaysApply: true
---
# Project Rules

Tech: Next.js 15 App Router, TypeScript strict, Tailwind, shadcn/ui, Prisma

## Structure
- src/app/ - pages and layouts
- src/components/ - React components (prefer Server Components)
- src/lib/ - utilities and configs
- src/server/actions/ - Server Actions

## Conventions
- TypeScript strict, no any
- Named exports, absolute imports (@/)
- Components < 150 lines
- Error handling with Result pattern
- Mobile-first, accessible

## Commands
- npm run dev (port 3000)
- npm run db:push (Prisma)

## When creating components
1. Check if similar exists in src/components/ui
2. Use shadcn/ui patterns
3. Add proper TypeScript types
4. Consider Server vs Client Component

Advanced configurations

Template with environment variables

Code
Markdown
## Environment Setup

### Development
\`\`\`bash
cp .env.example .env.local
# Edit .env.local with your values
\`\`\`

### Required Variables
| Variable | Description | Example |
|----------|-------------|---------|
| DATABASE_URL | PostgreSQL connection | postgresql://... |
| NEXTAUTH_SECRET | Auth secret (32+ chars) | openssl rand -base64 32 |
| NEXTAUTH_URL | App URL | http://localhost:3000 |
| STRIPE_SECRET_KEY | Stripe API key | sk_test_... |

### Optional Variables
| Variable | Description | Default |
|----------|-------------|---------|
| LOG_LEVEL | Logging verbosity | info |
| ENABLE_ANALYTICS | Enable tracking | false |

### Generating secrets
\`\`\`bash
# Generate NEXTAUTH_SECRET
openssl rand -base64 32

# Generate API key
openssl rand -hex 24
\`\`\`

Template with testing guidelines

Code
Markdown
## Testing

### File naming
- Unit tests: `[name].test.ts`
- Integration tests: `[name].integration.test.ts`
- E2E tests: `[name].e2e.ts`

### Test structure
\`\`\`typescript
describe('UserService', () => {
  describe('createUser', () => {
    it('should create user with valid data', async () => {
      // Arrange
      const input = { email: 'test@test.com', name: 'Test' }

      // Act
      const result = await userService.createUser(input)

      // Assert
      expect(result).toMatchObject(input)
    })

    it('should throw on duplicate email', async () => {
      // ...
    })
  })
})
\`\`\`

### Mocking
- Use Vitest's vi.mock() for modules
- Create fixtures in `__fixtures__/`
- Use factories for test data

### Coverage requirements
- Minimum 80% coverage for new code
- 100% coverage for critical paths (auth, payments)

Template with CI/CD information

Code
Markdown
## CI/CD Pipeline

### GitHub Actions Workflow
\`\`\`yaml
# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v2
      - uses: actions/setup-node@v4
      - run: pnpm install
      - run: pnpm lint
      - run: pnpm test
      - run: pnpm build
\`\`\`

### Deployment
- **Production**: main branch β†’ Vercel
- **Preview**: PR branches β†’ Vercel Preview

### Pre-commit hooks (Husky)
- Lint staged files
- Run affected tests
- Type check

### Branch naming
- feature/[ticket]-description
- fix/[ticket]-description
- chore/description

Creating your own template

Step 1: Gather information about your project

Code
Markdown
## CLAUDE.md Checklist

### Basics
- [ ] Project name and description
- [ ] Main tech stack with versions
- [ ] Folder structure
- [ ] Basic commands

### Conventions
- [ ] Naming style (camelCase, PascalCase, etc.)
- [ ] Preferred patterns (hooks vs HOC, etc.)
- [ ] Import conventions
- [ ] Error handling approach

### Project-specific
- [ ] Custom abstractions
- [ ] Utility functions to reuse
- [ ] Common gotchas
- [ ] Performance considerations

Step 2: Start with a minimum

Code
Markdown
# Project Name

## Stack
Next.js 15, TypeScript, Prisma, Tailwind

## Structure
- src/app - pages
- src/components - components
- src/lib - utilities

## Commands
npm run dev
npm run build

## Rules
- TypeScript strict mode
- Server Components preferred
- Tailwind for styling

Step 3: Iterate based on needs

Every time you need to fix generated code, add a rule to your CLAUDE.md:

Code
Markdown
## Learned rules
- Always use `prisma` singleton from `src/lib/prisma.ts`
- Forms use react-hook-form + zod, not native forms
- Images use next/image, not img tag
- Links use next/link, not anchor tags

Pricing

OptionCost
Catalogue and command line tool0 USD, MIT licence
Community contributed components0 USD
Your own configuration files0 USD, they are ordinary text files

The project has no paid tiers and no commercial edition: the repository is MIT licensed, and the catalogue and the command line package are free. The only bill involved is the subscription or the tokens of the tool whose configuration you are installing. The value lies in the knowledge and experience you accumulate by writing your own files.

FAQ - frequently asked questions

Does CLAUDE.md have to be in the project root?

It does not have to. The project file works as either ./CLAUDE.md or ./.claude/CLAUDE.md, and beyond the project there is also ~/.claude/CLAUDE.md for personal settings and ./CLAUDE.local.md for things that stay out of the repository. Files sitting in directories above the working directory load in full at launch, while those in subdirectories load only once the agent reaches for files there. The latter suits a monorepo, since it lets each package carry its own instructions.

How long should CLAUDE.md be?

There is no strict limit, but practically:

  • Minimum: 50-100 lines (basic info)
  • Optimal: 200-400 lines (full context)
  • Maximum: As long as needed

Cursor's documentation suggests keeping a single rule under five hundred lines and splitting larger ones across several files.

Can I use markdown formatting?

Yes, Claude understands markdown. Use:

  • Headers (#, ##, ###) for structure
  • Code blocks for examples
  • Tables for comparisons
  • Lists for conventions

How often should I update the template?

  • After significant architecture changes
  • After adding new conventions
  • After encountering recurring problems
  • When onboarding new tools

Should I share CLAUDE.md between projects?

You can have a base template and customize it per project. The main sections (tech stack, structure) will differ, but coding conventions can be shared.

How to test template effectiveness?

  1. Give Claude a task without a template
  2. Give the same task with a template
  3. Compare code quality and consistency
  4. Iterate on the template based on differences

Does CLAUDE.md replace README.md?

No, they serve different purposes. The first is for humans and describes the project in general terms; the second is for the agent and carries detailed technical context. They complement each other, but neither replaces the other.

Are catalogue components safe?

Treat them like any other dependency from an external source. Hooks execute commands automatically, and permission settings can loosen control over what the agent does without asking. Read the file before installing it, particularly if it contains anything executable.

How many components are worth installing?

Fewer than instinct suggests. Every additional agent and command occupies context and competes for attention when a tool is chosen. Three well matched pieces work better than twenty installed speculatively.

What genuinely improves work with an agent

A catalogue of ready pieces is convenient, but the largest improvement comes from something no catalogue holds, because it concerns your repository alone.

The first thing is run commands, which in a Next.js project is less obvious than it sounds. An agent that does not know tests are invoked through a specific script with a specific flag will either guess or ask, and both waste time. Writing the literal build, test, and type check commands into the configuration file removes the most common source of friction.

The second is boundaries. A sentence saying what must not be touched is usually more valuable than three paragraphs about architecture. The migrations directory, generated files, deployment configuration: those are where an agent's own initiative costs the most.

The third is conventions invisible in the code, the typing approach in a TypeScript project for instance. If the project follows a particular error handling approach or naming scheme that cannot be inferred from two random files, it has to be stated explicitly. An agent reads a fragment of the repository rather than all of it, so it generalises from whatever it happened to open.

The fourth is currency. A configuration file describing a structure from before a refactor is worse than none, because the agent will trust the description over what it sees. Treat it like code and update it in the same pull request that changes the thing it describes.

The fifth, most often skipped, is length. A thousand line file enters context on every task and crowds out the code the agent actually needs to read. A short file with pointers to detail works better than an exhaustive document, and for larger bodies of procedural knowledge the better home is skills in the standard format, loaded only when needed.

The project code and component catalogue live in the GitHub repository, and the tool's documentation at docs.aitmpl.com.