mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-14 04:01:30 +08:00
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>
This commit is contained in:
Santiago González Siordia
committed by
GitHub
GitHub
parent
28b78dd7bf
commit
ac0f11c640
@@ -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', () => {})
|
||||
```
|
||||
Reference in New Issue
Block a user