Claude Code Templates, katalog gotowych komponentów
Claude Code Templates to projekt zbierający gotowe elementy konfiguracji dla Claude Code: wyspecjalizowanych agentów, polecenia, haki, ustawienia i połączenia z serwerami MCP. Instaluje się je jednym poleceniem, a wybiera z katalogu na stronie. Repozytorium davila7/claude-code-templates ma ponad trzydzieści tysięcy gwiazdek i licencję MIT.
Co to właściwie jest
Nazwa myli, bo sugeruje szablony projektów w rozumieniu gotowego kodu startowego. To coś innego: katalog konfiguracji, czyli plików, które mówią agentowi, jak ma pracować, a nie kodu, który trafia do Twojej aplikacji.
Elementy dzielą się na kilka rodzajów i warto je rozróżniać, bo rozwiązują różne problemy. Agenci to wyspecjalizowane role z własnym opisem zadania, na przykład do przeglądu bezpieczeństwa albo do pracy z konkretnym frameworkiem. Polecenia to zapisane procedury uruchamiane skrótem. Haki to reguły wykonywane automatycznie przy określonych zdarzeniach. Ustawienia to gotowe konfiguracje uprawnień i zachowania. Do tego dochodzą wpisy podłączające serwery MCP oraz umiejętności, czyli spakowana wiedza proceduralna w formacie standardowym, i akurat ta kategoria jest w katalogu najliczniejsza. Osobną kategorią są wtyczki, które dokładają narzędziu mechanizm, a nie kolejną instrukcję: claude-mem zapisuje przebieg sesji, kompresuje go modelem i podaje notatki przy następnym uruchomieniu, dzięki czemu agent nie zaczyna każdego dnia od pustej kartki. O tym, co przetrwa kompresję, decyduje jednak model, więc te notatki trzeba raz na jakiś czas przeczytać zamiast zakładać, że wiernie oddają przebieg pracy.
Praktycznie wygląda to tak, że przeglądasz katalog na stronie projektu, składasz zestaw potrzebnych elementów i dostajesz gotowe polecenie do wklejenia w terminalu.
npx claude-code-templates@latestPakiet instaluje też krótszy alias cct, więc w codziennej pracy nie trzeba wpisywać pełnej nazwy.
Kiedy to ma sens, a kiedy nie
Uczciwie: to jest przyspieszacz startu, nie rozwiązanie problemu. Wartość jest największa w dwóch sytuacjach.
Pierwsza to początek pracy z narzędziem, kiedy nie wiesz jeszcze, co da się skonfigurować. Przejrzenie katalogu jest wtedy szybszym sposobem na poznanie możliwości niż czytanie dokumentacji, bo widzisz konkretne przykłady zamiast opisu mechanizmów.
Druga to potrzeba, którą ktoś już rozwiązał. Konfiguracja pod konkretny framework albo agent do przeglądu kodu pod kątem bezpieczeństwa to rzeczy, których nie warto pisać od zera, skoro istnieje działający punkt wyjścia.
Traci sens wtedy, gdy zaczynasz instalować elementy na zapas. Każdy dodatkowy agent i każde polecenie zajmuje miejsce w kontekście i konkuruje o uwagę modelu przy wyborze narzędzia. Dwadzieścia zainstalowanych elementów, z których korzystasz z trzech, pogarsza działanie zamiast je poprawiać.
Traci też sens jako substytut własnej konfiguracji. Największą wartość dla agenta ma wiedza o Twoim repozytorium: jak uruchamia się testy, gdzie leżą migracje, czego nie wolno ruszać. Tego nie znajdziesz w żadnym katalogu, bo to wiedza lokalna, i właśnie ona daje największą poprawę.
Na co uważać przy instalowaniu cudzych elementów
Ten projekt wstawia pliki do Twojego katalogu konfiguracyjnego i warto rozumieć, co się przy tym dzieje, bo nie wszystkie rodzaje elementów niosą to samo ryzyko.
Agenci i polecenia to tekst z instrukcjami. Najgorsze, co mogą zrobić, to skierować agenta na złą ścieżkę, co zauważysz przy pierwszym użyciu. Haki i ustawienia uprawnień są inną kategorią, bo wykonują się automatycznie albo zmieniają zakres tego, co agent zrobi bez pytania. Element rozluźniający uprawnienia jest wygodny do czasu, aż przestanie być. Na haku przechwytującym zakończenie pracy opiera się na przykład pętla Ralph: blokuje moment wyjścia i podaje agentowi to samo polecenie z powrotem, aż zadanie będzie gotowe. Sprawdza się przy pracy nudnej i weryfikowalnej, w rodzaju migracji składni w setkach plików, natomiast bez wyraźnego warunku zakończenia taka pętla kręci się dalej i wydaje budżet na kolejne obroty.
Praktyczna zasada wygląda tak samo jak przy zależnościach w kodzie: przeczytaj plik przed instalacją, zwłaszcza jeśli zawiera cokolwiek uruchamialnego. To zajmuje minutę, a katalog liczy tysiące pozycji zgłaszanych przez społeczność, więc nie wszystkie przeszły czyjkolwiek przegląd.
Druga sprawa to sprzątanie. Elementy instaluje się łatwo i dlatego łatwo o nich zapomnieć. Warto raz na jakiś czas przejrzeć katalog konfiguracyjny i usunąć to, czego nie używasz, bo inaczej po pół roku masz zestaw, którego nikt w zespole nie potrafi wytłumaczyć. Trzymanie tego katalogu w repozytorium projektu, a nie w konfiguracji użytkownika, ułatwia zauważenie takich zmian przy przeglądzie kodu.
Relacja do standardu Agent Skills
Warto umieścić ten projekt w szerszym kontekście, bo od grudnia 2025 roku istnieje otwarty standard pakowania wiedzy dla agentów, opisany w Agent Skills. Ten sam katalog z plikiem SKILL.md czyta dziś kilkadziesiąt narzędzi różnych producentów.
Różnica jest taka, że standard opisuje format przenośny między narzędziami, a ten projekt jest katalogiem: obok umiejętności w formacie standardowym zbiera elementy specyficzne dla jednego narzędzia, w tym takie, które nie mają odpowiednika w specyfikacji, na przykład haki i ustawienia uprawnień. Oba podejścia współistnieją i nie wykluczają się.
Praktyczny wniosek przy planowaniu: wiedzę proceduralną, którą chcesz przenosić między narzędziami, zapisuj w formacie standardowym. Konfigurację specyficzną dla jednego narzędzia trzymaj tam, gdzie to narzędzie jej szuka. Mieszanie tych dwóch warstw kończy się duplikacją, w której ta sama instrukcja żyje w dwóch miejscach i rozjeżdża się po pierwszej zmianie.
Czym są Claude Code Templates?
Sam katalog opisuje się jako zestaw gotowych konfiguracji dla Claude Code i to jest jego właściwy zakres: elementy instalują się do katalogu konfiguracyjnego tego narzędzia. Ta sekcja mówi natomiast szerzej o samych plikach kontekstu, bo wzorzec jest wspólny dla kilku asystentów. Chodzi o plik CLAUDE.md, a w Cursorze o regułę projektu, o strukturę katalogów i o opis konwencji, czyli o rzeczy, które podnoszą skuteczność modelu przy generowaniu i modyfikowaniu kodu.
Dobry template to nie tylko kod startowy - to przede wszystkim kontekst dla AI. Gdy Claude Code rozumie architekturę projektu, konwencje nazewnictwa i używany stack technologiczny, może generować kod, który natychmiast pasuje do reszty aplikacji.
Filozofia stojąca za szablonami
AI coding assistants są tak dobre, jak kontekst, który im przekażesz. Bez informacji o projekcie, Claude będzie generował kod w "domyślnym" stylu, który może nie pasować do Twojego projektu. Z dobrym CLAUDE.md, AI:
- Rozumie strukturę projektu i wie, gdzie umieszczać nowe pliki
- Zna konwencje nazewnictwa (camelCase vs snake_case, komponenty vs hooki)
- Wie, jakich bibliotek i wzorców używać (np. Prisma zamiast raw SQL)
- Generuje spójny kod zgodny z resztą codebase
- Unika duplikacji i wykorzystuje istniejące utility functions
Różnica między CLAUDE.md a regułami Cursora
Oba pliki służą podobnemu celowi, ale dla różnych narzędzi:
| Aspekt | CLAUDE.md | Reguły Cursora |
|---|---|---|
| Narzędzie | Claude Code | Cursor |
| Format | Markdown | Markdown z frontmatterem w plikach .mdc, albo zwykły AGENTS.md |
| Lokalizacja | ./CLAUDE.md lub ./.claude/CLAUDE.md w projekcie, ~/.claude/CLAUDE.md dla ustawień osobistych | katalog .cursor/rules/ albo AGENTS.md w katalogu głównym |
| Długość | Bez limitu, ale całość wchodzi do kontekstu przy każdej sesji | Dokumentacja zaleca poniżej pięciuset linii na regułę |
| Kontekst | Wczytywany na starcie sesji | Zawsze, po wzorcu ścieżek, na decyzję modelu albo przez wzmiankę w czacie |
Uwaga na nazwę pliku: .cursorrules w katalogu głównym to zapis historyczny, którego bieżąca dokumentacja Cursora już nie wymienia. Aktualne mechanizmy to reguły projektu w .cursor/rules/, reguły zespołowe zarządzane z panelu, reguły użytkownika i plik AGENTS.md. Jeśli masz w repozytorium stary plik, przenieś jego treść do jednego z nich.
Możesz mieć w projekcie oba zestawy, dla różnych narzędzi.
Dlaczego używać szablonów?
1. Natychmiastowa produktywność
Zamiast tracić czas na tłumaczenie Claude'owi struktury projektu przy każdym zadaniu, template robi to raz, a dobrze. Każda sesja zaczyna się z pełnym kontekstem.
2. Konsystencja kodu
AI generuje kod w tym samym stylu co reszta projektu. Brak miksu różnych konwencji w jednej codebase.
3. Mniej poprawek
Kod wygenerowany z dobrym kontekstem wymaga mniej ręcznych poprawek. AI od razu wie:
- Gdzie importować komponenty
- Jakich hooków używać
- Jak nazywać zmienne
- Jak obsługiwać błędy
4. Dokumentacja przy okazji
CLAUDE.md pełni jednocześnie funkcję dokumentacji projektu. Nowi developerzy (i AI) szybko rozumieją architekturę.
5. Powtarzalność
Te same instrukcje dają podobne wyniki. Team może współdzielić template i uzyskiwać spójny kod.
Struktura szablonu
Podstawowa struktura projektu
project-template/
├── CLAUDE.md # Główny plik konfiguracyjny dla Claude
├── .cursor/
│ └── rules/ # Reguly Cursora w plikach .mdc
├── src/
│ ├── components/ # React components
│ ├── hooks/ # Custom hooks
│ ├── lib/ # Utilities i konfiguracje
│ ├── types/ # TypeScript types
│ └── app/ # Next.js App Router pages
├── docs/
│ ├── ARCHITECTURE.md # Szczegółowy opis architektury
│ └── API.md # Dokumentacja API
├── scripts/
│ └── setup.sh # Setup script dla nowych devów
├── .env.example # Template zmiennych środowiskowych
└── package.jsonRekomendowane sekcje CLAUDE.md
- Overview - Krótki opis projektu (2-3 zdania)
- Tech Stack - Lista technologii z wersjami
- Directory Structure - Mapa folderów z opisami
- Commands - Podstawowe komendy npm/yarn
- Conventions - Reguły kodowania
- Common Tasks - Instrukcje dla częstych zadań
- Architecture Decisions - ADRs i uzasadnienia
CLAUDE.md Template - Kompletny przykład
Next.js App Router Template
# Project: [Nazwa Projektu]
## Overview
[Nazwa] to [krótki opis - 1-2 zdania]. Aplikacja służy do [główny cel].
## 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 (jeśli używany)
│ └── 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
[Nazwa] API to backend service dla [opis]. Obsługuje [główne funkcjonalności].
## 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
Każdy feature module zawiera:
- `.module.ts` - Module definition
- `.controller.ts` - HTTP endpoints
- `.service.ts` - Business logic
- `/dto` - Request/Response DTOs
- `/entities` - TypeORM entities (jeśli potrzebne)
### 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: [Nazwa Monorepo]
## Overview
Monorepo zawierające frontend (Next.js), backend (NestJS) i 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 appsSzablon reguł dla Cursora
Cursor preferuje krótsze instrukcje. Regułę zapisz jako plik .mdc w katalogu .cursor/rules/; frontmatter decyduje o tym, kiedy się doczyta. Poniżej wersja stosowana zawsze:
---
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 ComponentZaawansowane konfiguracje
Template z 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
\`\`\`Szablon z wytycznymi do testów
## 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 z 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/descriptionTworzenie własnego template
Krok 1: Zbierz informacje o projekcie
## Checklist do CLAUDE.md
### Podstawowe
- [ ] Nazwa i opis projektu
- [ ] Główny tech stack z wersjami
- [ ] Struktura folderów
- [ ] Podstawowe komendy
### Konwencje
- [ ] Styl nazewnictwa (camelCase, PascalCase, etc.)
- [ ] Preferowane wzorce (hooks vs HOC, etc.)
- [ ] Import conventions
- [ ] Error handling approach
### Specyficzne dla projektu
- [ ] Niestandardowe abstrakcje
- [ ] Utility functions do reuse
- [ ] Common gotchas
- [ ] Performance considerationsKrok 2: Zacznij od 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 stylingKrok 3: Iteruj na podstawie potrzeb
Za każdym razem, gdy musisz poprawiać wygenerowany kod, dodaj regułę do 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 tagsCennik
| Opcja | Koszt |
|---|---|
| Katalog i narzędzie wiersza poleceń | 0 USD, licencja MIT |
| Elementy zgłaszane przez społeczność | 0 USD |
| Własne pliki konfiguracyjne | 0 USD, to zwykłe pliki tekstowe |
Projekt nie ma planów płatnych ani wersji komercyjnej: repozytorium jest na licencji MIT, a katalog i pakiet z wiersza poleceń są darmowe. Jedyny rachunek, jaki przy tym płacisz, to abonament albo tokeny samego narzędzia, którego konfigurację tu instalujesz. Wartość jest w wiedzy i doświadczeniu, które zbierasz tworząc własne pliki.
FAQ - Najczęściej zadawane pytania
Czy CLAUDE.md musi być w root projektu?
Nie musi. Plik projektowy działa zarówno jako ./CLAUDE.md, jak i ./.claude/CLAUDE.md, a poza projektem obowiązuje jeszcze ~/.claude/CLAUDE.md z ustawieniami osobistymi i ./CLAUDE.local.md na rzeczy, które nie idą do repozytorium. Pliki leżące w katalogach powyżej katalogu roboczego wczytują się w całości na starcie, a te z podkatalogów dopiero wtedy, gdy agent sięgnie po pliki z tego miejsca. To ostatnie jest wygodne w monorepo, bo pozwala trzymać osobne instrukcje przy każdym pakiecie.
Jak długi powinien być CLAUDE.md?
Nie ma ścisłego limitu, ale praktycznie:
- Minimum: 50-100 linii (podstawowe info)
- Optymalnie: 200-400 linii (pełny kontekst)
- Maximum: Tyle, ile potrzeba
Dokumentacja Cursora radzi trzymać pojedynczą regułę poniżej pięciuset linii i dzielić większe na kilka plików.
Czy mogę używać markdown formatting?
Tak, Claude rozumie markdown. Używaj:
- Headers (#, ##, ###) dla struktury
- Code blocks dla przykładów
- Tables dla porównań
- Lists dla konwencji
Jak często aktualizować template?
- Po znaczących zmianach w architekturze
- Po dodaniu nowych konwencji
- Po napotkaniu powtarzających się problemów
- Podczas onboardingu nowych narzędzi
Czy dzielić CLAUDE.md między projektami?
Możesz mieć bazowy template i dostosowywać go per projekt. Główne sekcje (tech stack, structure) będą się różnić, ale konwencje kodowania mogą być wspólne.
Jak testować skuteczność template?
- Daj Claude'owi zadanie bez template
- Daj to samo zadanie z template
- Porównaj jakość i spójność kodu
- Iteruj na template na podstawie różnic
Czy CLAUDE.md zastępuje README.md?
Nie, to różne cele. Pierwszy plik jest dla ludzi i opisuje projekt ogólnie, drugi dla agenta i zawiera szczegółowy kontekst techniczny. Mogą się uzupełniać, ale jeden nie zastępuje drugiego.
Czy elementy z katalogu są bezpieczne?
Traktuj je jak każdą inną zależność z zewnętrznego źródła. Haki wykonują polecenia automatycznie, a ustawienia uprawnień mogą rozluźnić kontrolę nad tym, co agent zrobi bez pytania. Przeczytaj plik, zanim go zainstalujesz, zwłaszcza jeśli zawiera cokolwiek uruchamialnego.
Ile elementów warto zainstalować?
Mniej, niż podpowiada odruch. Każdy dodatkowy agent i polecenie zajmuje miejsce w kontekście i konkuruje o uwagę przy wyborze narzędzia. Trzy dopasowane elementy działają lepiej niż dwadzieścia zainstalowanych na zapas.
Co naprawdę poprawia pracę z agentem
Katalog gotowych elementów jest wygodny, ale największą poprawę daje coś, czego w żadnym katalogu nie znajdziesz, bo dotyczy wyłącznie Twojego repozytorium.
Pierwsza rzecz to polecenia uruchomieniowe, co w projekcie na Next.js bywa mniej oczywiste, niż się wydaje. Agent, który nie wie, że testy uruchamia się przez konkretny skrypt z konkretną flagą, albo zgadnie, albo zapyta, i w obu przypadkach traci czas. Wypisanie w pliku konfiguracyjnym dosłownych poleceń do budowania, testowania i sprawdzania typów usuwa najczęstsze źródło tarcia.
Druga to granice. Zdanie mówiące, czego nie wolno ruszać, jest zwykle cenniejsze niż trzy akapity o architekturze. Katalog z migracjami, wygenerowane pliki, konfiguracja wdrożeniowa: to miejsca, gdzie samodzielna inicjatywa agenta kosztuje najwięcej.
Trzecia to konwencje, które w kodzie są niewidoczne, na przykład sposób typowania w projekcie na TypeScripcie. Jeśli w projekcie obowiązuje określony sposób obsługi błędów albo nazewnictwo, którego nie da się wywnioskować z dwóch losowych plików, trzeba to napisać wprost. Agent czyta fragment repozytorium, a nie całość, więc uogólnia z tego, co akurat otworzył.
Czwarta to aktualność. Plik konfiguracyjny opisujący strukturę sprzed przebudowy jest gorszy niż jego brak, bo agent zaufa opisowi bardziej niż temu, co widzi. Warto go traktować jak kod i poprawiać w tym samym zgłoszeniu, w którym zmienia się opisywana rzecz.
Piąta, najczęściej pomijana, to długość. Plik na tysiąc linii trafia do kontekstu przy każdym zadaniu i wypycha z niego kod, który agent faktycznie musi przeczytać. Krótki plik z odsyłaczami do szczegółów działa lepiej niż wyczerpujący dokument, a przy większej ilości wiedzy proceduralnej lepszym miejscem są umiejętności w formacie standardowym, wczytywane tylko wtedy, gdy są potrzebne.
Kod projektu i katalog elementów znajdziesz w repozytorium na GitHubie, a dokumentację narzędzia w serwisie docs.aitmpl.com.