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.
npx claude-code-templates@latestThe 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:
| Aspect | CLAUDE.md | Cursor rules |
|---|---|---|
| Tool | Claude Code | Cursor |
| Format | Markdown | Markdown 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 settings | the .cursor/rules/ directory, or AGENTS.md in the project root |
| Length | No limit, though the whole file enters context on every session | The documentation suggests keeping a rule under five hundred lines |
| Context | Loaded at session start | Always, 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
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.jsonRecommended CLAUDE.md sections
- Overview - Short project description (2-3 sentences)
- Tech Stack - List of technologies with versions
- Directory Structure - Folder map with descriptions
- Commands - Basic npm/yarn commands
- Conventions - Coding rules
- Common Tasks - Instructions for frequent tasks
- Architecture Decisions - ADRs and rationale
CLAUDE.md Template - complete example
Next.js App Router Template
# 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
# 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_ORIGINSFullstack Monorepo Template
# 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 appsCursor 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:
---
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 ComponentAdvanced configurations
Template with environment variables
## 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
## 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
## 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/descriptionCreating your own template
Step 1: Gather information about your project
## 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 considerationsStep 2: Start with a minimum
# 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 stylingStep 3: Iterate based on needs
Every time you need to fix generated code, add a rule to your CLAUDE.md:
## 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 tagsPricing
| Option | Cost |
|---|---|
| Catalogue and command line tool | 0 USD, MIT licence |
| Community contributed components | 0 USD |
| Your own configuration files | 0 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?
- Give Claude a task without a template
- Give the same task with a template
- Compare code quality and consistency
- 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.