Mejores templates para Claude Code en 2026

Por qué usar templates

Configurar Claude Code desde cero para cada proyecto es tiempo perdido. Un buen template te da en 30 segundos lo que tardarías 2 horas en configurar: convenciones de código, permisos de seguridad, comandos reutilizables y hooks automatizados.

Los templates no son rígidos. Son puntos de partida que adaptas a tu proyecto. Copia, pega, modifica lo necesario. Si no sabes qué es Claude Code, empieza por la guía básica.

Anatomía de un template

Un template completo de Claude Code tiene tres componentes:

1. CLAUDE.md (el cerebro)

Define quién es el proyecto, qué reglas sigue y qué está prohibido. Es el archivo que Claude Code lee al inicio de cada sesión para entender el contexto.

2. settings.json (los permisos)

Define qué puede y qué no puede hacer Claude Code. Allow list, deny list, y hooks. Es la configuración técnica que complementa las instrucciones del CLAUDE.md.

3. commands/ (los workflows)

Archivos Markdown que definen tareas reutilizables. /review, /test, /deploy-check. Son los "scripts" que cualquier miembro del equipo ejecuta con una barra y un nombre.

La estructura en disco:

.claude/
  CLAUDE.md          # Reglas del proyecto
  settings.json      # Permisos y hooks
  commands/
    review.md        # Comando /review
    test.md          # Comando /test
    refactor.md      # Comando /refactor
    deploy-check.md  # Comando /deploy-check

Cada componente funciona independientemente, pero juntos crean un entorno de desarrollo consistente y predecible.

Template: Next.js + TypeScript

# .claude/CLAUDE.md - Next.js + TypeScript

## Proyecto
Aplicación web con Next.js 14+ y TypeScript.
App Router (NO Pages Router).

## Stack
- Next.js 14+, React 18+, TypeScript strict
- Tailwind CSS para estilos
- Prisma ORM para base de datos
- Zod para validación
- Jest + React Testing Library para tests

## Convenciones
- Server Components por defecto. "use client" solo cuando necesario
- Data fetching en Server Components (NO useEffect para datos iniciales)
- Metadata API para SEO (generateMetadata, NOT Head)
- Route Handlers en app/api/ para endpoints
- Zod schemas para validar input en API routes
- Error boundaries con error.tsx por segmento
- Loading states con loading.tsx

## Seguridad
- Sanitizar input del usuario SIEMPRE
- Usar next/headers para cookies, NUNCA document.cookie
- Variables de entorno: NEXT_PUBLIC_ solo para datos públicos
- CSRF protection en mutaciones (Server Actions)

## NO hacer
- NO usar Pages Router
- NO usar getServerSideProps/getStaticProps
- NO instalar axios (usar fetch nativo)
- NO usar CSS modules (usar Tailwind)
- NO commitear .env.local

Template: FastAPI + Python

# .claude/CLAUDE.md - FastAPI + Python

## Proyecto
API REST con FastAPI. Python 3.11+.

## Stack
- FastAPI + Uvicorn
- SQLAlchemy 2.0+ (async) + Alembic
- Pydantic v2 para validación
- pytest + httpx para tests
- Ruff para linting, Black para formateo

## Arquitectura
src/
 api/ # Routes (thin controllers)
 services/ # Business logic
 repositories/ # Data access
 models/ # SQLAlchemy models
 schemas/ # Pydantic schemas
 core/ # Config, security, deps
tests/
 api/ # Integration tests
 services/ # Unit tests

## Convenciones
- Async por defecto (async def, no def)
- Dependency injection para DB sessions y auth
- Pydantic schemas separados: Create, Update, Response
- Alembic para TODAS las migraciones (NUNCA crear tablas manual)
- Tests: pytest, fixtures en conftest.py, factories con factory_boy
- Docstrings en funciones públicas

## Seguridad
- NUNCA SQL crudo sin parametrizar
- NUNCA exponer stack traces en producción
- Rate limiting en todos los endpoints públicos
- JWT con refresh token rotation
- CORS configurado explícitamente (NO allow all)

Template: React SPA

# .claude/CLAUDE.md - React SPA (Vite + TypeScript)

## Proyecto
Single Page Application con React + Vite + TypeScript.
NO es Next.js. NO tiene SSR.

## Stack
- React 18+, TypeScript strict, Vite
- React Router v6 para routing
- Zustand para estado global
- TanStack Query para server state
- Tailwind CSS para estilos
- Vitest + Testing Library para tests

## Arquitectura
src/
 components/    # Componentes reutilizables (UI pura)
 features/      # Módulos por funcionalidad (auth/, dashboard/, settings/)
 hooks/         # Custom hooks compartidos
 services/      # API calls (fetch wrappers)
 stores/        # Zustand stores
 types/         # TypeScript types/interfaces
 utils/         # Funciones puras sin side effects

## Convenciones
- Componentes: función + export default (no export en la declaración)
- Props: interface con suffix Props (ButtonProps, ModalProps)
- Hooks: extraer lógica compleja a custom hooks
- API: TanStack Query para TODO dato del servidor (no useState + useEffect)
- Estado local: useState para UI. Zustand solo para estado compartido
- Estilos: Tailwind utilities. Componentes complejos: cn() para merge condicional

## Reglas
- NO useEffect para data fetching (usar useQuery)
- NO prop drilling más de 2 niveles (usar context o Zustand)
- NO any en TypeScript (usar unknown si es necesario)
- NO importar desde ../ más de 2 niveles (usar path aliases @/)
- Cada feature es un módulo independiente. Features NO importan entre sí

Template: Monorepo fullstack

# .claude/CLAUDE.md - Monorepo Fullstack

## Proyecto
Monorepo con frontend (Next.js) y backend (FastAPI).

## Estructura
/frontend # Next.js 14+ TypeScript
/backend # FastAPI Python 3.11+
/shared # Tipos compartidos, schemas
/infra # Docker, CI/CD, terraform

## Reglas críticas
- Frontend y backend son independientes. NO importar entre ellos
- Comunicación via API REST (/api/v1/)
- Tipos compartidos en /shared (generados desde OpenAPI spec)
- Docker Compose para desarrollo local
- CI ejecuta tests de ambos antes de merge

## Por directorio
- /frontend: seguir convenciones Next.js (ver template Next.js)
- /backend: seguir convenciones FastAPI (ver template FastAPI)
- /shared: solo tipos y utilidades puras, cero dependencias
- /infra: documentar cada cambio en comentarios

Templates de comandos útiles

Los comandos se guardan en .claude/commands/ como archivos Markdown. Cada archivo es un comando invocable con /nombre. Aquí van los más útiles para cualquier equipo.

# .claude/commands/review.md
Revisa TODO el código cambiado en esta rama vs develop.
Busca: bugs, edge cases, secretos expuestos, código muerto,
inconsistencias con CLAUDE.md, tests faltantes.
Clasifica findings: CRITICAL, HIGH, MEDIUM, LOW.
Sugiere fixes concretos para CRITICAL y HIGH.

# .claude/commands/refactor.md
Analiza el archivo o directorio indicado.
Identifica: código duplicado, funciones demasiado largas (>30 líneas),
complejidad ciclomática alta, abstracciones incorrectas.
Propón refactoring concreto con antes/después.
NO cambies comportamiento, solo estructura.

# .claude/commands/test.md
Para el código cambiado en esta rama, genera tests que cubran:
1. Happy path (caso normal)
2. Edge cases (inputs límite, vacíos, nulos)
3. Error cases (qué debería fallar y cómo)
Usa el framework de testing del proyecto.
Ejecuta los tests y verifica que pasan.

# .claude/commands/document.md
Para el módulo o archivo indicado:
1. Genera/actualiza JSDoc o docstrings en funciones públicas
2. Crea o actualiza el README del módulo con: propósito, uso básico, API
3. Si hay tipos complejos, añade ejemplos de uso
NO documentes lo obvio. Documenta el POR QUÉ, no el QUÉ.

Más sobre comandos en la guía de comandos de Claude Code.

Templates de hooks

// .claude/settings.json - Hooks útiles
{
 "hooks": {
 "PreCommit": [
 {
 "command": "npm run lint:fix && npm run test",
 "description": "Lint fix + tests antes de commit"
 }
 ],
 "PostFileWrite": [
 {
 "command": "npx prettier --write $FILE",
 "description": "Formatear archivo tras escritura"
 }
 ]
 }
}

Para entender qué hooks existen y cómo configurarlos, lee la guía en nuestra introducción a Claude Code.

Guía de personalización

Un template sin personalizar es ruido. Aquí tienes un proceso de 5 pasos para adaptar cualquier template a tu proyecto:

Paso 1: Identidad (2 minutos)

Cambia nombre del proyecto, stack, URLs. Es lo más obvio pero lo que más impacto tiene en las respuestas de Claude Code.

Paso 2: Estructura de archivos (5 minutos)

Adapta la sección de arquitectura a tu estructura real. Si tu proyecto usa src/modules/ en vez de src/features/, cámbialo. Claude Code necesita paths reales, no genéricos.

Paso 3: Convenciones reales (10 minutos)

Revisa cada convención del template. Si dice "Jest para tests" pero tú usas Vitest, cámbialo. Si dice "Tailwind" pero usas styled-components, cámbialo. Cada regla incorrecta genera código que tendrás que refactorizar.

Paso 4: Restricciones propias (5 minutos)

Añade las reglas específicas de tu proyecto que ningún template genérico incluye: "no tocar el módulo de pagos sin review de María", "los endpoints legacy en /api/v0/ no se modifican", "las queries a la tabla X siempre incluyen el filtro de tenant_id".

Paso 5: Elimina lo que no aplica (3 minutos)

Si tu proyecto no tiene Docker, elimina las reglas de Docker. Si no usas Alembic, elimina esa sección. Un CLAUDE.md más corto y preciso es mejor que uno largo y genérico.

Compartir templates con el equipo

Hay varias formas de compartir templates en un equipo:

1. Repo de templates interno:

# company-claude-templates/
templates/
  nextjs/
    .claude/CLAUDE.md
    .claude/settings.json
    .claude/commands/review.md
    .claude/commands/test.md
  fastapi/
    .claude/CLAUDE.md
    .claude/settings.json
    .claude/commands/review.md
    .claude/commands/migrate.md
  monorepo/
    .claude/CLAUDE.md
    .claude/settings.json
    .claude/commands/...
README.md  # Cómo usar cada template

2. Script de bootstrap:

#!/bin/bash
# init-claude.sh - Inicializa config de Claude Code
TEMPLATE=$1
if [ -z "$TEMPLATE" ]; then
  echo "Uso: ./init-claude.sh [nextjs|fastapi|monorepo]"
  exit 1
fi
cp -r ~/company-templates/$TEMPLATE/.claude .
echo "Template '$TEMPLATE' copiado. Personaliza .claude/CLAUDE.md"

3. Herencia en monorepos:

El CLAUDE.md raíz contiene reglas globales. Cada subdirectorio (frontend/, backend/) tiene su CLAUDE.md específico que hereda del raíz. No necesitas copiar reglas comunes.

Templates de la comunidad

Más allá de tus propios templates, la comunidad de Claude Code comparte configuraciones en varios sitios:

GitHub:

• Repositorios con tag "claude-code-template" o "claude-md".
• El repositorio oficial de Anthropic con ejemplos de configuración.
• Repos de proyectos open source que incluyen su CLAUDE.md (buen punto de referencia).

Comunidades:

• Discord de Claude Code: canal #templates donde la gente comparte configuraciones.
• Reddit r/ClaudeAI: posts con templates especializados.
• Twitter/X: threads con tips y configuraciones optimizadas.

Qué buscar en un template comunitario:

• Que esté actualizado (Claude Code cambia rápido, templates de hace 6 meses pueden estar obsoletos).
• Que tenga contexto sobre POR QUÉ cada regla existe (no solo el qué).
• Que sea específico de un stack, no genérico para "cualquier proyecto".
• Que incluya los tres componentes (CLAUDE.md + settings + commands), no solo el CLAUDE.md.

Cómo crear tus propios templates

1. Empieza con un proyecto real. Configura Claude Code para tu proyecto actual. Itera la configuración durante 1-2 semanas hasta que funcione bien.

2. Generaliza. Elimina lo específico del proyecto (nombres, URLs, datos) y deja las convenciones y reglas generales.

3. Documenta. Añade comentarios que expliquen el porqué de cada regla. Un template sin contexto es un template que nadie usa.

4. Versiona. Guarda los templates en un repo. Actualízalos cuando descubras mejores prácticas o cuando Claude Code añada nuevas funcionalidades.

5. Testea con un proyecto nuevo. La prueba real de un template es usarlo en un proyecto limpio. Si necesitas modificar más del 30%, el template es demasiado genérico o demasiado específico.

Señales de que tu template es bueno:

• Claude Code genera código consistente desde la primera sesión.
• No necesitas repetir instrucciones que ya están en el CLAUDE.md.
• Los comandos compartidos cubren el 80% de las tareas repetitivas.
• Nuevos miembros del equipo pueden usarlo sin explicación adicional.

Señales de que necesita mejora:

• Repites instrucciones que deberían estar en el CLAUDE.md.
• Claude Code ignora reglas (probablemente contradictorias o ambiguas).
• El equipo no usa los comandos compartidos (no cubren sus necesidades reales).
• Cada developer modifica el template nada más copiarlo.

Preguntas frecuentes

¿Cuántos templates necesito?

Uno por stack principal que uses. Si trabajas con Next.js y FastAPI, necesitas dos. Si todos tus proyectos son Next.js, uno basta (con variaciones menores por proyecto).

¿Los templates se quedan obsoletos?

Sí. Claude Code evoluciona rápido. Revisa tus templates cada 2-3 meses para incorporar nuevas funcionalidades (hooks, skills, MCP). Un template de hace 6 meses probablemente no aproveche las últimas capacidades.

¿Template largo o corto?

Depende. Un CLAUDE.md de 50 líneas es suficiente para proyectos personales. Para equipos de 5+ personas con requisitos complejos, 200-300 líneas es normal. Nunca más de 500.

¿Puedo usar un template de otro lenguaje cómo base?

La estructura (secciones, formato) sí es reutilizable entre lenguajes. El contenido (convenciones, herramientas) no. Es mejor empezar con un template del mismo stack y adaptarlo.

¿Los hooks del template funcionan en todos los sistemas operativos?

Los comandos de hooks deben ser compatibles con el sistema del equipo. Si mezclas Mac y Windows, usa comandos cross-platform (npx, npm run) en vez de comandos nativos de shell.

Siguiente paso

Copia el template que más se ajuste a tu stack, pégalo en tu proyecto, y adapta las 5-10 líneas que necesiten cambios. En 10 minutos tendrás Claude Code configurado para producir código consistente y de calidad.

Si necesitas la base, empieza por instalar Claude Code y luego aplica el template.