docs: add Spanish (es) translation (#2095)

Adds a complete Spanish translation of the ECC documentation under docs/es/, mirroring the Turkish (docs/tr/) translation in scope. 141 files covering agents, commands, rules, skills, contexts, examples, and core docs. Updates root README.md with the Spanish language link. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-14 04:01:30 +08:00 · 2026-06-07 01:26:42 -04:00
parent 28b78dd7bf
commit ac0f11c640
143 changed files with 28639 additions and 3 deletions
@@ -0,0 +1,61 @@
+# Reglas (Rules)
+
+Convenciones de codificación y mejores prácticas para Claude Code.
+
+## Estructura de Directorios
+
+### Common (Reglas Independientes del Lenguaje)
+
+Reglas fundamentales que aplican a todos los lenguajes de programación:
+
+- **agents.md** - Orquestación y uso de agentes
+- **coding-style.md** - Reglas generales de estilo de código (inmutabilidad, organización de archivos, manejo de errores)
+- **development-workflow.md** - Flujo de trabajo de desarrollo de features (investigación, planificación, TDD, revisión de código)
+- **git-workflow.md** - Flujo de trabajo de commits y PRs en Git
+- **hooks.md** - Sistema de hooks (PreToolUse, PostToolUse, Stop)
+- **patterns.md** - Patrones de diseño comunes (Repository, Formato de Respuesta de API)
+- **performance.md** - Optimización de rendimiento (selección de modelo, gestión de la ventana de contexto)
+- **security.md** - Reglas de seguridad (gestión de secretos, verificaciones de seguridad)
+- **testing.md** - Requisitos de pruebas (TDD, cobertura mínima del 80%)
+
+### TypeScript/JavaScript
+
+Reglas específicas para proyectos TypeScript y JavaScript:
+
+- **coding-style.md** - Sistemas de tipos, inmutabilidad, manejo de errores, validación de entrada
+- **hooks.md** - Prettier, verificación de TypeScript, advertencias de console.log
+- **patterns.md** - Formato de respuesta de API, custom hooks, patrón Repository
+- **security.md** - Gestión de secretos, variables de entorno
+- **testing.md** - Testing E2E con Playwright
+
+### Python
+
+Reglas específicas para proyectos Python:
+
+- **coding-style.md** - PEP 8, anotaciones de tipos, inmutabilidad, herramientas de formateo
+- **hooks.md** - Formateo con black/ruff, verificación de tipos con mypy/pyright
+- **patterns.md** - Protocol (duck typing), dataclasses, context managers
+- **security.md** - Gestión de secretos, escaneo de seguridad con bandit
+- **testing.md** - Framework pytest, cobertura, organización de pruebas
+
+### Golang
+
+Reglas específicas para proyectos Go:
+
+- **coding-style.md** - gofmt/goimports, principios de diseño, manejo de errores
+- **hooks.md** - Formateo con gofmt/goimports, go vet, staticcheck
+- **patterns.md** - Functional options, interfaces pequeñas, inyección de dependencias
+- **security.md** - Gestión de secretos, escaneo de seguridad con gosec, context y timeouts
+- **testing.md** - Pruebas table-driven, detección de condiciones de carrera, cobertura
+
+## Uso
+
+Estas reglas son cargadas y aplicadas automáticamente por Claude Code. Las reglas:
+
+1. **Independientes del lenguaje** - Las reglas en el directorio `common/` aplican a todos los proyectos
+2. **Específicas por lenguaje** - Las reglas en los directorios de lenguaje (typescript/, python/, golang/) extienden las reglas comunes
+3. **Basadas en rutas** - Las reglas se aplican a archivos que coinciden con los patrones de rutas en el frontmatter YAML
+
+## Documentación Original
+
+El original en inglés de esta documentación se encuentra en el directorio `rules/`.
@@ -0,0 +1,51 @@
+# Orquestación de Agentes
+
+## Agentes Disponibles
+
+Ubicados en `~/.claude/agents/`:
+
+| Agente | Propósito | Cuándo Usar |
+|--------|-----------|-------------|
+| planner | Planificación de implementación | Features complejas, refactoring |
+| architect | Diseño de sistemas | Decisiones arquitectónicas |
+| tdd-guide | Desarrollo guiado por pruebas | Nuevas features, corrección de bugs |
+| code-reviewer | Revisión de código | Después de escribir código |
+| security-reviewer | Análisis de seguridad | Antes de los commits |
+| build-error-resolver | Corrección de errores de build | Cuando el build falla |
+| e2e-runner | Testing E2E | Flujos de usuario críticos |
+| refactor-cleaner | Limpieza de código muerto | Mantenimiento de código |
+| doc-updater | Documentación | Actualización de docs |
+| rust-reviewer | Revisión de código Rust | Proyectos Rust |
+| harmonyos-app-resolver | Desarrollo de apps HarmonyOS | Proyectos HarmonyOS/ArkTS |
+
+## Uso Inmediato de Agentes
+
+Sin necesidad de prompt del usuario:
+1. Solicitudes de features complejas - Usar el agente **planner**
+2. Código recién escrito/modificado - Usar el agente **code-reviewer**
+3. Corrección de bug o nueva feature - Usar el agente **tdd-guide**
+4. Decisión arquitectónica - Usar el agente **architect**
+
+## Ejecución Paralela de Tareas
+
+SIEMPRE usar ejecución paralela de tareas para operaciones independientes:
+
+```markdown
+# CORRECTO: Ejecución paralela
+Lanzar 3 agentes en paralelo:
+1. Agente 1: Análisis de seguridad del módulo de auth
+2. Agente 2: Revisión de rendimiento del sistema de caché
+3. Agente 3: Verificación de tipos de las utilidades
+
+# INCORRECTO: Secuencial cuando no es necesario
+Primero agente 1, luego agente 2, luego agente 3
+```
+
+## Análisis Multi-Perspectiva
+
+Para problemas complejos, usar sub-agentes con roles divididos:
+- Revisor factual
+- Ingeniero senior
+- Experto en seguridad
+- Revisor de consistencia
+- Verificador de redundancias
@@ -0,0 +1,90 @@
+# Estilo de Código
+
+## Inmutabilidad (CRÍTICO)
+
+SIEMPRE crear objetos nuevos, NUNCA mutar los existentes:
+
+```
+// Pseudocódigo
+INCORRECTO:  modify(original, campo, valor) → modifica original in-place
+CORRECTO:    update(original, campo, valor) → retorna nueva copia con el cambio
+```
+
+Justificación: Los datos inmutables previenen efectos secundarios ocultos, facilitan la depuración y permiten concurrencia segura.
+
+## Principios Fundamentales
+
+### KISS (Keep It Simple)
+
+- Preferir la solución más simple que realmente funcione
+- Evitar optimización prematura
+- Optimizar para claridad, no para ingeniosidad
+
+### DRY (Don't Repeat Yourself)
+
+- Extraer lógica repetida en funciones o utilidades compartidas
+- Evitar la deriva por copiar y pegar implementaciones
+- Introducir abstracciones cuando la repetición es real, no especulativa
+
+### YAGNI (You Aren't Gonna Need It)
+
+- No construir features o abstracciones antes de que sean necesarias
+- Evitar generalidad especulativa
+- Comenzar simple, luego refactorizar cuando la presión es real
+
+## Organización de Archivos
+
+MUCHOS ARCHIVOS PEQUEÑOS > POCOS ARCHIVOS GRANDES:
+- Alta cohesión, bajo acoplamiento
+- 200-400 líneas típico, 800 máximo
+- Extraer utilidades de módulos grandes
+- Organizar por feature/dominio, no por tipo
+
+## Manejo de Errores
+
+SIEMPRE manejar errores de forma exhaustiva:
+- Manejar errores explícitamente en cada nivel
+- Proporcionar mensajes de error amigables en código orientado a la UI
+- Registrar contexto detallado del error en el lado del servidor
+- Nunca silenciar errores
+
+## Validación de Entrada
+
+SIEMPRE validar en los límites del sistema:
+- Validar toda la entrada del usuario antes de procesarla
+- Usar validación basada en esquemas donde esté disponible
+- Fallar rápido con mensajes de error claros
+- Nunca confiar en datos externos (respuestas de API, entrada de usuario, contenido de archivos)
+
+## Convenciones de Nomenclatura
+
+- Variables y funciones: `camelCase` con nombres descriptivos
+- Booleanos: preferir prefijos `is`, `has`, `should`, o `can`
+- Interfaces, tipos y componentes: `PascalCase`
+- Constantes: `UPPER_SNAKE_CASE`
+- Custom hooks: `camelCase` con prefijo `use`
+
+## Code Smells a Evitar
+
+### Anidamiento Profundo
+
+Preferir retornos anticipados sobre condicionales anidados cuando la lógica empieza a acumularse.
+
+### Números Mágicos
+
+Usar constantes nombradas para umbrales, retrasos y límites significativos.
+
+### Funciones Largas
+
+Dividir funciones grandes en piezas enfocadas con responsabilidades claras.
+
+## Lista de Verificación de Calidad de Código
+
+Antes de marcar el trabajo como completo:
+- [ ] El código es legible y bien nombrado
+- [ ] Las funciones son pequeñas (<50 líneas)
+- [ ] Los archivos están enfocados (<800 líneas)
+- [ ] Sin anidamiento profundo (>4 niveles)
+- [ ] Manejo de errores apropiado
+- [ ] Sin valores hardcodeados (usar constantes o configuración)
+- [ ] Sin mutación (patrones inmutables usados)
@@ -0,0 +1,44 @@
+# Flujo de Trabajo de Desarrollo
+
+> Este archivo extiende [common/git-workflow.md](./git-workflow.md) con el proceso completo de desarrollo de features que ocurre antes de las operaciones de git.
+
+El Flujo de Trabajo de Implementación de Features describe el pipeline de desarrollo: investigación, planificación, TDD, revisión de código y luego commit a git.
+
+## Flujo de Trabajo de Implementación de Features
+
+0. **Investigación y Reutilización** _(obligatorio antes de cualquier nueva implementación)_
+   - **Búsqueda en código de GitHub primero:** Ejecutar `gh search repos` y `gh search code` para encontrar implementaciones existentes, plantillas y patrones antes de escribir nada nuevo.
+   - **Docs de librerías segundo:** Usar Context7 o los docs del proveedor principal para confirmar el comportamiento de las APIs, uso de paquetes y detalles específicos de versión antes de implementar.
+   - **Exa solo cuando los dos primeros son insuficientes:** Usar Exa para investigación web más amplia o descubrimiento después de la búsqueda en GitHub y los docs principales.
+   - **Verificar registros de paquetes:** Buscar en npm, PyPI, crates.io y otros registros antes de escribir código de utilidades. Preferir librerías probadas en batalla sobre soluciones escritas a mano.
+   - **Buscar implementaciones adaptables:** Buscar proyectos open-source que resuelvan el 80%+ del problema y puedan ser forkeados, portados o envueltos.
+   - Preferir adoptar o portar un enfoque probado antes de escribir código nuevo cuando cumple el requisito.
+
+1. **Planificar Primero**
+   - Usar el agente **planner** para crear un plan de implementación
+   - Generar documentos de planificación antes de codificar: PRD, arquitectura, system_design, tech_doc, task_list
+   - Identificar dependencias y riesgos
+   - Desglosar en fases
+
+2. **Enfoque TDD**
+   - Usar el agente **tdd-guide**
+   - Escribir pruebas primero (ROJO)
+   - Implementar para que pasen las pruebas (VERDE)
+   - Refactorizar (MEJORAR)
+   - Verificar cobertura del 80%+
+
+3. **Revisión de Código**
+   - Usar el agente **code-reviewer** inmediatamente después de escribir código
+   - Abordar problemas CRÍTICOS y ALTOS
+   - Corregir problemas MEDIOS cuando sea posible
+
+4. **Commit y Push**
+   - Mensajes de commit detallados
+   - Seguir el formato de conventional commits
+   - Ver [git-workflow.md](./git-workflow.md) para el formato de mensajes de commit y el proceso de PR
+
+5. **Verificaciones Pre-Revisión**
+   - Verificar que todas las verificaciones automatizadas (CI/CD) estén pasando
+   - Resolver cualquier conflicto de merge
+   - Asegurar que el branch esté actualizado con el branch objetivo
+   - Solo solicitar revisión después de que estas verificaciones pasen
@@ -0,0 +1,24 @@
+# Flujo de Trabajo con Git
+
+## Formato de Mensajes de Commit
+```
+<tipo>: <descripción>
+
+<cuerpo opcional>
+```
+
+Tipos: feat, fix, refactor, docs, test, chore, perf, ci
+
+Nota: Atribución deshabilitada globalmente mediante ~/.claude/settings.json.
+
+## Flujo de Trabajo de Pull Request
+
+Al crear PRs:
+1. Analizar el historial completo de commits (no solo el último commit)
+2. Usar `git diff [base-branch]...HEAD` para ver todos los cambios
+3. Redactar un resumen completo del PR
+4. Incluir plan de pruebas con TODOs
+5. Hacer push con la flag `-u` si es un branch nuevo
+
+> Para el proceso completo de desarrollo (planificación, TDD, revisión de código) antes de las operaciones de git,
+> ver [development-workflow.md](./development-workflow.md).
@@ -0,0 +1,30 @@
+# Sistema de Hooks
+
+## Tipos de Hooks
+
+- **PreToolUse**: Antes de la ejecución de herramientas (validación, modificación de parámetros)
+- **PostToolUse**: Después de la ejecución de herramientas (auto-formato, verificaciones)
+- **Stop**: Cuando la sesión termina (verificación final)
+
+## Permisos de Auto-Aceptación
+
+Usar con precaución:
+- Habilitar para planes bien definidos y de confianza
+- Deshabilitar para trabajo exploratorio
+- Nunca usar la flag dangerously-skip-permissions
+- Configurar `allowedTools` en `~/.claude.json` en su lugar
+
+## Buenas Prácticas de TodoWrite
+
+Usar la herramienta TodoWrite para:
+- Rastrear el progreso en tareas de múltiples pasos
+- Verificar la comprensión de las instrucciones
+- Permitir redirección en tiempo real
+- Mostrar pasos de implementación granulares
+
+La lista de tareas revela:
+- Pasos fuera de orden
+- Elementos faltantes
+- Elementos adicionales innecesarios
+- Granularidad incorrecta
+- Requisitos mal interpretados
@@ -0,0 +1,31 @@
+# Patrones Comunes
+
+## Proyectos Esqueleto
+
+Al implementar nueva funcionalidad:
+1. Buscar proyectos esqueleto probados en batalla
+2. Usar agentes paralelos para evaluar opciones:
+   - Evaluación de seguridad
+   - Análisis de extensibilidad
+   - Puntuación de relevancia
+   - Planificación de implementación
+3. Clonar la mejor coincidencia como fundación
+4. Iterar dentro de la estructura probada
+
+## Patrones de Diseño
+
+### Patrón Repository
+
+Encapsular el acceso a datos detrás de una interfaz consistente:
+- Definir operaciones estándar: findAll, findById, create, update, delete
+- Las implementaciones concretas manejan los detalles de almacenamiento (base de datos, API, archivo, etc.)
+- La lógica de negocio depende de la interfaz abstracta, no del mecanismo de almacenamiento
+- Permite cambiar fácilmente las fuentes de datos y simplifica las pruebas con mocks
+
+### Formato de Respuesta de API
+
+Usar un envelope consistente para todas las respuestas de API:
+- Incluir un indicador de éxito/estado
+- Incluir el payload de datos (nullable en error)
+- Incluir un campo de mensaje de error (nullable en éxito)
+- Incluir metadatos para respuestas paginadas (total, page, limit)
@@ -0,0 +1,55 @@
+# Optimización de Rendimiento
+
+## Estrategia de Selección de Modelos
+
+**Haiku 4.5** (90% de la capacidad de Sonnet, 3x ahorro de costos):
+- Agentes ligeros con invocación frecuente
+- Programación en pareja y generación de código
+- Agentes workers en sistemas multi-agente
+
+**Sonnet 4.6** (Mejor modelo para codificación):
+- Trabajo de desarrollo principal
+- Orquestación de flujos de trabajo multi-agente
+- Tareas de codificación complejas
+
+**Opus 4.5** (Razonamiento más profundo):
+- Decisiones arquitectónicas complejas
+- Requisitos de razonamiento máximo
+- Tareas de investigación y análisis
+
+## Gestión de la Ventana de Contexto
+
+Evitar el último 20% de la ventana de contexto para:
+- Refactoring a gran escala
+- Implementación de features que abarca múltiples archivos
+- Depuración de interacciones complejas
+
+Tareas con menor sensibilidad al contexto:
+- Ediciones de un solo archivo
+- Creación de utilidades independientes
+- Actualizaciones de documentación
+- Correcciones de bugs simples
+
+## Extended Thinking + Modo Plan
+
+El extended thinking está habilitado por defecto, reservando hasta 31,999 tokens para razonamiento interno.
+
+Controlar el extended thinking mediante:
+- **Toggle**: Option+T (macOS) / Alt+T (Windows/Linux)
+- **Config**: Establecer `alwaysThinkingEnabled` en `~/.claude/settings.json`
+- **Límite de presupuesto**: `export MAX_THINKING_TOKENS=10000`
+- **Modo verbose**: Ctrl+O para ver la salida del pensamiento
+
+Para tareas complejas que requieren razonamiento profundo:
+1. Asegurarse de que el extended thinking esté habilitado (activado por defecto)
+2. Habilitar el **Modo Plan** para un enfoque estructurado
+3. Usar múltiples rondas de crítica para un análisis exhaustivo
+4. Usar sub-agentes con roles divididos para perspectivas diversas
+
+## Solución de Problemas de Build
+
+Si el build falla:
+1. Usar el agente **build-error-resolver**
+2. Analizar los mensajes de error
+3. Corregir de forma incremental
+4. Verificar después de cada corrección
@@ -0,0 +1,29 @@
+# Directrices de Seguridad
+
+## Verificaciones de Seguridad Obligatorias
+
+Antes de CUALQUIER commit:
+- [ ] Sin secretos hardcodeados (claves de API, contraseñas, tokens)
+- [ ] Todas las entradas de usuario validadas
+- [ ] Prevención de inyección SQL (consultas parametrizadas)
+- [ ] Prevención de XSS (HTML sanitizado)
+- [ ] Protección CSRF habilitada
+- [ ] Autenticación/autorización verificada
+- [ ] Rate limiting en todos los endpoints
+- [ ] Los mensajes de error no filtran datos sensibles
+
+## Gestión de Secretos
+
+- NUNCA hardcodear secretos en el código fuente
+- SIEMPRE usar variables de entorno o un gestor de secretos
+- Validar que los secretos requeridos estén presentes al iniciar
+- Rotar cualquier secreto que pueda haber sido expuesto
+
+## Protocolo de Respuesta a Seguridad
+
+Si se encuentra un problema de seguridad:
+1. DETENER inmediatamente
+2. Usar el agente **security-reviewer**
+3. Corregir problemas CRÍTICOS antes de continuar
+4. Rotar cualquier secreto expuesto
+5. Revisar todo el código base en busca de problemas similares
@@ -0,0 +1,57 @@
+# Requisitos de Pruebas
+
+## Cobertura Mínima de Pruebas: 80%
+
+Tipos de Pruebas (TODOS requeridos):
+1. **Pruebas Unitarias** - Funciones individuales, utilidades, componentes
+2. **Pruebas de Integración** - Endpoints de API, operaciones de base de datos
+3. **Pruebas E2E** - Flujos de usuario críticos (framework elegido por lenguaje)
+
+## Desarrollo Guiado por Pruebas
+
+Flujo de trabajo OBLIGATORIO:
+1. Escribir la prueba primero (ROJO)
+2. Ejecutar la prueba - debe FALLAR
+3. Escribir la implementación mínima (VERDE)
+4. Ejecutar la prueba - debe PASAR
+5. Refactorizar (MEJORAR)
+6. Verificar cobertura (80%+)
+
+## Solución de Problemas en Fallos de Pruebas
+
+1. Usar el agente **tdd-guide**
+2. Verificar el aislamiento de las pruebas
+3. Verificar que los mocks sean correctos
+4. Corregir la implementación, no las pruebas (a menos que las pruebas estén equivocadas)
+
+## Soporte de Agentes
+
+- **tdd-guide** - Usar PROACTIVAMENTE para nuevas features, aplica escribir-pruebas-primero
+
+## Estructura de Pruebas (Patrón AAA)
+
+Preferir la estructura Arrange-Act-Assert para las pruebas:
+
+```typescript
+test('calcula la similitud correctamente', () => {
+  // Arrange
+  const vector1 = [1, 0, 0]
+  const vector2 = [0, 1, 0]
+
+  // Act
+  const similarity = calculateCosineSimilarity(vector1, vector2)
+
+  // Assert
+  expect(similarity).toBe(0)
+})
+```
+
+### Nomenclatura de Pruebas
+
+Usar nombres descriptivos que expliquen el comportamiento bajo prueba:
+
+```typescript
+test('retorna array vacío cuando ningún mercado coincide con la consulta', () => {})
+test('lanza error cuando falta la clave de API', () => {})
+test('cae de vuelta a búsqueda por substring cuando Redis no está disponible', () => {})
+```
@@ -0,0 +1,32 @@
+---
+paths:
+  - "**/*.go"
+  - "**/go.mod"
+  - "**/go.sum"
+---
+# Estilo de Código en Go
+
+> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de Go.
+
+## Formateo
+
+- **gofmt** y **goimports** son obligatorios — sin debates de estilo
+
+## Principios de Diseño
+
+- Aceptar interfaces, retornar structs
+- Mantener las interfaces pequeñas (1-3 métodos)
+
+## Manejo de Errores
+
+Siempre envolver los errores con contexto:
+
+```go
+if err != nil {
+    return fmt.Errorf("failed to create user: %w", err)
+}
+```
+
+## Referencia
+
+Ver skill: `golang-patterns` para idiomas y patrones completos de Go.
@@ -0,0 +1,17 @@
+---
+paths:
+  - "**/*.go"
+  - "**/go.mod"
+  - "**/go.sum"
+---
+# Hooks de Go
+
+> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de Go.
+
+## Hooks PostToolUse
+
+Configurar en `~/.claude/settings.json`:
+
+- **gofmt/goimports**: Auto-formatear archivos `.go` después de editar
+- **go vet**: Ejecutar análisis estático después de editar archivos `.go`
+- **staticcheck**: Ejecutar verificaciones estáticas extendidas en los paquetes modificados
@@ -0,0 +1,45 @@
+---
+paths:
+  - "**/*.go"
+  - "**/go.mod"
+  - "**/go.sum"
+---
+# Patrones de Go
+
+> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de Go.
+
+## Functional Options
+
+```go
+type Option func(*Server)
+
+func WithPort(port int) Option {
+    return func(s *Server) { s.port = port }
+}
+
+func NewServer(opts ...Option) *Server {
+    s := &Server{port: 8080}
+    for _, opt := range opts {
+        opt(s)
+    }
+    return s
+}
+```
+
+## Interfaces Pequeñas
+
+Definir las interfaces donde se usan, no donde se implementan.
+
+## Inyección de Dependencias
+
+Usar funciones constructor para inyectar dependencias:
+
+```go
+func NewUserService(repo UserRepository, logger Logger) *UserService {
+    return &UserService{repo: repo, logger: logger}
+}
+```
+
+## Referencia
+
+Ver skill: `golang-patterns` para patrones completos de Go incluyendo concurrencia, manejo de errores y organización de paquetes.
@@ -0,0 +1,34 @@
+---
+paths:
+  - "**/*.go"
+  - "**/go.mod"
+  - "**/go.sum"
+---
+# Seguridad en Go
+
+> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de Go.
+
+## Gestión de Secretos
+
+```go
+apiKey := os.Getenv("OPENAI_API_KEY")
+if apiKey == "" {
+    log.Fatal("OPENAI_API_KEY not configured")
+}
+```
+
+## Escaneo de Seguridad
+
+- Usar **gosec** para análisis estático de seguridad:
+  ```bash
+  gosec ./...
+  ```
+
+## Context y Timeouts
+
+Siempre usar `context.Context` para control de timeout:
+
+```go
+ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
+defer cancel()
+```
@@ -0,0 +1,31 @@
+---
+paths:
+  - "**/*.go"
+  - "**/go.mod"
+  - "**/go.sum"
+---
+# Pruebas en Go
+
+> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de Go.
+
+## Framework
+
+Usar el `go test` estándar con **pruebas table-driven**.
+
+## Detección de Condiciones de Carrera
+
+Siempre ejecutar con la flag `-race`:
+
+```bash
+go test -race ./...
+```
+
+## Cobertura
+
+```bash
+go test -cover ./...
+```
+
+## Referencia
+
+Ver skill: `golang-testing` para patrones detallados de pruebas en Go y helpers.
@@ -0,0 +1,42 @@
+---
+paths:
+  - "**/*.py"
+  - "**/*.pyi"
+---
+# Estilo de Código en Python
+
+> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de Python.
+
+## Estándares
+
+- Seguir las convenciones de **PEP 8**
+- Usar **anotaciones de tipos** en todas las firmas de funciones
+
+## Inmutabilidad
+
+Preferir estructuras de datos inmutables:
+
+```python
+from dataclasses import dataclass
+
+@dataclass(frozen=True)
+class User:
+    name: str
+    email: str
+
+from typing import NamedTuple
+
+class Point(NamedTuple):
+    x: float
+    y: float
+```
+
+## Formateo
+
+- **black** para formateo de código
+- **isort** para ordenamiento de imports
+- **ruff** para linting
+
+## Referencia
+
+Ver skill: `python-patterns` para idiomas y patrones completos de Python.
@@ -0,0 +1,19 @@
+---
+paths:
+  - "**/*.py"
+  - "**/*.pyi"
+---
+# Hooks de Python
+
+> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de Python.
+
+## Hooks PostToolUse
+
+Configurar en `~/.claude/settings.json`:
+
+- **black/ruff**: Auto-formatear archivos `.py` después de editar
+- **mypy/pyright**: Ejecutar verificación de tipos después de editar archivos `.py`
+
+## Advertencias
+
+- Advertir sobre sentencias `print()` en los archivos editados (usar el módulo `logging` en su lugar)
@@ -0,0 +1,39 @@
+---
+paths:
+  - "**/*.py"
+  - "**/*.pyi"
+---
+# Patrones de Python
+
+> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de Python.
+
+## Protocol (Duck Typing)
+
+```python
+from typing import Protocol
+
+class Repository(Protocol):
+    def find_by_id(self, id: str) -> dict | None: ...
+    def save(self, entity: dict) -> dict: ...
+```
+
+## Dataclasses como DTOs
+
+```python
+from dataclasses import dataclass
+
+@dataclass
+class CreateUserRequest:
+    name: str
+    email: str
+    age: int | None = None
+```
+
+## Context Managers y Generadores
+
+- Usar context managers (sentencia `with`) para gestión de recursos
+- Usar generadores para evaluación lazy e iteración eficiente en memoria
+
+## Referencia
+
+Ver skill: `python-patterns` para patrones completos incluyendo decoradores, concurrencia y organización de paquetes.
@@ -0,0 +1,30 @@
+---
+paths:
+  - "**/*.py"
+  - "**/*.pyi"
+---
+# Seguridad en Python
+
+> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de Python.
+
+## Gestión de Secretos
+
+```python
+import os
+from dotenv import load_dotenv
+
+load_dotenv()
+
+api_key = os.environ["OPENAI_API_KEY"]  # Lanza KeyError si falta
+```
+
+## Escaneo de Seguridad
+
+- Usar **bandit** para análisis estático de seguridad:
+  ```bash
+  bandit -r src/
+  ```
+
+## Referencia
+
+Ver skill: `django-security` para directrices de seguridad específicas de Django (si aplica).
@@ -0,0 +1,38 @@
+---
+paths:
+  - "**/*.py"
+  - "**/*.pyi"
+---
+# Pruebas en Python
+
+> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de Python.
+
+## Framework
+
+Usar **pytest** como framework de pruebas.
+
+## Cobertura
+
+```bash
+pytest --cov=src --cov-report=term-missing
+```
+
+## Organización de Pruebas
+
+Usar `pytest.mark` para categorización de pruebas:
+
+```python
+import pytest
+
+@pytest.mark.unit
+def test_calculate_total():
+    ...
+
+@pytest.mark.integration
+def test_database_connection():
+    ...
+```
+
+## Referencia
+
+Ver skill: `python-testing` para patrones detallados de pytest y fixtures.
@@ -0,0 +1,199 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# Estilo de Código en TypeScript/JavaScript
+
+> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de TypeScript/JavaScript.
+
+## Tipos e Interfaces
+
+Usar tipos para hacer las APIs públicas, modelos compartidos y props de componentes explícitos, legibles y reutilizables.
+
+### APIs Públicas
+
+- Agregar tipos de parámetros y retorno a funciones exportadas, utilidades compartidas y métodos públicos de clases
+- Dejar que TypeScript infiera tipos obvios de variables locales
+- Extraer formas de objetos inline repetidas en tipos o interfaces nombradas
+
+```typescript
+// INCORRECTO: Función exportada sin tipos explícitos
+export function formatUser(user) {
+  return `${user.firstName} ${user.lastName}`
+}
+
+// CORRECTO: Tipos explícitos en APIs públicas
+interface User {
+  firstName: string
+  lastName: string
+}
+
+export function formatUser(user: User): string {
+  return `${user.firstName} ${user.lastName}`
+}
+```
+
+### Interfaces vs. Type Aliases
+
+- Usar `interface` para formas de objetos que puedan ser extendidas o implementadas
+- Usar `type` para uniones, intersecciones, tuplas, tipos mapeados y tipos utilitarios
+- Preferir uniones de literales de string sobre `enum` a menos que se requiera un `enum` para interoperabilidad
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+type UserRole = 'admin' | 'member'
+type UserWithRole = User & {
+  role: UserRole
+}
+```
+
+### Evitar `any`
+
+- Evitar `any` en el código de aplicación
+- Usar `unknown` para entrada externa o no confiable, luego estrecharlo de forma segura
+- Usar genéricos cuando el tipo de un valor depende del llamador
+
+```typescript
+// INCORRECTO: any elimina la seguridad de tipos
+function getErrorMessage(error: any) {
+  return error.message
+}
+
+// CORRECTO: unknown fuerza estrechamiento seguro
+function getErrorMessage(error: unknown): string {
+  if (error instanceof Error) {
+    return error.message
+  }
+
+  return 'Unexpected error'
+}
+```
+
+### Props de React
+
+- Definir las props de componentes con una `interface` o `type` nombrado
+- Tipar las props de callback explícitamente
+- No usar `React.FC` a menos que haya una razón específica para hacerlo
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+interface UserCardProps {
+  user: User
+  onSelect: (id: string) => void
+}
+
+function UserCard({ user, onSelect }: UserCardProps) {
+  return <button onClick={() => onSelect(user.id)}>{user.email}</button>
+}
+```
+
+### Archivos JavaScript
+
+- En archivos `.js` y `.jsx`, usar JSDoc cuando los tipos mejoran la claridad y una migración a TypeScript no es práctica
+- Mantener JSDoc alineado con el comportamiento en tiempo de ejecución
+
+```javascript
+/**
+ * @param {{ firstName: string, lastName: string }} user
+ * @returns {string}
+ */
+export function formatUser(user) {
+  return `${user.firstName} ${user.lastName}`
+}
+```
+
+## Inmutabilidad
+
+Usar el operador spread para actualizaciones inmutables:
+
+```typescript
+interface User {
+  id: string
+  name: string
+}
+
+// INCORRECTO: Mutación
+function updateUser(user: User, name: string): User {
+  user.name = name // ¡MUTACIÓN!
+  return user
+}
+
+// CORRECTO: Inmutabilidad
+function updateUser(user: Readonly<User>, name: string): User {
+  return {
+    ...user,
+    name
+  }
+}
+```
+
+## Manejo de Errores
+
+Usar async/await con try-catch y estrechar errores unknown de forma segura:
+
+```typescript
+interface User {
+  id: string
+  email: string
+}
+
+declare function riskyOperation(userId: string): Promise<User>
+
+function getErrorMessage(error: unknown): string {
+  if (error instanceof Error) {
+    return error.message
+  }
+
+  return 'Unexpected error'
+}
+
+const logger = {
+  error: (message: string, error: unknown) => {
+    // Reemplazar con tu logger de producción (por ejemplo, pino o winston).
+  }
+}
+
+async function loadUser(userId: string): Promise<User> {
+  try {
+    const result = await riskyOperation(userId)
+    return result
+  } catch (error: unknown) {
+    logger.error('Operation failed', error)
+    throw new Error(getErrorMessage(error))
+  }
+}
+```
+
+## Validación de Entrada
+
+Usar Zod para validación basada en esquemas e inferir tipos desde el esquema:
+
+```typescript
+import { z } from 'zod'
+
+const userSchema = z.object({
+  email: z.string().email(),
+  age: z.number().int().min(0).max(150)
+})
+
+type UserInput = z.infer<typeof userSchema>
+
+const validated: UserInput = userSchema.parse(input)
+```
+
+## Console.log
+
+- Sin sentencias `console.log` en código de producción
+- Usar librerías de logging apropiadas en su lugar
+- Ver hooks para detección automática
@@ -0,0 +1,22 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# Hooks de TypeScript/JavaScript
+
+> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de TypeScript/JavaScript.
+
+## Hooks PostToolUse
+
+Configurar en `~/.claude/settings.json`:
+
+- **Prettier**: Auto-formatear archivos JS/TS después de editar
+- **Verificación de TypeScript**: Ejecutar `tsc` después de editar archivos `.ts`/`.tsx`
+- **Advertencia de console.log**: Advertir sobre `console.log` en los archivos editados
+
+## Hooks Stop
+
+- **Auditoría de console.log**: Verificar todos los archivos modificados en busca de `console.log` antes de que termine la sesión
@@ -0,0 +1,52 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# Patrones de TypeScript/JavaScript
+
+> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de TypeScript/JavaScript.
+
+## Formato de Respuesta de API
+
+```typescript
+interface ApiResponse<T> {
+  success: boolean
+  data?: T
+  error?: string
+  meta?: {
+    total: number
+    page: number
+    limit: number
+  }
+}
+```
+
+## Patrón de Custom Hooks
+
+```typescript
+export function useDebounce<T>(value: T, delay: number): T {
+  const [debouncedValue, setDebouncedValue] = useState<T>(value)
+
+  useEffect(() => {
+    const handler = setTimeout(() => setDebouncedValue(value), delay)
+    return () => clearTimeout(handler)
+  }, [value, delay])
+
+  return debouncedValue
+}
+```
+
+## Patrón Repository
+
+```typescript
+interface Repository<T> {
+  findAll(filters?: Filters): Promise<T[]>
+  findById(id: string): Promise<T | null>
+  create(data: CreateDto): Promise<T>
+  update(id: string, data: UpdateDto): Promise<T>
+  delete(id: string): Promise<void>
+}
+```
@@ -0,0 +1,28 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# Seguridad en TypeScript/JavaScript
+
+> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de TypeScript/JavaScript.
+
+## Gestión de Secretos
+
+```typescript
+// NUNCA: Secretos hardcodeados
+const apiKey = "sk-proj-xxxxx"
+
+// SIEMPRE: Variables de entorno
+const apiKey = process.env.OPENAI_API_KEY
+
+if (!apiKey) {
+  throw new Error('OPENAI_API_KEY not configured')
+}
+```
+
+## Soporte de Agentes
+
+- Usar la skill **security-reviewer** para auditorías de seguridad exhaustivas
@@ -0,0 +1,18 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.tsx"
+  - "**/*.js"
+  - "**/*.jsx"
+---
+# Pruebas en TypeScript/JavaScript
+
+> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de TypeScript/JavaScript.
+
+## Testing E2E
+
+Usar **Playwright** como framework de testing E2E para flujos de usuario críticos.
+
+## Soporte de Agentes
+
+- **e2e-runner** - Especialista en testing E2E con Playwright