mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-14 12:11:27 +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,66 @@
|
||||
---
|
||||
description: Detectar el sistema de build del proyecto y corregir incrementalmente errores de build/tipos con cambios mínimos y seguros.
|
||||
---
|
||||
|
||||
# Build y Corrección
|
||||
|
||||
Corregir incrementalmente errores de build y de tipos con cambios mínimos y seguros.
|
||||
|
||||
## Paso 1: Detectar el Sistema de Build
|
||||
|
||||
Identificar la herramienta de build del proyecto y ejecutar el build:
|
||||
|
||||
| Indicador | Comando de Build |
|
||||
|-----------|-----------------|
|
||||
| `package.json` con script `build` | `npm run build` o `pnpm build` |
|
||||
| `tsconfig.json` (solo TypeScript) | `npx tsc --noEmit` |
|
||||
| `Cargo.toml` | `cargo build 2>&1` |
|
||||
| `pom.xml` | `mvn compile` |
|
||||
| `build.gradle` | `./gradlew compileJava` |
|
||||
| `go.mod` | `go build ./...` |
|
||||
| `pyproject.toml` | `python -m compileall -q .` o `mypy .` |
|
||||
|
||||
## Paso 2: Parsear y Agrupar Errores
|
||||
|
||||
1. Ejecutar el comando de build y capturar stderr
|
||||
2. Agrupar errores por ruta de archivo
|
||||
3. Ordenar por orden de dependencia (corregir imports/tipos antes que errores de lógica)
|
||||
4. Contar errores totales para seguimiento del progreso
|
||||
|
||||
## Paso 3: Bucle de Corrección (Un Error a la Vez)
|
||||
|
||||
Para cada error:
|
||||
|
||||
1. **Leer el archivo** — Usar la herramienta Read para ver el contexto del error (10 líneas alrededor del error)
|
||||
2. **Diagnosticar** — Identificar la causa raíz (import faltante, tipo incorrecto, error de sintaxis)
|
||||
3. **Corregir mínimamente** — Usar la herramienta Edit para el cambio más pequeño que resuelva el error
|
||||
4. **Re-ejecutar el build** — Verificar que el error desapareció y que no se introdujeron nuevos errores
|
||||
5. **Continuar** — Seguir con los errores restantes
|
||||
|
||||
## Paso 4: Salvaguardas
|
||||
|
||||
Parar y preguntar al usuario si:
|
||||
- Una corrección introduce **más errores de los que resuelve**
|
||||
- El **mismo error persiste después de 3 intentos** (probablemente un problema más profundo)
|
||||
- La corrección requiere **cambios arquitectónicos** (no es solo una corrección de build)
|
||||
- Los errores de build provienen de **dependencias faltantes** (se necesita `npm install`, `cargo add`, etc.)
|
||||
|
||||
## Paso 5: Resumen
|
||||
|
||||
Mostrar resultados:
|
||||
- Errores corregidos (con rutas de archivos)
|
||||
- Errores restantes (si los hay)
|
||||
- Nuevos errores introducidos (debe ser cero)
|
||||
- Próximos pasos sugeridos para problemas no resueltos
|
||||
|
||||
## Estrategias de Recuperación
|
||||
|
||||
| Situación | Acción |
|
||||
|-----------|--------|
|
||||
| Módulo/import faltante | Verificar si el paquete está instalado; sugerir comando de instalación |
|
||||
| Incompatibilidad de tipos | Leer ambas definiciones de tipo; corregir el tipo más restrictivo |
|
||||
| Dependencia circular | Identificar el ciclo con el grafo de imports; sugerir extracción |
|
||||
| Conflicto de versiones | Verificar `package.json` / `Cargo.toml` para restricciones de versión |
|
||||
| Mala configuración de herramienta de build | Leer el archivo de configuración; comparar con valores por defecto funcionales |
|
||||
|
||||
Corregir un error a la vez por seguridad. Preferir diffs mínimos sobre refactorización.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
description: Crear, verificar o listar puntos de control del flujo de trabajo después de ejecutar verificaciones.
|
||||
---
|
||||
|
||||
# Comando Checkpoint
|
||||
|
||||
Crear o verificar un punto de control en tu flujo de trabajo.
|
||||
|
||||
## Uso
|
||||
|
||||
`/checkpoint [create|verify|list] [nombre]`
|
||||
|
||||
## Crear Checkpoint
|
||||
|
||||
Al crear un checkpoint:
|
||||
|
||||
1. Ejecutar `/verify quick` para asegurarse de que el estado actual está limpio
|
||||
2. Crear un git stash o commit con el nombre del checkpoint
|
||||
3. Registrar el checkpoint en `.claude/checkpoints.log`:
|
||||
|
||||
```bash
|
||||
echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
|
||||
```
|
||||
|
||||
4. Reportar que el checkpoint fue creado
|
||||
|
||||
## Verificar Checkpoint
|
||||
|
||||
Al verificar contra un checkpoint:
|
||||
|
||||
1. Leer el checkpoint desde el log
|
||||
2. Comparar el estado actual con el checkpoint:
|
||||
- Archivos añadidos desde el checkpoint
|
||||
- Archivos modificados desde el checkpoint
|
||||
- Tasa de pruebas pasadas ahora vs entonces
|
||||
- Cobertura ahora vs entonces
|
||||
|
||||
3. Reportar:
|
||||
```
|
||||
COMPARACIÓN DE CHECKPOINT: $NAME
|
||||
============================
|
||||
Archivos cambiados: X
|
||||
Pruebas: +Y pasaron / -Z fallaron
|
||||
Cobertura: +X% / -Y%
|
||||
Build: [PASS/FAIL]
|
||||
```
|
||||
|
||||
## Listar Checkpoints
|
||||
|
||||
Mostrar todos los checkpoints con:
|
||||
- Nombre
|
||||
- Marca de tiempo
|
||||
- SHA de git
|
||||
- Estado (actual, detrás, adelante)
|
||||
|
||||
## Flujo de Trabajo
|
||||
|
||||
Flujo típico de checkpoints:
|
||||
|
||||
```
|
||||
[Inicio] --> /checkpoint create "feature-start"
|
||||
|
|
||||
[Implementar] --> /checkpoint create "core-done"
|
||||
|
|
||||
[Probar] --> /checkpoint verify "core-done"
|
||||
|
|
||||
[Refactorizar] --> /checkpoint create "refactor-done"
|
||||
|
|
||||
[PR] --> /checkpoint verify "feature-start"
|
||||
```
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `create <nombre>` - Crear checkpoint con nombre
|
||||
- `verify <nombre>` - Verificar contra checkpoint con nombre
|
||||
- `list` - Mostrar todos los checkpoints
|
||||
- `clear` - Eliminar checkpoints antiguos (conserva los últimos 5)
|
||||
@@ -0,0 +1,289 @@
|
||||
---
|
||||
description: Revisión de código — cambios locales no confirmados o PR de GitHub (pasa número/URL del PR para modo PR)
|
||||
argument-hint: [número-pr | url-pr | vacío para revisión local]
|
||||
---
|
||||
|
||||
# Revisión de Código
|
||||
|
||||
> Modo de revisión de PR adaptado de PRPs-agentic-eng por Wirasm. Parte de la serie de flujos de trabajo PRP.
|
||||
|
||||
**Entrada**: $ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Selección de Modo
|
||||
|
||||
Si `$ARGUMENTS` contiene un número de PR, URL de PR, o `--pr`:
|
||||
→ Ir a **Modo de Revisión de PR** más abajo.
|
||||
|
||||
De lo contrario:
|
||||
→ Usar **Modo de Revisión Local**.
|
||||
|
||||
---
|
||||
|
||||
## Modo de Revisión Local
|
||||
|
||||
Revisión exhaustiva de seguridad y calidad de los cambios no confirmados.
|
||||
|
||||
### Fase 1 — RECOPILAR
|
||||
|
||||
```bash
|
||||
git diff --name-only HEAD
|
||||
```
|
||||
|
||||
Si no hay archivos modificados, detener: "Nada que revisar."
|
||||
|
||||
### Fase 2 — REVISAR
|
||||
|
||||
Leer cada archivo modificado completo. Verificar:
|
||||
|
||||
**Problemas de Seguridad (CRÍTICO):**
|
||||
- Credenciales, claves de API, tokens hardcodeados
|
||||
- Vulnerabilidades de inyección SQL
|
||||
- Vulnerabilidades XSS
|
||||
- Validación de entrada faltante
|
||||
- Dependencias inseguras
|
||||
- Riesgos de path traversal
|
||||
|
||||
**Calidad de Código (ALTO):**
|
||||
- Funciones de más de 50 líneas
|
||||
- Archivos de más de 800 líneas
|
||||
- Profundidad de anidamiento mayor a 4 niveles
|
||||
- Manejo de errores faltante
|
||||
- Sentencias console.log
|
||||
- Comentarios TODO/FIXME
|
||||
- JSDoc faltante para APIs públicas
|
||||
|
||||
**Buenas Prácticas (MEDIO):**
|
||||
- Patrones de mutación (usar inmutable en su lugar)
|
||||
- Uso de emojis en código/comentarios
|
||||
- Pruebas faltantes para código nuevo
|
||||
- Problemas de accesibilidad (a11y)
|
||||
|
||||
### Fase 3 — REPORTE
|
||||
|
||||
Generar reporte con:
|
||||
- Severidad: CRÍTICO, ALTO, MEDIO, BAJO
|
||||
- Ubicación del archivo y números de línea
|
||||
- Descripción del problema
|
||||
- Corrección sugerida
|
||||
|
||||
Bloquear commit si se encuentran problemas CRÍTICOS o ALTOS.
|
||||
Nunca aprobar código con vulnerabilidades de seguridad.
|
||||
|
||||
---
|
||||
|
||||
## Modo de Revisión de PR
|
||||
|
||||
Revisión exhaustiva de PR de GitHub — obtiene el diff, lee los archivos completos, ejecuta validación, publica la revisión.
|
||||
|
||||
### Fase 1 — OBTENER
|
||||
|
||||
Parsear la entrada para determinar el PR:
|
||||
|
||||
| Entrada | Acción |
|
||||
|---|---|
|
||||
| Número (ej. `42`) | Usar como número de PR |
|
||||
| URL (`github.com/.../pull/42`) | Extraer número de PR |
|
||||
| Nombre de branch | Encontrar PR via `gh pr list --head <branch>` |
|
||||
|
||||
```bash
|
||||
gh pr view <NÚMERO> --json number,title,body,author,baseRefName,headRefName,changedFiles,additions,deletions
|
||||
gh pr diff <NÚMERO>
|
||||
```
|
||||
|
||||
Si no se encuentra el PR, detener con error. Almacenar metadatos del PR para fases posteriores.
|
||||
|
||||
### Fase 2 — CONTEXTO
|
||||
|
||||
Construir contexto de revisión:
|
||||
|
||||
1. **Reglas del proyecto** — Leer `CLAUDE.md`, `.claude/docs/`, y cualquier guía de contribución
|
||||
2. **Artefactos de planificación** — Verificar `.claude/prds/`, `.claude/plans/`, `.claude/reviews/`, y legacy `.claude/PRPs/{prds,plans,reports,reviews}/` para contexto relacionado con este PR
|
||||
3. **Intención del PR** — Parsear la descripción del PR para objetivos, issues vinculados, planes de prueba
|
||||
4. **Archivos modificados** — Listar todos los archivos modificados y categorizar por tipo (fuente, prueba, config, docs)
|
||||
|
||||
### Fase 3 — REVISAR
|
||||
|
||||
Leer cada archivo modificado **completo** (no solo los hunks del diff — se necesita el contexto circundante).
|
||||
|
||||
Para revisiones de PR, obtener el contenido completo del archivo en la revisión head del PR:
|
||||
```bash
|
||||
gh pr diff <NÚMERO> --name-only | while IFS= read -r file; do
|
||||
gh api "repos/{owner}/{repo}/contents/$file?ref=<head-branch>" --jq '.content' | base64 -d
|
||||
done
|
||||
```
|
||||
|
||||
Aplicar la lista de verificación de revisión en 7 categorías:
|
||||
|
||||
| Categoría | Qué Verificar |
|
||||
|---|---|
|
||||
| **Corrección** | Errores lógicos, off-by-ones, manejo de null, casos límite, condiciones de carrera |
|
||||
| **Seguridad de Tipos** | Incompatibilidades de tipos, castings inseguros, uso de `any`, generics faltantes |
|
||||
| **Cumplimiento de Patrones** | Coincide con convenciones del proyecto (nomenclatura, estructura de archivos, manejo de errores, imports) |
|
||||
| **Seguridad** | Inyección, brechas de auth, exposición de secretos, SSRF, path traversal, XSS |
|
||||
| **Rendimiento** | Consultas N+1, índices faltantes, bucles sin límite, fugas de memoria, payloads grandes |
|
||||
| **Completitud** | Pruebas faltantes, manejo de errores faltante, migraciones incompletas, docs faltante |
|
||||
| **Mantenibilidad** | Código muerto, números mágicos, anidamiento profundo, nomenclatura poco clara, tipos faltantes |
|
||||
|
||||
Asignar severidad a cada hallazgo:
|
||||
|
||||
| Severidad | Significado | Acción |
|
||||
|---|---|---|
|
||||
| **CRÍTICO** | Vulnerabilidad de seguridad o riesgo de pérdida de datos | Debe corregirse antes de merge |
|
||||
| **ALTO** | Bug o error lógico que probablemente causará problemas | Debería corregirse antes de merge |
|
||||
| **MEDIO** | Problema de calidad de código o buena práctica faltante | Se recomienda corregir |
|
||||
| **BAJO** | Detalle de estilo o sugerencia menor | Opcional |
|
||||
|
||||
### Fase 4 — VALIDAR
|
||||
|
||||
Ejecutar comandos de validación disponibles:
|
||||
|
||||
Detectar el tipo de proyecto desde los archivos de configuración (`package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, etc.), luego ejecutar los comandos apropiados:
|
||||
|
||||
**Node.js / TypeScript** (tiene `package.json`):
|
||||
```bash
|
||||
npm run typecheck 2>/dev/null || npx tsc --noEmit 2>/dev/null # Verificación de tipos
|
||||
npm run lint # Lint
|
||||
npm test # Pruebas
|
||||
npm run build # Build
|
||||
```
|
||||
|
||||
**Rust** (tiene `Cargo.toml`):
|
||||
```bash
|
||||
cargo clippy -- -D warnings # Lint
|
||||
cargo test # Pruebas
|
||||
cargo build # Build
|
||||
```
|
||||
|
||||
**Go** (tiene `go.mod`):
|
||||
```bash
|
||||
go vet ./... # Lint
|
||||
go test ./... # Pruebas
|
||||
go build ./... # Build
|
||||
```
|
||||
|
||||
**Python** (tiene `pyproject.toml` / `setup.py`):
|
||||
```bash
|
||||
pytest # Pruebas
|
||||
```
|
||||
|
||||
Ejecutar solo los comandos que apliquen al tipo de proyecto detectado. Registrar pass/fail para cada uno.
|
||||
|
||||
### Fase 5 — DECIDIR
|
||||
|
||||
Formular recomendación basada en los hallazgos:
|
||||
|
||||
| Condición | Decisión |
|
||||
|---|---|
|
||||
| Cero problemas CRÍTICOS/ALTOS, validación pasa | **APROBAR** |
|
||||
| Solo problemas MEDIO/BAJO, validación pasa | **APROBAR** con comentarios |
|
||||
| Cualquier problema ALTO o fallos de validación | **SOLICITAR CAMBIOS** |
|
||||
| Cualquier problema CRÍTICO | **BLOQUEAR** — debe corregirse antes del merge |
|
||||
|
||||
Casos especiales:
|
||||
- PR en borrador → Siempre usar **COMENTAR** (no aprobar/bloquear)
|
||||
- Solo cambios de docs/config → Revisión más ligera, enfocada en corrección
|
||||
- Flag explícito `--approve` o `--request-changes` → Anular decisión (pero reportar todos los hallazgos)
|
||||
|
||||
### Fase 6 — REPORTE
|
||||
|
||||
Crear artefacto de revisión en `.claude/reviews/pr-<NÚMERO>-review.md` a menos que el repositorio ya use el legacy `.claude/PRPs/reviews/` para este flujo:
|
||||
|
||||
```markdown
|
||||
# Revisión de PR: #<NÚMERO> — <TÍTULO>
|
||||
|
||||
**Revisado**: <fecha>
|
||||
**Autor**: <autor>
|
||||
**Branch**: <head> → <base>
|
||||
**Decisión**: APROBAR | SOLICITAR CAMBIOS | BLOQUEAR
|
||||
|
||||
## Resumen
|
||||
<evaluación general en 1-2 oraciones>
|
||||
|
||||
## Hallazgos
|
||||
|
||||
### CRÍTICO
|
||||
<hallazgos o "Ninguno">
|
||||
|
||||
### ALTO
|
||||
<hallazgos o "Ninguno">
|
||||
|
||||
### MEDIO
|
||||
<hallazgos o "Ninguno">
|
||||
|
||||
### BAJO
|
||||
<hallazgos o "Ninguno">
|
||||
|
||||
## Resultados de Validación
|
||||
|
||||
| Verificación | Resultado |
|
||||
|---|---|
|
||||
| Verificación de tipos | Pass / Fail / Omitido |
|
||||
| Lint | Pass / Fail / Omitido |
|
||||
| Pruebas | Pass / Fail / Omitido |
|
||||
| Build | Pass / Fail / Omitido |
|
||||
|
||||
## Archivos Revisados
|
||||
<lista de archivos con tipo de cambio: Agregado/Modificado/Eliminado>
|
||||
```
|
||||
|
||||
### Fase 7 — PUBLICAR
|
||||
|
||||
Publicar la revisión en GitHub:
|
||||
|
||||
```bash
|
||||
# Si APROBAR
|
||||
gh pr review <NÚMERO> --approve --body "<resumen de la revisión>"
|
||||
|
||||
# Si SOLICITAR CAMBIOS
|
||||
gh pr review <NÚMERO> --request-changes --body "<resumen con correcciones requeridas>"
|
||||
|
||||
# Si solo COMENTAR (PR en borrador o informativo)
|
||||
gh pr review <NÚMERO> --comment --body "<resumen>"
|
||||
```
|
||||
|
||||
Para comentarios en línea en líneas específicas, usar la API de comentarios de revisión de GitHub:
|
||||
```bash
|
||||
gh api "repos/{owner}/{repo}/pulls/<NÚMERO>/comments" \
|
||||
-f body="<comentario>" \
|
||||
-f path="<archivo>" \
|
||||
-F line=<número-de-línea> \
|
||||
-f side="RIGHT" \
|
||||
-f commit_id="$(gh pr view <NÚMERO> --json headRefOid --jq .headRefOid)"
|
||||
```
|
||||
|
||||
Alternativamente, publicar una sola revisión con múltiples comentarios en línea a la vez:
|
||||
```bash
|
||||
gh api "repos/{owner}/{repo}/pulls/<NÚMERO>/reviews" \
|
||||
-f event="COMMENT" \
|
||||
-f body="<resumen general>" \
|
||||
--input comments.json # [{"path": "archivo", "line": N, "body": "comentario"}, ...]
|
||||
```
|
||||
|
||||
### Fase 8 — SALIDA
|
||||
|
||||
Reportar al usuario:
|
||||
|
||||
```
|
||||
PR #<NÚMERO>: <TÍTULO>
|
||||
Decisión: <APROBAR|SOLICITAR_CAMBIOS|BLOQUEAR>
|
||||
|
||||
Problemas: <cantidad_críticos> críticos, <cantidad_altos> altos, <cantidad_medios> medios, <cantidad_bajos> bajos
|
||||
Validación: <cantidad_pass>/<total> verificaciones pasaron
|
||||
|
||||
Artefactos:
|
||||
Revisión: .claude/reviews/pr-<NÚMERO>-review.md
|
||||
GitHub: <URL del PR>
|
||||
|
||||
Próximos pasos:
|
||||
- <sugerencias contextuales basadas en la decisión>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Casos Límite
|
||||
|
||||
- **Sin CLI `gh`**: Volver a revisión solo local (leer el diff, omitir publicación en GitHub). Advertir al usuario.
|
||||
- **Branches divergidos**: Sugerir `git fetch origin && git rebase origin/<base>` antes de la revisión.
|
||||
- **PRs grandes (>50 archivos)**: Advertir sobre el alcance de la revisión. Enfocarse primero en cambios de fuente, luego pruebas, luego config/docs.
|
||||
@@ -0,0 +1,336 @@
|
||||
---
|
||||
description: Crear y ejecutar pruebas end-to-end con Playwright. Genera flujos de prueba, ejecuta los tests, captura capturas de pantalla/videos/trazas y sube artefactos.
|
||||
---
|
||||
|
||||
# Comando E2E
|
||||
|
||||
Este comando invoca al agente **e2e-runner** para crear, mantener y ejecutar pruebas end-to-end usando Playwright.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Crear Flujos de Prueba** - Generar pruebas Playwright para flujos de usuario
|
||||
2. **Ejecutar Pruebas E2E** - Ejecutar los tests en múltiples navegadores
|
||||
3. **Capturar Artefactos** - Capturas de pantalla, videos y trazas en caso de error
|
||||
4. **Subir Resultados** - Reportes HTML y JUnit XML
|
||||
5. **Identificar Pruebas Inestables** - Poner en cuarentena tests no deterministas
|
||||
|
||||
## Cuándo Usarlo
|
||||
|
||||
Usa el comando `/e2e` cuando:
|
||||
- Pruebes flujos de usuario críticos (login, transacciones, pagos)
|
||||
- Verifiques que flujos de múltiples pasos funcionen de extremo a extremo
|
||||
- Pruebes interacciones de UI y navegación
|
||||
- Valides la integración entre frontend y backend
|
||||
- Te prepares para despliegue a producción
|
||||
|
||||
## Cómo Funciona
|
||||
|
||||
El agente e2e-runner:
|
||||
|
||||
1. **Analizará el flujo de usuario** e identificará los escenarios de prueba
|
||||
2. **Generará la prueba Playwright** usando el patrón Page Object Model
|
||||
3. **Ejecutará las pruebas** (Chrome, Firefox, Safari)
|
||||
4. **Capturará los fallos** con capturas de pantalla, videos y trazas
|
||||
5. **Generará un reporte** con los resultados y artefactos
|
||||
6. **Identificará pruebas inestables** y sugerirá correcciones
|
||||
|
||||
## Ejemplo de Uso
|
||||
|
||||
```
|
||||
Usuario: /e2e Probar el flujo de búsqueda y visualización de mercados
|
||||
|
||||
Agente (e2e-runner):
|
||||
# Creación de Prueba E2E: Flujo de Búsqueda y Visualización de Mercados
|
||||
|
||||
## Escenario de Prueba Identificado
|
||||
|
||||
**Flujo de Usuario:** Búsqueda de Mercados → Ver Resultados → Click en Mercado → Ver Detalles
|
||||
|
||||
**Cobertura de Prueba:**
|
||||
1. Ir a la página de mercados
|
||||
2. Realizar búsqueda semántica
|
||||
3. Validar resultados de búsqueda
|
||||
4. Click en el primer resultado
|
||||
5. Validar que carga la página de detalles del mercado
|
||||
6. Validar que el gráfico se renderiza
|
||||
|
||||
## Código de Prueba Generado
|
||||
|
||||
```typescript
|
||||
// tests/e2e/markets/search-and-view.spec.ts
|
||||
import { test, expect } from '@playwright/test'
|
||||
import { MarketsPage } from '../../pages/MarketsPage'
|
||||
import { MarketDetailsPage } from '../../pages/MarketDetailsPage'
|
||||
|
||||
test.describe('Market Search and View Flow', () => {
|
||||
test('el usuario puede buscar mercados y ver detalles', async ({ page }) => {
|
||||
// 1. Ir a la página de mercados
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Validar que la página cargó
|
||||
await expect(page).toHaveTitle(/Markets/)
|
||||
await expect(page.locator('h1')).toContainText('Markets')
|
||||
|
||||
// 2. Realizar búsqueda semántica
|
||||
await marketsPage.searchMarkets('election')
|
||||
|
||||
// Esperar respuesta de la API
|
||||
await page.waitForResponse(resp =>
|
||||
resp.url().includes('/api/markets/search') && resp.status() === 200
|
||||
)
|
||||
|
||||
// 3. Validar resultados de búsqueda
|
||||
const marketCards = marketsPage.marketCards
|
||||
await expect(marketCards.first()).toBeVisible()
|
||||
const resultCount = await marketCards.count()
|
||||
expect(resultCount).toBeGreaterThan(0)
|
||||
|
||||
// Tomar captura de pantalla de los resultados
|
||||
await page.screenshot({ path: 'artifacts/search-results.png' })
|
||||
|
||||
// 4. Click en el primer resultado
|
||||
const firstMarketTitle = await marketCards.first().textContent()
|
||||
await marketCards.first().click()
|
||||
|
||||
// 5. Validar que carga la página de detalles del mercado
|
||||
await expect(page).toHaveURL(/\/markets\/[a-z0-9-]+/)
|
||||
|
||||
const detailsPage = new MarketDetailsPage(page)
|
||||
await expect(detailsPage.marketName).toBeVisible()
|
||||
await expect(detailsPage.marketDescription).toBeVisible()
|
||||
|
||||
// 6. Validar que el gráfico se renderiza
|
||||
await expect(detailsPage.priceChart).toBeVisible()
|
||||
|
||||
// Verificar que el nombre del mercado coincide
|
||||
const detailsTitle = await detailsPage.marketName.textContent()
|
||||
expect(detailsTitle?.toLowerCase()).toContain(
|
||||
firstMarketTitle?.toLowerCase().substring(0, 20) || ''
|
||||
)
|
||||
|
||||
// Tomar captura de pantalla de los detalles del mercado
|
||||
await page.screenshot({ path: 'artifacts/market-details.png' })
|
||||
})
|
||||
|
||||
test('búsqueda sin resultados debe mostrar estado vacío', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Buscar un mercado que no existe
|
||||
await marketsPage.searchMarkets('xyznonexistentmarket123456')
|
||||
|
||||
// Validar estado vacío
|
||||
await expect(page.locator('[data-testid="no-results"]')).toBeVisible()
|
||||
await expect(page.locator('[data-testid="no-results"]')).toContainText(
|
||||
/no.*results|no.*markets/i
|
||||
)
|
||||
|
||||
const marketCount = await marketsPage.marketCards.count()
|
||||
expect(marketCount).toBe(0)
|
||||
})
|
||||
|
||||
test('puede limpiar la búsqueda y ver todos los mercados de nuevo', async ({ page }) => {
|
||||
const marketsPage = new MarketsPage(page)
|
||||
await marketsPage.goto()
|
||||
|
||||
// Cantidad inicial de mercados
|
||||
const initialCount = await marketsPage.marketCards.count()
|
||||
|
||||
// Realizar búsqueda
|
||||
await marketsPage.searchMarkets('trump')
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Validar resultados filtrados
|
||||
const filteredCount = await marketsPage.marketCards.count()
|
||||
expect(filteredCount).toBeLessThan(initialCount)
|
||||
|
||||
// Limpiar búsqueda
|
||||
await marketsPage.searchInput.clear()
|
||||
await page.waitForLoadState('networkidle')
|
||||
|
||||
// Validar que se muestran todos los mercados de nuevo
|
||||
const finalCount = await marketsPage.marketCards.count()
|
||||
expect(finalCount).toBe(initialCount)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Ejecutar las Pruebas
|
||||
|
||||
```bash
|
||||
# Ejecutar la prueba generada
|
||||
npx playwright test tests/e2e/markets/search-and-view.spec.ts
|
||||
|
||||
Corriendo 3 pruebas usando 3 workers
|
||||
|
||||
✓ [chromium] › search-and-view.spec.ts:5:3 › el usuario puede buscar mercados y ver detalles (4.2s)
|
||||
✓ [chromium] › search-and-view.spec.ts:52:3 › búsqueda sin resultados muestra estado vacío (1.8s)
|
||||
✓ [chromium] › search-and-view.spec.ts:67:3 › puede limpiar búsqueda y ver todos los mercados (2.9s)
|
||||
|
||||
3 passed (9.1s)
|
||||
|
||||
Artefactos generados:
|
||||
- artifacts/search-results.png
|
||||
- artifacts/market-details.png
|
||||
- playwright-report/index.html
|
||||
```
|
||||
|
||||
## Reporte de Pruebas
|
||||
|
||||
```
|
||||
╔══════════════════════════════════════════════════════════════╗
|
||||
║ Resultados de Pruebas E2E ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ Estado: PASS: TODAS LAS PRUEBAS PASARON ║
|
||||
║ Total: 3 pruebas ║
|
||||
║ Pasaron: 3 (100%) ║
|
||||
║ Fallaron: 0 ║
|
||||
║ Inestables: 0 ║
|
||||
║ Duración: 9.1s ║
|
||||
╚══════════════════════════════════════════════════════════════╝
|
||||
|
||||
Artefactos:
|
||||
Capturas de pantalla: 2 archivos
|
||||
Videos: 0 archivos (solo en fallo)
|
||||
Trazas: 0 archivos (solo en fallo)
|
||||
Reporte HTML: playwright-report/index.html
|
||||
|
||||
Ver reporte: npx playwright show-report
|
||||
```
|
||||
|
||||
PASS: ¡Suite de pruebas E2E lista para integración CI/CD!
|
||||
```
|
||||
|
||||
## Artefactos de Prueba
|
||||
|
||||
Cuando las pruebas se ejecutan, se capturan estos artefactos:
|
||||
|
||||
**En Todas las Pruebas:**
|
||||
- Reporte HTML con cronología y resultados
|
||||
- JUnit XML para integración CI
|
||||
|
||||
**Solo en Caso de Fallo:**
|
||||
- Captura de pantalla del estado fallido
|
||||
- Grabación de video de la prueba
|
||||
- Archivo de traza para depuración (reproducción paso a paso)
|
||||
- Logs de red
|
||||
- Logs de consola
|
||||
|
||||
## Ver Artefactos
|
||||
|
||||
```bash
|
||||
# Ver reporte HTML en el navegador
|
||||
npx playwright show-report
|
||||
|
||||
# Ver archivo de traza específico
|
||||
npx playwright show-trace artifacts/trace-abc123.zip
|
||||
|
||||
# Las capturas de pantalla se guardan en el directorio artifacts/
|
||||
open artifacts/search-results.png
|
||||
```
|
||||
|
||||
## Detección de Pruebas Inestables
|
||||
|
||||
Si una prueba falla de forma intermitente:
|
||||
|
||||
```
|
||||
ADVERTENCIA: PRUEBA INESTABLE DETECTADA: tests/e2e/markets/trade.spec.ts
|
||||
|
||||
La prueba pasó 7 de 10 ejecuciones (70% de tasa de éxito)
|
||||
|
||||
Fallo más frecuente:
|
||||
"Timeout esperando elemento '[data-testid="confirm-btn"]'"
|
||||
|
||||
Correcciones sugeridas:
|
||||
1. Agregar espera explícita: await page.waitForSelector('[data-testid="confirm-btn"]')
|
||||
2. Aumentar timeout: { timeout: 10000 }
|
||||
3. Verificar condiciones de carrera en el componente
|
||||
4. Validar que el elemento no está oculto por animación
|
||||
|
||||
Sugerencia de cuarentena: Marcar como test.fixme() hasta que se corrija
|
||||
```
|
||||
|
||||
## Configuración de Navegadores
|
||||
|
||||
Las pruebas se ejecutan en múltiples navegadores por defecto:
|
||||
- PASS: Chromium (Desktop Chrome)
|
||||
- PASS: Firefox (Desktop)
|
||||
- PASS: WebKit (Desktop Safari)
|
||||
- PASS: Mobile Chrome (opcional)
|
||||
|
||||
Configura `playwright.config.ts` para ajustar los navegadores.
|
||||
|
||||
## Integración CI/CD
|
||||
|
||||
Agregar a tu pipeline CI:
|
||||
|
||||
```yaml
|
||||
# .github/workflows/e2e.yml
|
||||
- name: Install Playwright
|
||||
run: npx playwright install --with-deps
|
||||
|
||||
- name: Run E2E tests
|
||||
run: npx playwright test
|
||||
|
||||
- name: Upload artifacts
|
||||
if: always()
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: playwright-report
|
||||
path: playwright-report/
|
||||
```
|
||||
|
||||
## Buenas Prácticas
|
||||
|
||||
**HAZ:**
|
||||
- PASS: Usa Page Object Model para mantenibilidad
|
||||
- PASS: Usa atributos data-testid para los selectores
|
||||
- PASS: Espera respuestas de API, no timeouts arbitrarios
|
||||
- PASS: Prueba los flujos de usuario críticos de extremo a extremo
|
||||
- PASS: Ejecuta las pruebas antes de hacer merge a main
|
||||
- PASS: Inspecciona los artefactos cuando las pruebas fallen
|
||||
|
||||
**NO HAGAS:**
|
||||
- FAIL: No uses selectores frágiles (las clases CSS pueden cambiar)
|
||||
- FAIL: No pruebes detalles de implementación
|
||||
- FAIL: No ejecutes pruebas contra producción
|
||||
- FAIL: No ignores pruebas inestables
|
||||
- FAIL: No omitas la inspección de artefactos en fallos
|
||||
- FAIL: No pruebes todos los casos límite con E2E (usa pruebas unitarias)
|
||||
|
||||
## Comandos Rápidos
|
||||
|
||||
```bash
|
||||
# Ejecutar todas las pruebas E2E
|
||||
npx playwright test
|
||||
|
||||
# Ejecutar archivo de prueba específico
|
||||
npx playwright test tests/e2e/markets/search.spec.ts
|
||||
|
||||
# Ejecutar en modo headed (ver el navegador)
|
||||
npx playwright test --headed
|
||||
|
||||
# Depurar prueba
|
||||
npx playwright test --debug
|
||||
|
||||
# Generar código de prueba
|
||||
npx playwright codegen http://localhost:3000
|
||||
|
||||
# Ver reporte
|
||||
npx playwright show-report
|
||||
```
|
||||
|
||||
## Agentes Relacionados
|
||||
|
||||
Este comando invoca al agente `e2e-runner` proporcionado por ECC.
|
||||
|
||||
Para instalaciones manuales, el archivo fuente se encuentra en:
|
||||
`agents/e2e-runner.md`
|
||||
|
||||
## Integración con Otros Comandos
|
||||
|
||||
- Usa `/plan` para identificar los flujos críticos a probar
|
||||
- Usa `/tdd` para pruebas unitarias (más rápidas, más detalladas)
|
||||
- Usa `/e2e` para pruebas de integración y flujos de usuario
|
||||
- Usa `/code-review` para validar la calidad de las pruebas
|
||||
@@ -0,0 +1,120 @@
|
||||
# Comando Eval
|
||||
|
||||
Gestionar el flujo de trabajo de desarrollo orientado a evals.
|
||||
|
||||
## Uso
|
||||
|
||||
`/eval [define|check|report|list] [nombre-feature]`
|
||||
|
||||
## Definir Eval
|
||||
|
||||
`/eval define nombre-feature`
|
||||
|
||||
Crear una nueva definición de eval:
|
||||
|
||||
1. Crear `.claude/evals/nombre-feature.md` con la plantilla:
|
||||
|
||||
```markdown
|
||||
## EVAL: nombre-feature
|
||||
Created: $(date)
|
||||
|
||||
### Capability Evals
|
||||
- [ ] [Descripción de Capability 1]
|
||||
- [ ] [Descripción de Capability 2]
|
||||
|
||||
### Regression Evals
|
||||
- [ ] [El comportamiento existente 1 sigue funcionando]
|
||||
- [ ] [El comportamiento existente 2 sigue funcionando]
|
||||
|
||||
### Success Criteria
|
||||
- pass@3 > 90% para capability evals
|
||||
- pass^3 = 100% para regression evals
|
||||
```
|
||||
|
||||
2. Pedir al usuario que complete los criterios específicos
|
||||
|
||||
## Verificar Eval
|
||||
|
||||
`/eval check nombre-feature`
|
||||
|
||||
Ejecutar los evals para una feature:
|
||||
|
||||
1. Leer la definición de eval desde `.claude/evals/nombre-feature.md`
|
||||
2. Para cada capability eval:
|
||||
- Intentar verificar el criterio
|
||||
- Registrar PASS/FAIL
|
||||
- Guardar el intento en `.claude/evals/nombre-feature.log`
|
||||
3. Para cada regression eval:
|
||||
- Ejecutar las pruebas relevantes
|
||||
- Comparar con la línea base
|
||||
- Registrar PASS/FAIL
|
||||
4. Reportar el estado actual:
|
||||
|
||||
```
|
||||
EVAL CHECK: nombre-feature
|
||||
========================
|
||||
Capability: X/Y pasando
|
||||
Regression: X/Y pasando
|
||||
Estado: EN PROGRESO / LISTO
|
||||
```
|
||||
|
||||
## Reporte de Eval
|
||||
|
||||
`/eval report nombre-feature`
|
||||
|
||||
Generar reporte exhaustivo de eval:
|
||||
|
||||
```
|
||||
EVAL REPORT: nombre-feature
|
||||
=========================
|
||||
Generated: $(date)
|
||||
|
||||
CAPABILITY EVALS
|
||||
----------------
|
||||
[eval-1]: PASS (pass@1)
|
||||
[eval-2]: PASS (pass@2) - requirió reintento
|
||||
[eval-3]: FAIL - ver notas
|
||||
|
||||
REGRESSION EVALS
|
||||
----------------
|
||||
[test-1]: PASS
|
||||
[test-2]: PASS
|
||||
[test-3]: PASS
|
||||
|
||||
METRICS
|
||||
-------
|
||||
Capability pass@1: 67%
|
||||
Capability pass@3: 100%
|
||||
Regression pass^3: 100%
|
||||
|
||||
NOTES
|
||||
-----
|
||||
[Cualquier problema, caso límite u observación]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Listar Evals
|
||||
|
||||
`/eval list`
|
||||
|
||||
Mostrar todas las definiciones de eval:
|
||||
|
||||
```
|
||||
EVAL DEFINITIONS
|
||||
================
|
||||
feature-auth [3/5 pasando] EN PROGRESO
|
||||
feature-search [5/5 pasando] LISTO
|
||||
feature-export [0/4 pasando] NO INICIADO
|
||||
```
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `define <nombre>` - Crear nueva definición de eval
|
||||
- `check <nombre>` - Ejecutar y verificar evals
|
||||
- `report <nombre>` - Generar reporte completo
|
||||
- `list` - Mostrar todos los evals
|
||||
- `clean` - Eliminar logs de evals antiguos (mantiene las últimas 10 ejecuciones)
|
||||
@@ -0,0 +1,178 @@
|
||||
---
|
||||
name: evolve
|
||||
description: Analizar instintos y sugerir o generar estructuras evolucionadas
|
||||
command: true
|
||||
---
|
||||
|
||||
# Comando Evolve
|
||||
|
||||
## Implementación
|
||||
|
||||
Ejecutar la CLI de instintos usando la ruta raíz del plugin:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate]
|
||||
```
|
||||
|
||||
O si `CLAUDE_PLUGIN_ROOT` no está configurado (instalación manual):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate]
|
||||
```
|
||||
|
||||
Analiza los instintos y agrupa los relacionados en estructuras de nivel superior:
|
||||
- **Comandos**: Cuando los instintos describen acciones invocadas por el usuario
|
||||
- **Skills**: Cuando los instintos describen comportamientos activados automáticamente
|
||||
- **Agentes**: Cuando los instintos describen procesos complejos de múltiples pasos
|
||||
|
||||
## Uso
|
||||
|
||||
```
|
||||
/evolve # Analizar todos los instintos y sugerir evoluciones
|
||||
/evolve --generate # También generar archivos bajo evolved/{skills,commands,agents}
|
||||
```
|
||||
|
||||
## Reglas de Evolución
|
||||
|
||||
### → Comando (Invocado por el Usuario)
|
||||
Cuando los instintos describen acciones que un usuario solicitaría explícitamente:
|
||||
- Múltiples instintos sobre "cuando el usuario pide..."
|
||||
- Instintos con disparadores como "cuando se crea un nuevo X"
|
||||
- Instintos que siguen una secuencia repetible
|
||||
|
||||
Ejemplo:
|
||||
- `new-table-step1`: "cuando se añade una tabla de base de datos, crear migración"
|
||||
- `new-table-step2`: "cuando se añade una tabla de base de datos, actualizar schema"
|
||||
- `new-table-step3`: "cuando se añade una tabla de base de datos, regenerar tipos"
|
||||
|
||||
→ Crea: comando **new-table**
|
||||
|
||||
### → Skill (Activada Automáticamente)
|
||||
Cuando los instintos describen comportamientos que deben ocurrir automáticamente:
|
||||
- Disparadores de coincidencia de patrones
|
||||
- Respuestas al manejo de errores
|
||||
- Aplicación de estilo de código
|
||||
|
||||
Ejemplo:
|
||||
- `prefer-functional`: "cuando se escriben funciones, preferir estilo funcional"
|
||||
- `use-immutable`: "cuando se modifica estado, usar patrones inmutables"
|
||||
- `avoid-classes`: "cuando se diseñan módulos, evitar diseño basado en clases"
|
||||
|
||||
→ Crea: skill `functional-patterns`
|
||||
|
||||
### → Agente (Necesita Profundidad/Aislamiento)
|
||||
Cuando los instintos describen procesos complejos de múltiples pasos que se benefician del aislamiento:
|
||||
- Flujos de trabajo de depuración
|
||||
- Secuencias de refactorización
|
||||
- Tareas de investigación
|
||||
|
||||
Ejemplo:
|
||||
- `debug-step1`: "al depurar, primero revisar los logs"
|
||||
- `debug-step2`: "al depurar, aislar el componente que falla"
|
||||
- `debug-step3`: "al depurar, crear una reproducción mínima"
|
||||
- `debug-step4`: "al depurar, verificar la corrección con una prueba"
|
||||
|
||||
→ Crea: agente **debugger**
|
||||
|
||||
## Qué Hacer
|
||||
|
||||
1. Detectar el contexto actual del proyecto
|
||||
2. Leer los instintos del proyecto y globales (el proyecto tiene precedencia en conflictos de ID)
|
||||
3. Agrupar los instintos por patrones de disparador/dominio
|
||||
4. Identificar:
|
||||
- Candidatos a skill (clusters de disparadores con 2+ instintos)
|
||||
- Candidatos a comando (instintos de flujo de trabajo de alta confianza)
|
||||
- Candidatos a agente (clusters más grandes de alta confianza)
|
||||
5. Mostrar candidatos a promoción (proyecto → global) cuando corresponda
|
||||
6. Si se pasa `--generate`, escribir archivos en:
|
||||
- Alcance del proyecto: `~/.claude/homunculus/projects/<project-id>/evolved/`
|
||||
- Respaldo global: `~/.claude/homunculus/evolved/`
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
```
|
||||
============================================================
|
||||
ANÁLISIS EVOLVE - 12 instintos
|
||||
Proyecto: my-app (a1b2c3d4e5f6)
|
||||
Con alcance de proyecto: 8 | Global: 4
|
||||
============================================================
|
||||
|
||||
Instintos de alta confianza (>=80%): 5
|
||||
|
||||
## CANDIDATOS A SKILL
|
||||
1. Cluster: "adding tests"
|
||||
Instintos: 3
|
||||
Confianza promedio: 82%
|
||||
Dominios: testing
|
||||
Alcances: proyecto
|
||||
|
||||
## CANDIDATOS A COMANDO (2)
|
||||
/adding-tests
|
||||
De: test-first-workflow [proyecto]
|
||||
Confianza: 84%
|
||||
|
||||
## CANDIDATOS A AGENTE (1)
|
||||
adding-tests-agent
|
||||
Cubre 3 instintos
|
||||
Confianza promedio: 82%
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
- `--generate`: Generar archivos evolucionados además de la salida de análisis
|
||||
|
||||
## Formato de Archivo Generado
|
||||
|
||||
### Comando
|
||||
```markdown
|
||||
---
|
||||
name: new-table
|
||||
description: Crear una nueva tabla de base de datos con migración, actualización de schema y generación de tipos
|
||||
command: /new-table
|
||||
evolved_from:
|
||||
- new-table-migration
|
||||
- update-schema
|
||||
- regenerate-types
|
||||
---
|
||||
|
||||
# Comando New Table
|
||||
|
||||
[Contenido generado basado en instintos agrupados]
|
||||
|
||||
## Pasos
|
||||
1. ...
|
||||
2. ...
|
||||
```
|
||||
|
||||
### Skill
|
||||
```markdown
|
||||
---
|
||||
name: functional-patterns
|
||||
description: Reforzar patrones de programación funcional
|
||||
evolved_from:
|
||||
- prefer-functional
|
||||
- use-immutable
|
||||
- avoid-classes
|
||||
---
|
||||
|
||||
# Skill de Patrones Funcionales
|
||||
|
||||
[Contenido generado basado en instintos agrupados]
|
||||
```
|
||||
|
||||
### Agente
|
||||
```markdown
|
||||
---
|
||||
name: debugger
|
||||
description: Agente de depuración sistemática
|
||||
model: sonnet
|
||||
evolved_from:
|
||||
- debug-check-logs
|
||||
- debug-isolate
|
||||
- debug-reproduce
|
||||
---
|
||||
|
||||
# Agente Debugger
|
||||
|
||||
[Contenido generado basado en instintos agrupados]
|
||||
```
|
||||
@@ -0,0 +1,166 @@
|
||||
---
|
||||
description: Corregir errores de build de Go, advertencias de go vet y problemas del linter de forma incremental. Invoca al agente go-build-resolver para correcciones mínimas y quirúrgicas.
|
||||
---
|
||||
|
||||
# Go Build y Corrección
|
||||
|
||||
Este comando invoca al agente **go-build-resolver** para corregir incrementalmente errores de build de Go con cambios mínimos.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Ejecutar Diagnósticos**: Ejecutar `go build`, `go vet`, `staticcheck`
|
||||
2. **Parsear Errores**: Agrupar por archivo y ordenar por severidad
|
||||
3. **Corregir Incrementalmente**: Un error a la vez
|
||||
4. **Verificar Cada Corrección**: Re-ejecutar el build después de cada cambio
|
||||
5. **Reportar Resumen**: Mostrar qué se corrigió y qué queda pendiente
|
||||
|
||||
## Cuándo Usar
|
||||
|
||||
Usar `/go-build` cuando:
|
||||
- `go build ./...` falla con errores
|
||||
- `go vet ./...` reporta problemas
|
||||
- `golangci-lint run` muestra advertencias
|
||||
- Las dependencias de módulos están rotas
|
||||
- Después de hacer pull de cambios que rompen el build
|
||||
|
||||
## Comandos de Diagnóstico Ejecutados
|
||||
|
||||
```bash
|
||||
# Verificación de build principal
|
||||
go build ./...
|
||||
|
||||
# Análisis estático
|
||||
go vet ./...
|
||||
|
||||
# Linting extendido (si está disponible)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Problemas de módulos
|
||||
go mod verify
|
||||
go mod tidy -v
|
||||
```
|
||||
|
||||
## Ejemplo de Sesión
|
||||
|
||||
```text
|
||||
Usuario: /go-build
|
||||
|
||||
Agente:
|
||||
# Resolución de Build de Go
|
||||
|
||||
## Diagnósticos Iniciales
|
||||
|
||||
$ go build ./...
|
||||
internal/service/user.go:25:15: undefined: UserRepository
|
||||
internal/handler/api.go:42:9: cannot use x (type string) as type int
|
||||
internal/handler/api.go:58:2: missing return at end of function
|
||||
|
||||
Errores encontrados: 3
|
||||
|
||||
## Corrección 1: Identificador Indefinido
|
||||
|
||||
Archivo: internal/service/user.go:25
|
||||
Error: undefined: UserRepository
|
||||
Causa: Import faltante
|
||||
|
||||
// Import añadido
|
||||
import "project/internal/repository"
|
||||
|
||||
// Cambiado
|
||||
var repo UserRepository
|
||||
// A
|
||||
var repo repository.UserRepository
|
||||
|
||||
$ go build ./...
|
||||
# 2 errores restantes
|
||||
|
||||
## Corrección 2: Incompatibilidad de Tipos
|
||||
|
||||
Archivo: internal/handler/api.go:42
|
||||
Error: cannot use x (type string) as type int
|
||||
|
||||
// Cambiado
|
||||
count := params.Get("count")
|
||||
// A
|
||||
countStr := params.Get("count")
|
||||
count, _ := strconv.Atoi(countStr)
|
||||
|
||||
$ go build ./...
|
||||
# 1 error restante
|
||||
|
||||
## Corrección 3: Return Faltante
|
||||
|
||||
Archivo: internal/handler/api.go:58
|
||||
Error: missing return at end of function
|
||||
|
||||
func GetUser(id string) (*User, error) {
|
||||
if id == "" {
|
||||
return nil, ErrInvalidID
|
||||
}
|
||||
user := findUser(id)
|
||||
// Return añadido
|
||||
return user, nil
|
||||
}
|
||||
|
||||
$ go build ./...
|
||||
# ¡Build exitoso!
|
||||
|
||||
## Verificación Final
|
||||
|
||||
$ go vet ./...
|
||||
# Sin problemas
|
||||
|
||||
$ go test ./...
|
||||
ok project/internal/service 0.015s
|
||||
ok project/internal/handler 0.023s
|
||||
|
||||
## Resumen
|
||||
|
||||
| Métrica | Cantidad |
|
||||
|---------|---------|
|
||||
| Errores de build corregidos | 3 |
|
||||
| Advertencias de vet corregidas | 0 |
|
||||
| Archivos modificados | 2 |
|
||||
| Problemas restantes | 0 |
|
||||
|
||||
Estado del Build: ÉXITO
|
||||
```
|
||||
|
||||
## Errores Comunes Corregidos
|
||||
|
||||
| Error | Corrección Típica |
|
||||
|-------|-----------------|
|
||||
| `undefined: X` | Añadir import o corregir typo |
|
||||
| `cannot use X as Y` | Conversión de tipo o corregir asignación |
|
||||
| `missing return` | Añadir sentencia return |
|
||||
| `X does not implement Y` | Añadir método faltante |
|
||||
| `import cycle` | Reestructurar paquetes |
|
||||
| `declared but not used` | Eliminar o usar la variable |
|
||||
| `cannot find package` | `go get` o `go mod tidy` |
|
||||
|
||||
## Estrategia de Corrección
|
||||
|
||||
1. **Errores de build primero** - El código debe compilar
|
||||
2. **Advertencias de vet segundo** - Corregir construcciones sospechosas
|
||||
3. **Advertencias del linter tercero** - Estilo y mejores prácticas
|
||||
4. **Una corrección a la vez** - Verificar cada cambio
|
||||
5. **Cambios mínimos** - No refactorizar, solo corregir
|
||||
|
||||
## Condiciones de Parada
|
||||
|
||||
El agente se detendrá e informará si:
|
||||
- El mismo error persiste después de 3 intentos
|
||||
- La corrección introduce más errores
|
||||
- Requiere cambios arquitectónicos
|
||||
- Faltan dependencias externas
|
||||
|
||||
## Comandos Relacionados
|
||||
|
||||
- `/go-test` - Ejecutar pruebas después de que el build tenga éxito
|
||||
- `/go-review` - Revisar la calidad del código
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Agente: `agents/go-build-resolver.md`
|
||||
- Skill: `skills/golang-patterns/`
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
description: Revisión de código Go completa para patrones idiomáticos, seguridad de concurrencia, manejo de errores y seguridad. Invoca al agente go-reviewer.
|
||||
---
|
||||
|
||||
# Revisión de Código Go
|
||||
|
||||
Este comando invoca al agente **go-reviewer** para una revisión de código Go completa y específica.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Identificar Cambios de Go**: Encontrar archivos `.go` modificados mediante `git diff`
|
||||
2. **Ejecutar Análisis Estático**: Ejecutar `go vet`, `staticcheck` y `golangci-lint`
|
||||
3. **Escaneo de Seguridad**: Verificar inyección SQL, inyección de comandos, condiciones de carrera
|
||||
4. **Revisión de Concurrencia**: Analizar seguridad de goroutines, uso de canales, patrones de mutex
|
||||
5. **Verificación de Go Idiomático**: Verificar que el código sigue las convenciones y mejores prácticas de Go
|
||||
6. **Generar Reporte**: Categorizar problemas por severidad
|
||||
|
||||
## Cuándo Usar
|
||||
|
||||
Usar `/go-review` cuando:
|
||||
- Después de escribir o modificar código Go
|
||||
- Antes de hacer commit de cambios de Go
|
||||
- Al revisar pull requests con código Go
|
||||
- Al incorporarse a una nueva base de código de Go
|
||||
- Al aprender patrones idiomáticos de Go
|
||||
|
||||
## Categorías de Revisión
|
||||
|
||||
### CRÍTICO (Debe Corregirse)
|
||||
- Vulnerabilidades de inyección SQL/comandos
|
||||
- Condiciones de carrera sin sincronización
|
||||
- Fugas de goroutines
|
||||
- Credenciales hardcodeadas
|
||||
- Uso de punteros inseguros
|
||||
- Errores ignorados en rutas críticas
|
||||
|
||||
### ALTO (Debería Corregirse)
|
||||
- Manejo de errores sin context
|
||||
- Panic en lugar de retorno de errores
|
||||
- Context no propagado
|
||||
- Canales sin buffer causando deadlocks
|
||||
- Errores de interfaz no satisfecha
|
||||
- Protección de mutex faltante
|
||||
|
||||
### MEDIO (Considerar)
|
||||
- Patrones de código no idiomáticos
|
||||
- Comentarios godoc faltantes en exports
|
||||
- Concatenación de strings ineficiente
|
||||
- Slice no preasignado
|
||||
- Pruebas table-driven no usadas
|
||||
|
||||
## Verificaciones Automáticas Ejecutadas
|
||||
|
||||
```bash
|
||||
# Análisis estático
|
||||
go vet ./...
|
||||
|
||||
# Verificaciones avanzadas (si están instaladas)
|
||||
staticcheck ./...
|
||||
golangci-lint run
|
||||
|
||||
# Detección de condiciones de carrera
|
||||
go build -race ./...
|
||||
|
||||
# Vulnerabilidades de seguridad
|
||||
govulncheck ./...
|
||||
```
|
||||
|
||||
## Ejemplo de Uso
|
||||
|
||||
```text
|
||||
Usuario: /go-review
|
||||
|
||||
Agente:
|
||||
# Reporte de Revisión de Código Go
|
||||
|
||||
## Archivos Revisados
|
||||
- internal/handler/user.go (modificado)
|
||||
- internal/service/auth.go (modificado)
|
||||
|
||||
## Resultados del Análisis Estático
|
||||
✓ go vet: Sin problemas
|
||||
✓ staticcheck: Sin problemas
|
||||
|
||||
## Problemas Encontrados
|
||||
|
||||
[CRÍTICO] Condición de Carrera
|
||||
Archivo: internal/service/auth.go:45
|
||||
Problema: Mapa compartido accedido sin sincronización
|
||||
Fix: Usar sync.RWMutex o sync.Map
|
||||
|
||||
[ALTO] Context de Error Faltante
|
||||
Archivo: internal/handler/user.go:28
|
||||
Problema: Error retornado sin context
|
||||
Fix: Envolver con context
|
||||
return fmt.Errorf("get user %s: %w", userID, err)
|
||||
|
||||
## Resumen
|
||||
- CRÍTICO: 1
|
||||
- ALTO: 1
|
||||
- MEDIO: 0
|
||||
|
||||
Recomendación: FALLAR: Bloquear merge hasta que se corrija el problema CRÍTICO
|
||||
```
|
||||
|
||||
## Criterios de Aprobación
|
||||
|
||||
| Estado | Condición |
|
||||
|--------|-----------|
|
||||
| PASAR: Aprobar | Sin problemas CRÍTICOS o ALTOS |
|
||||
| ADVERTENCIA | Solo problemas MEDIOS (fusionar con precaución) |
|
||||
| FALLAR: Bloquear | Problemas CRÍTICOS o ALTOS encontrados |
|
||||
|
||||
## Integración con Otros Comandos
|
||||
|
||||
- Usar `/go-test` primero para asegurarse de que las pruebas pasen
|
||||
- Usar `/go-build` si ocurren errores de build
|
||||
- Usar `/go-review` antes de hacer commit
|
||||
- Usar `/code-review` para preocupaciones no específicas de Go
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Agente: `agents/go-reviewer.md`
|
||||
- Skills: `skills/golang-patterns/`, `skills/golang-testing/`
|
||||
@@ -0,0 +1,191 @@
|
||||
---
|
||||
description: Reforzar el flujo de trabajo TDD para Go. Escribir pruebas table-driven primero, luego implementar. Verificar 80%+ de cobertura con go test -cover.
|
||||
---
|
||||
|
||||
# Comando TDD de Go
|
||||
|
||||
Este comando refuerza la metodología de desarrollo guiado por pruebas para código Go usando patrones de testing idiomáticos de Go.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Definir Tipos/Interfaces**: Hacer scaffold de las firmas de funciones primero
|
||||
2. **Escribir Pruebas Table-Driven**: Crear casos de prueba exhaustivos (ROJO)
|
||||
3. **Ejecutar Pruebas**: Verificar que las pruebas fallan por la razón correcta
|
||||
4. **Implementar Código**: Escribir el código mínimo para que pasen (VERDE)
|
||||
5. **Refactorizar**: Mejorar mientras se mantienen las pruebas en verde
|
||||
6. **Verificar Cobertura**: Asegurar 80%+ de cobertura
|
||||
|
||||
## Cuándo Usar
|
||||
|
||||
Usar `/go-test` cuando:
|
||||
- Se implementan nuevas funciones de Go
|
||||
- Se añade cobertura de pruebas a código existente
|
||||
- Se corrigen bugs (escribir primero la prueba que falla)
|
||||
- Se construye lógica de negocio crítica
|
||||
- Se aprende el flujo de trabajo TDD en Go
|
||||
|
||||
## Ciclo TDD
|
||||
|
||||
```
|
||||
ROJO → Escribir prueba table-driven que falla
|
||||
VERDE → Implementar código mínimo para que pase
|
||||
REFACTOR → Mejorar código, las pruebas se mantienen en verde
|
||||
REPETIR → Siguiente caso de prueba
|
||||
```
|
||||
|
||||
## Ejemplo de Sesión
|
||||
|
||||
```
|
||||
Usuario: /go-test Necesito una función para validar direcciones de email
|
||||
|
||||
Agente:
|
||||
# Sesión TDD: Validador de Email
|
||||
|
||||
## Paso 1: Definir Interfaz
|
||||
|
||||
// validator/email.go
|
||||
package validator
|
||||
|
||||
// ValidateEmail verifica si el string dado es una dirección de email válida.
|
||||
// Retorna nil si es válido, error describiendo el problema de lo contrario.
|
||||
func ValidateEmail(email string) error {
|
||||
panic("not implemented")
|
||||
}
|
||||
|
||||
## Paso 2: Escribir Pruebas Table-Driven (ROJO)
|
||||
|
||||
// validator/email_test.go
|
||||
func TestValidateEmail(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
email string
|
||||
wantErr bool
|
||||
}{
|
||||
// Emails válidos
|
||||
{"email simple", "user@example.com", false},
|
||||
{"con subdominio", "user@mail.example.com", false},
|
||||
// Emails inválidos
|
||||
{"string vacío", "", true},
|
||||
{"sin arroba", "userexample.com", true},
|
||||
{"sin dominio", "user@", true},
|
||||
}
|
||||
// ...
|
||||
}
|
||||
|
||||
## Paso 3: Ejecutar Pruebas - Verificar FALLO
|
||||
|
||||
$ go test ./validator/...
|
||||
FAIL (panic: not implemented)
|
||||
✓ Las pruebas fallan como se esperaba.
|
||||
|
||||
## Paso 4: Implementar Código Mínimo (VERDE)
|
||||
|
||||
var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
|
||||
|
||||
func ValidateEmail(email string) error {
|
||||
if email == "" {
|
||||
return ErrEmailEmpty
|
||||
}
|
||||
if !emailRegex.MatchString(email) {
|
||||
return ErrEmailInvalid
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
## Paso 5: Ejecutar Pruebas - Verificar PASAN
|
||||
|
||||
$ go test ./validator/...
|
||||
PASS ✓ Todas las pruebas pasando!
|
||||
|
||||
## Paso 6: Verificar Cobertura
|
||||
|
||||
$ go test -cover ./validator/...
|
||||
coverage: 100.0% of statements
|
||||
```
|
||||
|
||||
## Patrones de Prueba
|
||||
|
||||
### Pruebas Table-Driven
|
||||
```go
|
||||
tests := []struct {
|
||||
name string
|
||||
input InputType
|
||||
want OutputType
|
||||
wantErr bool
|
||||
}{
|
||||
{"caso 1", input1, want1, false},
|
||||
{"caso 2", input2, want2, true},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := Function(tt.input)
|
||||
// afirmaciones
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Pruebas en Paralelo
|
||||
```go
|
||||
for _, tt := range tests {
|
||||
tt := tt // Capturar
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
t.Parallel()
|
||||
// cuerpo de prueba
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
## Comandos de Cobertura
|
||||
|
||||
```bash
|
||||
# Cobertura básica
|
||||
go test -cover ./...
|
||||
|
||||
# Perfil de cobertura
|
||||
go test -coverprofile=coverage.out ./...
|
||||
|
||||
# Ver en navegador
|
||||
go tool cover -html=coverage.out
|
||||
|
||||
# Cobertura por función
|
||||
go tool cover -func=coverage.out
|
||||
|
||||
# Con detección de condiciones de carrera
|
||||
go test -race -cover ./...
|
||||
```
|
||||
|
||||
## Objetivos de Cobertura
|
||||
|
||||
| Tipo de Código | Objetivo |
|
||||
|----------------|---------|
|
||||
| Lógica de negocio crítica | 100% |
|
||||
| APIs públicas | 90%+ |
|
||||
| Código general | 80%+ |
|
||||
| Código generado | Excluir |
|
||||
|
||||
## Mejores Prácticas de TDD
|
||||
|
||||
**HACER:**
|
||||
- Escribir la prueba PRIMERO, antes de cualquier implementación
|
||||
- Ejecutar las pruebas después de cada cambio
|
||||
- Usar pruebas table-driven para cobertura exhaustiva
|
||||
- Probar el comportamiento, no los detalles de implementación
|
||||
- Incluir casos límite (vacío, nil, valores máximos)
|
||||
|
||||
**NO HACER:**
|
||||
- Escribir implementación antes que las pruebas
|
||||
- Saltar la fase ROJO
|
||||
- Probar funciones privadas directamente
|
||||
- Usar `time.Sleep` en las pruebas
|
||||
- Ignorar las pruebas inestables
|
||||
|
||||
## Comandos Relacionados
|
||||
|
||||
- `/go-build` - Corregir errores de build
|
||||
- `/go-review` - Revisar código después de la implementación
|
||||
|
||||
## Relacionado
|
||||
|
||||
- Skill: `skills/golang-testing/`
|
||||
- Skill: `skills/tdd-workflow/`
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
name: instinct-export
|
||||
description: Exportar instintos del alcance del proyecto/global a un archivo
|
||||
command: /instinct-export
|
||||
---
|
||||
|
||||
# Comando Instinct Export
|
||||
|
||||
Exporta los instintos a un formato compartible. Perfecto para:
|
||||
- Compartir con compañeros de equipo
|
||||
- Transferir a una nueva máquina
|
||||
- Contribuir a las convenciones del proyecto
|
||||
|
||||
## Uso
|
||||
|
||||
```
|
||||
/instinct-export # Exportar todos los instintos personales
|
||||
/instinct-export --domain testing # Exportar solo instintos de testing
|
||||
/instinct-export --min-confidence 0.7 # Solo exportar instintos de alta confianza
|
||||
/instinct-export --output team-instincts.yaml
|
||||
/instinct-export --scope project --output project-instincts.yaml
|
||||
```
|
||||
|
||||
## Qué Hacer
|
||||
|
||||
1. Detectar el contexto actual del proyecto
|
||||
2. Cargar instintos por alcance seleccionado:
|
||||
- `project`: solo el proyecto actual
|
||||
- `global`: solo global
|
||||
- `all`: proyecto + global fusionados (por defecto)
|
||||
3. Aplicar filtros (`--domain`, `--min-confidence`)
|
||||
4. Escribir la exportación en formato YAML al archivo (o stdout si no se proporciona ruta de salida)
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
Crea un archivo YAML:
|
||||
|
||||
```yaml
|
||||
# Exportación de Instintos
|
||||
# Generado: 2025-01-22
|
||||
# Fuente: personal
|
||||
# Cantidad: 12 instintos
|
||||
|
||||
---
|
||||
id: prefer-functional-style
|
||||
trigger: "when writing new functions"
|
||||
confidence: 0.8
|
||||
domain: code-style
|
||||
source: session-observation
|
||||
scope: project
|
||||
project_id: a1b2c3d4e5f6
|
||||
project_name: my-app
|
||||
---
|
||||
|
||||
# Preferir Estilo Funcional
|
||||
|
||||
## Acción
|
||||
Usar patrones funcionales sobre clases.
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
- `--domain <nombre>`: Exportar solo el dominio especificado
|
||||
- `--min-confidence <n>`: Umbral mínimo de confianza
|
||||
- `--output <archivo>`: Ruta del archivo de salida (imprime a stdout si se omite)
|
||||
- `--scope <project|global|all>`: Alcance de exportación (por defecto: `all`)
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: instinct-import
|
||||
description: Importar instintos desde archivo o URL al alcance del proyecto/global
|
||||
command: true
|
||||
---
|
||||
|
||||
# Comando Instinct Import
|
||||
|
||||
## Implementación
|
||||
|
||||
Ejecutar la CLI de instintos usando la ruta raíz del plugin:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <archivo-o-url> [--dry-run] [--force] [--min-confidence 0.7] [--scope project|global]
|
||||
```
|
||||
|
||||
O si `CLAUDE_PLUGIN_ROOT` no está configurado (instalación manual):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <archivo-o-url>
|
||||
```
|
||||
|
||||
Importar instintos desde rutas de archivos locales o URLs HTTP(S).
|
||||
|
||||
## Uso
|
||||
|
||||
```
|
||||
/instinct-import team-instincts.yaml
|
||||
/instinct-import https://github.com/org/repo/instincts.yaml
|
||||
/instinct-import team-instincts.yaml --dry-run
|
||||
/instinct-import team-instincts.yaml --scope global --force
|
||||
```
|
||||
|
||||
## Qué Hacer
|
||||
|
||||
1. Obtener el archivo de instintos (ruta local o URL)
|
||||
2. Parsear y validar el formato
|
||||
3. Verificar duplicados con instintos existentes
|
||||
4. Fusionar o añadir nuevos instintos
|
||||
5. Guardar en el directorio de instintos heredados:
|
||||
- Alcance de proyecto: `~/.claude/homunculus/projects/<project-id>/instincts/inherited/`
|
||||
- Alcance global: `~/.claude/homunculus/instincts/inherited/`
|
||||
|
||||
## Proceso de Importación
|
||||
|
||||
```
|
||||
Importando instintos desde: team-instincts.yaml
|
||||
================================================
|
||||
|
||||
12 instintos encontrados para importar.
|
||||
|
||||
Analizando conflictos...
|
||||
|
||||
## Nuevos Instintos (8)
|
||||
Estos se añadirán:
|
||||
✓ use-zod-validation (confianza: 0.7)
|
||||
✓ prefer-named-exports (confianza: 0.65)
|
||||
✓ test-async-functions (confianza: 0.8)
|
||||
...
|
||||
|
||||
## Instintos Duplicados (3)
|
||||
Ya existen instintos similares:
|
||||
ADVERTENCIA: prefer-functional-style
|
||||
Local: confianza 0.8, 12 observaciones
|
||||
Importado: confianza 0.7
|
||||
→ Conservar local (mayor confianza)
|
||||
|
||||
ADVERTENCIA: test-first-workflow
|
||||
Local: confianza 0.75
|
||||
Importado: confianza 0.9
|
||||
→ Actualizar al importado (mayor confianza)
|
||||
|
||||
¿Importar 8 nuevos, actualizar 1?
|
||||
```
|
||||
|
||||
## Comportamiento de Fusión
|
||||
|
||||
Al importar un instinto con un ID existente:
|
||||
- El importado con mayor confianza se convierte en candidato de actualización
|
||||
- El importado con igual/menor confianza se omite
|
||||
- El usuario confirma a menos que se use `--force`
|
||||
|
||||
## Seguimiento de Fuente
|
||||
|
||||
Los instintos importados se marcan con:
|
||||
```yaml
|
||||
source: inherited
|
||||
scope: project
|
||||
imported_from: "team-instincts.yaml"
|
||||
project_id: "a1b2c3d4e5f6"
|
||||
project_name: "my-project"
|
||||
```
|
||||
|
||||
## Flags
|
||||
|
||||
- `--dry-run`: Vista previa sin importar
|
||||
- `--force`: Omitir el prompt de confirmación
|
||||
- `--min-confidence <n>`: Solo importar instintos por encima del umbral
|
||||
- `--scope <project|global>`: Seleccionar el alcance destino (por defecto: `project`)
|
||||
|
||||
## Salida
|
||||
|
||||
Después de la importación:
|
||||
```
|
||||
¡Importación completada!
|
||||
|
||||
Añadidos: 8 instintos
|
||||
Actualizados: 1 instinto
|
||||
Omitidos: 3 instintos (ya existe igual/mayor confianza)
|
||||
|
||||
Nuevos instintos guardados en: ~/.claude/homunculus/instincts/inherited/
|
||||
|
||||
Ejecutar /instinct-status para ver todos los instintos.
|
||||
```
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: instinct-status
|
||||
description: Mostrar los instintos aprendidos (proyecto + global) con confianza
|
||||
command: true
|
||||
---
|
||||
|
||||
# Comando Instinct Status
|
||||
|
||||
Muestra los instintos aprendidos para el proyecto actual más los instintos globales, agrupados por dominio.
|
||||
|
||||
## Implementación
|
||||
|
||||
Ejecutar la CLI de instintos usando la ruta raíz del plugin:
|
||||
|
||||
```bash
|
||||
python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" status
|
||||
```
|
||||
|
||||
O si `CLAUDE_PLUGIN_ROOT` no está configurado (instalación manual):
|
||||
|
||||
```bash
|
||||
python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
|
||||
```
|
||||
|
||||
## Uso
|
||||
|
||||
```
|
||||
/instinct-status
|
||||
```
|
||||
|
||||
## Qué Hacer
|
||||
|
||||
1. Detectar el contexto actual del proyecto (hash de remote/ruta de git)
|
||||
2. Leer instintos del proyecto desde `~/.claude/homunculus/projects/<project-id>/instincts/`
|
||||
3. Leer instintos globales desde `~/.claude/homunculus/instincts/`
|
||||
4. Fusionar con reglas de precedencia (el proyecto sobreescribe global cuando hay colisión de IDs)
|
||||
5. Mostrar agrupados por dominio con barras de confianza y estadísticas de observación
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
```
|
||||
============================================================
|
||||
ESTADO DE INSTINTOS - 12 en total
|
||||
============================================================
|
||||
|
||||
Proyecto: my-app (a1b2c3d4e5f6)
|
||||
Instintos del proyecto: 8
|
||||
Instintos globales: 4
|
||||
|
||||
## CON ALCANCE DE PROYECTO (my-app)
|
||||
### WORKFLOW (3)
|
||||
███████░░░ 70% grep-before-edit [proyecto]
|
||||
disparador: when modifying code
|
||||
|
||||
## GLOBAL (aplican a todos los proyectos)
|
||||
### SECURITY (2)
|
||||
█████████░ 85% validate-user-input [global]
|
||||
disparador: when handling user input
|
||||
```
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
description: "Extraer patrones reutilizables de la sesión, autoevaluar la calidad antes de guardar y determinar la ubicación correcta (Global vs. Proyecto)."
|
||||
---
|
||||
|
||||
# /learn-eval - Extraer, Evaluar y luego Guardar
|
||||
|
||||
Extiende `/learn` con una puerta de calidad, decisión de ubicación de guardado y conciencia de colocación del conocimiento antes de escribir cualquier archivo de skill.
|
||||
|
||||
## Qué Extraer
|
||||
|
||||
Buscar:
|
||||
|
||||
1. **Patrones de Resolución de Errores** — causa raíz + corrección + reutilizabilidad
|
||||
2. **Técnicas de Depuración** — pasos no obvios, combinaciones de herramientas
|
||||
3. **Soluciones Alternativas** — peculiaridades de librerías, limitaciones de API, correcciones específicas de versión
|
||||
4. **Patrones Específicos del Proyecto** — convenciones, decisiones arquitectónicas, patrones de integración
|
||||
|
||||
## Proceso
|
||||
|
||||
1. Revisar la sesión en busca de patrones extraíbles
|
||||
2. Identificar el insight más valioso/reutilizable
|
||||
|
||||
3. **Determinar la ubicación de guardado:**
|
||||
- Preguntar: "¿Este patrón sería útil en un proyecto diferente?"
|
||||
- **Global** (`~/.claude/skills/learned/`): Patrones genéricos usables en 2+ proyectos (compatibilidad bash, comportamiento de API LLM, técnicas de depuración, etc.)
|
||||
- **Proyecto** (`.claude/skills/learned/` en el proyecto actual): Conocimiento específico del proyecto (peculiaridades de un archivo de configuración particular, decisiones de arquitectura específicas del proyecto, etc.)
|
||||
- Ante la duda, elegir Global (mover Global → Proyecto es más fácil que al revés)
|
||||
|
||||
4. Redactar el archivo de skill usando este formato:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: nombre-del-patron
|
||||
description: "Menos de 130 caracteres"
|
||||
user-invocable: false
|
||||
origin: auto-extracted
|
||||
---
|
||||
|
||||
# [Nombre Descriptivo del Patrón]
|
||||
|
||||
**Extraído:** [Fecha]
|
||||
**Contexto:** [Breve descripción de cuándo aplica]
|
||||
|
||||
## Problema
|
||||
[Qué problema resuelve - ser específico]
|
||||
|
||||
## Solución
|
||||
[El patrón/técnica/solución alternativa - con ejemplos de código]
|
||||
|
||||
## Cuándo Usar
|
||||
[Condiciones de activación]
|
||||
```
|
||||
|
||||
5. **Puerta de calidad — Lista de verificación + Veredicto holístico**
|
||||
|
||||
### 5a. Lista de verificación requerida (verificar leyendo los archivos reales)
|
||||
|
||||
Ejecutar **todos** los siguientes antes de evaluar el borrador:
|
||||
|
||||
- [ ] Hacer grep en `~/.claude/skills/` y archivos relevantes de `.claude/skills/` del proyecto por palabras clave para verificar superposición de contenido
|
||||
- [ ] Verificar MEMORY.md (tanto del proyecto como global) para superposición
|
||||
- [ ] Considerar si añadir a una skill existente sería suficiente
|
||||
- [ ] Confirmar que este es un patrón reutilizable, no una corrección puntual
|
||||
|
||||
### 5b. Veredicto holístico
|
||||
|
||||
Sintetizar los resultados de la lista de verificación y la calidad del borrador, luego elegir **uno** de los siguientes:
|
||||
|
||||
| Veredicto | Significado | Próxima Acción |
|
||||
|-----------|-------------|---------------|
|
||||
| **Guardar** | Único, específico, bien delimitado | Proceder al Paso 6 |
|
||||
| **Mejorar y luego Guardar** | Valioso pero necesita refinamiento | Listar mejoras → revisar → re-evaluar (una vez) |
|
||||
| **Absorber en [X]** | Debe añadirse a una skill existente | Mostrar skill objetivo y adiciones → Paso 6 |
|
||||
| **Descartar** | Trivial, redundante o demasiado abstracto | Explicar razonamiento y parar |
|
||||
|
||||
**Dimensiones de guía** (informando el veredicto, no puntuadas):
|
||||
|
||||
- **Especificidad y Accionabilidad**: Contiene ejemplos de código o comandos que son utilizables inmediatamente
|
||||
- **Ajuste de Alcance**: El nombre, las condiciones de activación y el contenido están alineados y enfocados en un solo patrón
|
||||
- **Unicidad**: Proporciona valor no cubierto por skills existentes (informado por los resultados de la lista de verificación)
|
||||
- **Reutilizabilidad**: Existen escenarios de activación realistas en sesiones futuras
|
||||
|
||||
6. **Flujo de confirmación específico por veredicto**
|
||||
|
||||
- **Mejorar y luego Guardar**: Presentar las mejoras requeridas + borrador revisado + lista de verificación/veredicto actualizado después de una re-evaluación; si el veredicto revisado es **Guardar**, guardar después de confirmación del usuario, de lo contrario seguir el nuevo veredicto
|
||||
- **Guardar**: Presentar ruta de guardado + resultados de lista de verificación + razón de veredicto de 1 línea + borrador completo → guardar después de confirmación del usuario
|
||||
- **Absorber en [X]**: Presentar ruta objetivo + adiciones (formato diff) + resultados de lista de verificación + razón del veredicto → añadir después de confirmación del usuario
|
||||
- **Descartar**: Mostrar solo resultados de lista de verificación + razonamiento (sin necesidad de confirmación)
|
||||
|
||||
7. Guardar / Absorber en la ubicación determinada
|
||||
|
||||
## Formato de Salida para el Paso 5
|
||||
|
||||
```
|
||||
### Lista de Verificación
|
||||
- [x] grep de skills/: sin superposición (o: superposición encontrada → detalles)
|
||||
- [x] MEMORY.md: sin superposición (o: superposición encontrada → detalles)
|
||||
- [x] Añadir a skill existente: nuevo archivo apropiado (o: debería añadirse a [X])
|
||||
- [x] Reutilizabilidad: confirmada (o: caso único → Descartar)
|
||||
|
||||
### Veredicto: Guardar / Mejorar y luego Guardar / Absorber en [X] / Descartar
|
||||
|
||||
**Razonamiento:** (1-2 oraciones explicando el veredicto)
|
||||
```
|
||||
|
||||
## Notas
|
||||
|
||||
- No extraer correcciones triviales (typos, errores de sintaxis simples)
|
||||
- No extraer problemas puntuales (interrupciones específicas de API, etc.)
|
||||
- Enfocarse en patrones que ahorrarán tiempo en sesiones futuras
|
||||
- Mantener las skills enfocadas — un patrón por skill
|
||||
- Cuando el veredicto es Absorber, añadir a la skill existente en lugar de crear un archivo nuevo
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
description: Extraer patrones reutilizables de la sesión actual y guardarlos como skills candidatas o guía.
|
||||
---
|
||||
|
||||
# /learn - Extraer Patrones Reutilizables
|
||||
|
||||
Analizar la sesión actual y extraer cualquier patrón que valga la pena guardar como skills.
|
||||
|
||||
## Activador
|
||||
|
||||
Ejecutar `/learn` en cualquier momento durante una sesión cuando se haya resuelto un problema no trivial.
|
||||
|
||||
## Qué Extraer
|
||||
|
||||
Buscar:
|
||||
|
||||
1. **Patrones de Resolución de Errores**
|
||||
- ¿Qué error ocurrió?
|
||||
- ¿Cuál fue la causa raíz?
|
||||
- ¿Qué lo solucionó?
|
||||
- ¿Es reutilizable para errores similares?
|
||||
|
||||
2. **Técnicas de Depuración**
|
||||
- Pasos de depuración no obvios
|
||||
- Combinaciones de herramientas que funcionaron
|
||||
- Patrones de diagnóstico
|
||||
|
||||
3. **Soluciones Alternativas**
|
||||
- Peculiaridades de librerías
|
||||
- Limitaciones de API
|
||||
- Correcciones específicas de versión
|
||||
|
||||
4. **Patrones Específicos del Proyecto**
|
||||
- Convenciones de la base de código descubiertas
|
||||
- Decisiones arquitectónicas tomadas
|
||||
- Patrones de integración
|
||||
|
||||
## Formato de Salida
|
||||
|
||||
Crear un archivo de skill en `~/.claude/skills/learned/[nombre-del-patron].md`:
|
||||
|
||||
```markdown
|
||||
# [Nombre Descriptivo del Patrón]
|
||||
|
||||
**Extraído:** [Fecha]
|
||||
**Contexto:** [Breve descripción de cuándo aplica]
|
||||
|
||||
## Problema
|
||||
[Qué problema resuelve - ser específico]
|
||||
|
||||
## Solución
|
||||
[El patrón/técnica/solución alternativa]
|
||||
|
||||
## Ejemplo
|
||||
[Ejemplo de código si aplica]
|
||||
|
||||
## Cuándo Usar
|
||||
[Condiciones de activación - qué debe activar esta skill]
|
||||
```
|
||||
|
||||
## Proceso
|
||||
|
||||
1. Revisar la sesión en busca de patrones extraíbles
|
||||
2. Identificar el insight más valioso/reutilizable
|
||||
3. Redactar el archivo de skill
|
||||
4. Pedir al usuario que confirme antes de guardar
|
||||
5. Guardar en `~/.claude/skills/learned/`
|
||||
|
||||
## Notas
|
||||
|
||||
- No extraer correcciones triviales (typos, errores de sintaxis simples)
|
||||
- No extraer problemas puntuales (interrupciones específicas de API, etc.)
|
||||
- Enfocarse en patrones que ahorrarán tiempo en sesiones futuras
|
||||
- Mantener las skills enfocadas - un patrón por skill
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
description: Ejecutar un flujo de trabajo multi-modelo enfocado en backend para APIs, algoritmos, datos y lógica de negocio.
|
||||
---
|
||||
|
||||
# Backend - Desarrollo Enfocado en Backend
|
||||
|
||||
Flujo de trabajo enfocado en backend (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión), liderado por Codex.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
/backend <descripción de tarea backend>
|
||||
```
|
||||
|
||||
## Contexto
|
||||
|
||||
- Tarea backend: $ARGUMENTS
|
||||
- Liderado por Codex, Gemini para referencia auxiliar
|
||||
- Aplicable a: diseño de API, implementación de algoritmos, optimización de base de datos, lógica de negocio
|
||||
|
||||
## Tu Rol
|
||||
|
||||
Eres el **Orquestador Backend**, coordinando la colaboración multi-modelo para tareas del lado del servidor (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión).
|
||||
|
||||
**Modelos Colaboradores**:
|
||||
- **Codex** – Lógica backend, algoritmos (**Autoridad de backend, confiable**)
|
||||
- **Gemini** – Perspectiva frontend (**Opiniones de backend solo como referencia**)
|
||||
- **Claude (propio)** – Orquestación, planificación, ejecución, entrega
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Trabajo Principal
|
||||
|
||||
### Fase 0: Mejora del Prompt (Opcional)
|
||||
|
||||
`[Modo: Preparar]` - Si el MCP ace-tool está disponible, llamar a `mcp__ace-tool__enhance_prompt`. Si no está disponible, usar `$ARGUMENTS` tal cual.
|
||||
|
||||
### Fase 1: Investigación
|
||||
|
||||
`[Modo: Investigación]` - Entender los requisitos y recopilar contexto
|
||||
|
||||
1. **Recuperación de Código** (si el MCP ace-tool está disponible): Llamar a `mcp__ace-tool__search_context`. Si no está disponible, usar herramientas integradas: `Glob` para descubrir archivos, `Grep` para buscar símbolos/APIs, `Read` para recopilar contexto.
|
||||
2. Puntuación de completitud de requisitos (0-10): >=7 continuar, <7 parar y complementar
|
||||
|
||||
### Fase 2: Ideación
|
||||
|
||||
`[Modo: Ideación]` - Análisis liderado por Codex
|
||||
|
||||
**DEBE llamar a Codex**:
|
||||
- Análisis de viabilidad técnica, soluciones recomendadas (al menos 2), evaluación de riesgos
|
||||
|
||||
**Guardar SESSION_ID** (`CODEX_SESSION`) para reutilización en fases posteriores.
|
||||
|
||||
Presentar soluciones (al menos 2), esperar selección del usuario.
|
||||
|
||||
### Fase 3: Planificación
|
||||
|
||||
`[Modo: Plan]` - Planificación liderada por Codex
|
||||
|
||||
**DEBE llamar a Codex** (usar `resume <CODEX_SESSION>`):
|
||||
- Estructura de archivos, diseño de funciones/clases, relaciones de dependencia
|
||||
|
||||
Claude sintetiza el plan, guardar en `.claude/plan/nombre-tarea.md` después de aprobación del usuario.
|
||||
|
||||
### Fase 4: Implementación
|
||||
|
||||
`[Modo: Ejecutar]` - Desarrollo de código
|
||||
|
||||
- Seguir estrictamente el plan aprobado
|
||||
- Seguir los estándares de código existentes del proyecto
|
||||
- Asegurar manejo de errores, seguridad, optimización de rendimiento
|
||||
|
||||
### Fase 5: Optimización
|
||||
|
||||
`[Modo: Optimizar]` - Revisión liderada por Codex
|
||||
|
||||
**DEBE llamar a Codex**:
|
||||
- Lista de problemas de seguridad, rendimiento, manejo de errores, cumplimiento de API
|
||||
|
||||
Integrar retroalimentación de la revisión, ejecutar optimización después de confirmación del usuario.
|
||||
|
||||
### Fase 6: Revisión de Calidad
|
||||
|
||||
`[Modo: Revisión]` - Evaluación final
|
||||
|
||||
- Verificar completitud contra el plan
|
||||
- Ejecutar pruebas para verificar la funcionalidad
|
||||
- Reportar problemas y recomendaciones
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. **Las opiniones de backend de Codex son confiables**
|
||||
2. **Las opiniones de backend de Gemini son solo de referencia**
|
||||
3. Los modelos externos tienen **cero acceso de escritura al sistema de archivos**
|
||||
4. Claude maneja todas las escrituras de código y operaciones de archivos
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
description: Ejecutar un plan de implementación multi-modelo preservando a Claude como el único escritor del sistema de archivos.
|
||||
---
|
||||
|
||||
# Execute - Ejecución Colaborativa Multi-Modelo
|
||||
|
||||
Ejecución colaborativa multi-modelo - Obtener prototipo del plan → Claude refactoriza e implementa → Auditoría multi-modelo y entrega.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Protocolos Principales
|
||||
|
||||
- **Soberanía del Código**: Los modelos externos tienen **cero acceso de escritura al sistema de archivos**, todas las modificaciones por Claude
|
||||
- **Refactorización de Prototipo Sucio**: Tratar el Unified Diff de Codex/Gemini como "prototipo sucio", debe refactorizarse a código de calidad de producción
|
||||
- **Mecanismo de Parada**: No proceder a la siguiente fase hasta que la salida de la fase actual esté validada
|
||||
- **Prerrequisito**: Solo ejecutar después de que el usuario responda explícitamente "Y" a la salida de `/ccg:plan`
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Ejecución
|
||||
|
||||
**Tarea a Ejecutar**: $ARGUMENTS
|
||||
|
||||
### Fase 0: Leer Plan
|
||||
|
||||
`[Modo: Preparar]`
|
||||
|
||||
1. **Identificar Tipo de Entrada**:
|
||||
- Ruta de archivo de plan (ej. `.claude/plan/xxx.md`)
|
||||
- Descripción directa de tarea
|
||||
|
||||
2. **Leer Contenido del Plan**:
|
||||
- Si se proporciona ruta de archivo, leer y parsear
|
||||
- Extraer: tipo de tarea, pasos de implementación, archivos clave, SESSION_ID
|
||||
|
||||
3. **Enrutamiento por Tipo de Tarea**:
|
||||
|
||||
| Tipo de Tarea | Detección | Ruta |
|
||||
|---------------|-----------|------|
|
||||
| **Frontend** | Páginas, componentes, UI, estilos | Gemini |
|
||||
| **Backend** | API, interfaces, base de datos, lógica | Codex |
|
||||
| **Fullstack** | Contiene tanto frontend como backend | Codex ∥ Gemini en paralelo |
|
||||
|
||||
---
|
||||
|
||||
### Fase 1: Recuperación Rápida de Contexto
|
||||
|
||||
`[Modo: Recuperación]`
|
||||
|
||||
Basado en la lista de "Archivos Clave" del plan, recuperar el contexto relevante del proyecto.
|
||||
|
||||
---
|
||||
|
||||
### Fase 3: Adquisición de Prototipo
|
||||
|
||||
`[Modo: Prototipo]`
|
||||
|
||||
**Enrutar según el Tipo de Tarea**:
|
||||
|
||||
#### Ruta A: Frontend/UI/Estilos → Gemini
|
||||
|
||||
1. Llamar a Gemini
|
||||
2. Entrada: Contenido del plan + contexto recuperado + archivos objetivo
|
||||
3. **Gemini es la autoridad de diseño frontend, su prototipo CSS/React/Vue es la línea base visual final**
|
||||
|
||||
#### Ruta B: Backend/Lógica/Algoritmos → Codex
|
||||
|
||||
1. Llamar a Codex
|
||||
2. **Codex es la autoridad de lógica backend, aprovechar su razonamiento lógico y capacidades de depuración**
|
||||
|
||||
#### Ruta C: Fullstack → Llamadas en Paralelo
|
||||
|
||||
1. **Llamadas en Paralelo**
|
||||
2. Esperar resultados completos de ambos modelos
|
||||
3. Cada uno usa el `SESSION_ID` correspondiente del plan para `resume`
|
||||
|
||||
---
|
||||
|
||||
### Fase 4: Implementación de Código
|
||||
|
||||
`[Modo: Implementar]`
|
||||
|
||||
**Claude como Soberano del Código ejecuta los siguientes pasos**:
|
||||
|
||||
1. **Leer Diff**: Parsear el Unified Diff Patch retornado por Codex/Gemini
|
||||
2. **Sandbox Mental**: Simular la aplicación del Diff a los archivos objetivo
|
||||
3. **Refactorizar y Limpiar**: Refactorizar el "prototipo sucio" a **código altamente legible, mantenible y de nivel empresarial**
|
||||
4. **Alcance Mínimo**: Cambios limitados solo al alcance del requisito
|
||||
5. **Aplicar Cambios**: Usar herramientas Edit/Write para ejecutar las modificaciones reales
|
||||
|
||||
---
|
||||
|
||||
### Fase 5: Auditoría y Entrega
|
||||
|
||||
`[Modo: Auditoría]`
|
||||
|
||||
**Llamar en paralelo** a Codex y Gemini para revisión de código:
|
||||
|
||||
1. **Revisión de Codex**: Seguridad, rendimiento, manejo de errores, corrección lógica
|
||||
2. **Revisión de Gemini**: Accesibilidad, consistencia de diseño, experiencia de usuario
|
||||
|
||||
Después de que pase la auditoría, reportar al usuario:
|
||||
|
||||
```markdown
|
||||
## Ejecución Completa
|
||||
|
||||
### Resumen de Cambios
|
||||
| Archivo | Operación | Descripción |
|
||||
|---------|-----------|-------------|
|
||||
| ruta/al/archivo.ts | Modificado | Descripción |
|
||||
|
||||
### Resultados de Auditoría
|
||||
- Codex: <Pasó/Encontró N problemas>
|
||||
- Gemini: <Pasó/Encontró N problemas>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. **Soberanía del Código** – Todas las modificaciones de archivos por Claude, los modelos externos tienen cero acceso de escritura
|
||||
2. **Refactorización del Prototipo Sucio** – La salida de Codex/Gemini tratada como borrador, debe refactorizarse
|
||||
3. **Reglas de Confianza** – Backend sigue a Codex, Frontend sigue a Gemini
|
||||
4. **Cambios Mínimos** – Solo modificar el código necesario, sin efectos secundarios
|
||||
5. **Auditoría Obligatoria** – Debe realizar revisión de código multi-modelo después de los cambios
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
description: Ejecutar un flujo de trabajo multi-modelo enfocado en frontend para componentes, layouts, animaciones y pulido de UI.
|
||||
---
|
||||
|
||||
# Frontend - Desarrollo Enfocado en Frontend
|
||||
|
||||
Flujo de trabajo enfocado en frontend (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión), liderado por Gemini.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
/frontend <descripción de tarea de UI>
|
||||
```
|
||||
|
||||
## Contexto
|
||||
|
||||
- Tarea frontend: $ARGUMENTS
|
||||
- Liderado por Gemini, Codex para referencia auxiliar
|
||||
- Aplicable a: diseño de componentes, layout responsivo, animaciones de UI, optimización de estilos
|
||||
|
||||
## Tu Rol
|
||||
|
||||
Eres el **Orquestador Frontend**, coordinando la colaboración multi-modelo para tareas de UI/UX (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión).
|
||||
|
||||
**Modelos Colaboradores**:
|
||||
- **Gemini** – UI/UX frontend (**Autoridad frontend, confiable**)
|
||||
- **Codex** – Perspectiva backend (**Opiniones de frontend solo como referencia**)
|
||||
- **Claude (propio)** – Orquestación, planificación, ejecución, entrega
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Trabajo Principal
|
||||
|
||||
### Fase 0: Mejora del Prompt (Opcional)
|
||||
|
||||
`[Modo: Preparar]` - Si el MCP ace-tool está disponible, llamar a `mcp__ace-tool__enhance_prompt`. Si no está disponible, usar `$ARGUMENTS` tal cual.
|
||||
|
||||
### Fase 1: Investigación
|
||||
|
||||
`[Modo: Investigación]` - Entender los requisitos y recopilar contexto
|
||||
|
||||
1. **Recuperación de Código**: Recuperar componentes existentes, estilos, sistema de diseño.
|
||||
2. Puntuación de completitud de requisitos (0-10): >=7 continuar, <7 parar y complementar
|
||||
|
||||
### Fase 2: Ideación
|
||||
|
||||
`[Modo: Ideación]` - Análisis liderado por Gemini
|
||||
|
||||
**DEBE llamar a Gemini**:
|
||||
- Análisis de viabilidad de UI, soluciones recomendadas (al menos 2), evaluación de UX
|
||||
|
||||
**Guardar SESSION_ID** (`GEMINI_SESSION`) para reutilización en fases posteriores.
|
||||
|
||||
Presentar soluciones (al menos 2), esperar selección del usuario.
|
||||
|
||||
### Fase 3: Planificación
|
||||
|
||||
`[Modo: Plan]` - Planificación liderada por Gemini
|
||||
|
||||
**DEBE llamar a Gemini** (usar `resume <GEMINI_SESSION>`):
|
||||
- Estructura de componentes, flujo de UI, enfoque de estilos
|
||||
|
||||
Claude sintetiza el plan, guardar en `.claude/plan/nombre-tarea.md` después de aprobación del usuario.
|
||||
|
||||
### Fase 4: Implementación
|
||||
|
||||
`[Modo: Ejecutar]` - Desarrollo de código
|
||||
|
||||
- Seguir estrictamente el plan aprobado
|
||||
- Seguir el sistema de diseño y estándares de código existentes del proyecto
|
||||
- Asegurar responsividad, accesibilidad
|
||||
|
||||
### Fase 5: Optimización
|
||||
|
||||
`[Modo: Optimizar]` - Revisión liderada por Gemini
|
||||
|
||||
**DEBE llamar a Gemini**:
|
||||
- Lista de problemas de accesibilidad, responsividad, rendimiento, consistencia de diseño
|
||||
|
||||
Integrar retroalimentación de la revisión, ejecutar optimización después de confirmación del usuario.
|
||||
|
||||
### Fase 6: Revisión de Calidad
|
||||
|
||||
`[Modo: Revisión]` - Evaluación final
|
||||
|
||||
- Verificar completitud contra el plan
|
||||
- Verificar responsividad y accesibilidad
|
||||
- Reportar problemas y recomendaciones
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. **Las opiniones frontend de Gemini son confiables**
|
||||
2. **Las opiniones frontend de Codex son solo de referencia**
|
||||
3. Los modelos externos tienen **cero acceso de escritura al sistema de archivos**
|
||||
4. Claude maneja todas las escrituras de código y operaciones de archivos
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
description: Crear un plan de implementación multi-modelo sin modificar código de producción.
|
||||
---
|
||||
|
||||
# Plan - Planificación Colaborativa Multi-Modelo
|
||||
|
||||
Planificación colaborativa multi-modelo - Recuperación de contexto + Análisis de doble modelo → Generar plan de implementación paso a paso.
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
## Protocolos Principales
|
||||
|
||||
- **Solo Planificación**: Este comando permite leer contexto y escribir en archivos de plan `.claude/plan/*`, pero **NUNCA modificar código de producción**
|
||||
- **Soberanía del Código**: Los modelos externos tienen **cero acceso de escritura al sistema de archivos**, todas las modificaciones por Claude
|
||||
- **Paralelo Obligatorio**: Las llamadas a Codex/Gemini DEBEN usar `run_in_background: true`
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Ejecución
|
||||
|
||||
**Tarea de Planificación**: $ARGUMENTS
|
||||
|
||||
### Fase 1: Recuperación Completa de Contexto
|
||||
|
||||
`[Modo: Investigación]`
|
||||
|
||||
1. **Mejora del Prompt** (si el MCP ace-tool está disponible)
|
||||
2. **Recuperación de Contexto**: Obtener definiciones y firmas completas para clases, funciones y variables relevantes
|
||||
3. **Verificación de Completitud**: Si los requisitos aún tienen ambigüedad, **DEBE** presentar preguntas guía al usuario
|
||||
|
||||
### Fase 2: Análisis Colaborativo Multi-Modelo
|
||||
|
||||
`[Modo: Análisis]`
|
||||
|
||||
**Llamadas en Paralelo** a Codex y Gemini:
|
||||
|
||||
1. **Análisis Backend de Codex**: Viabilidad técnica, impacto arquitectónico, consideraciones de rendimiento
|
||||
2. **Análisis Frontend de Gemini**: Impacto en UI/UX, experiencia de usuario, diseño visual
|
||||
|
||||
**Guardar SESSION_ID** (`CODEX_SESSION` y `GEMINI_SESSION`).
|
||||
|
||||
**Validación Cruzada**:
|
||||
1. Identificar consenso (señal fuerte)
|
||||
2. Identificar divergencia (necesita ponderación)
|
||||
3. Fortalezas complementarias: lógica backend sigue a Codex, diseño frontend sigue a Gemini
|
||||
|
||||
### Fase 2: Generar Plan de Implementación (Versión Final de Claude)
|
||||
|
||||
Sintetizar ambos análisis, generar **Plan de Implementación Paso a Paso**:
|
||||
|
||||
```markdown
|
||||
## Plan de Implementación: <Nombre de Tarea>
|
||||
|
||||
### Tipo de Tarea
|
||||
- [ ] Frontend (→ Gemini)
|
||||
- [ ] Backend (→ Codex)
|
||||
- [ ] Fullstack (→ Paralelo)
|
||||
|
||||
### Solución Técnica
|
||||
<Solución óptima sintetizada del análisis de Codex + Gemini>
|
||||
|
||||
### Pasos de Implementación
|
||||
1. <Paso 1> - Entregable esperado
|
||||
2. <Paso 2> - Entregable esperado
|
||||
...
|
||||
|
||||
### Archivos Clave
|
||||
| Archivo | Operación | Descripción |
|
||||
|---------|-----------|-------------|
|
||||
| ruta/al/archivo.ts:L10-L50 | Modificar | Descripción |
|
||||
|
||||
### SESSION_ID (para uso de /ccg:execute)
|
||||
- CODEX_SESSION: <session_id>
|
||||
- GEMINI_SESSION: <session_id>
|
||||
```
|
||||
|
||||
### Fin de Fase 2: Entrega del Plan (No Ejecución)
|
||||
|
||||
**Las responsabilidades de `/ccg:plan` terminan aquí**:
|
||||
|
||||
1. Presentar el plan completo al usuario
|
||||
2. Guardar el plan en `.claude/plan/<nombre-característica>.md`
|
||||
3. Solicitar revisión del usuario
|
||||
|
||||
**ABSOLUTAMENTE PROHIBIDO**:
|
||||
- Preguntar "Y/N" y luego auto-ejecutar (la ejecución es responsabilidad de `/ccg:execute`)
|
||||
- Cualquier operación de escritura en código de producción
|
||||
- Llamar automáticamente a `/ccg:execute` o cualquier acción de implementación
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. **Solo planificación, sin implementación** – Este comando no ejecuta ningún cambio de código
|
||||
2. **Sin prompts Y/N** – Solo presentar el plan, dejar que el usuario decida los próximos pasos
|
||||
3. **Reglas de Confianza** – Backend sigue a Codex, Frontend sigue a Gemini
|
||||
4. Los modelos externos tienen **cero acceso de escritura al sistema de archivos**
|
||||
5. **Traspaso de SESSION_ID** – El plan debe incluir `CODEX_SESSION` / `GEMINI_SESSION` al final
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
description: Ejecutar un flujo de trabajo de desarrollo multi-modelo completo con investigación, planificación, ejecución, optimización y revisión.
|
||||
---
|
||||
|
||||
# Workflow - Desarrollo Colaborativo Multi-Modelo
|
||||
|
||||
Flujo de trabajo de desarrollo colaborativo multi-modelo (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión), con enrutamiento inteligente: Frontend → Gemini, Backend → Codex.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
/workflow <descripción de la tarea>
|
||||
```
|
||||
|
||||
## Contexto
|
||||
|
||||
- Tarea a desarrollar: $ARGUMENTS
|
||||
- Flujo de trabajo estructurado de 6 fases con puertas de calidad
|
||||
- Colaboración multi-modelo: Codex (backend) + Gemini (frontend) + Claude (orquestación)
|
||||
|
||||
## Tu Rol
|
||||
|
||||
Eres el **Orquestador**, coordinando un sistema colaborativo multi-modelo (Investigación → Ideación → Plan → Ejecución → Optimización → Revisión).
|
||||
|
||||
**Modelos Colaboradores**:
|
||||
- **Codex** – Lógica backend, algoritmos, depuración (**Autoridad de backend, confiable**)
|
||||
- **Gemini** – UI/UX frontend, diseño visual (**Experto en frontend, opiniones de backend solo como referencia**)
|
||||
- **Claude (propio)** – Orquestación, planificación, ejecución, entrega
|
||||
|
||||
---
|
||||
|
||||
## Pautas de Comunicación
|
||||
|
||||
1. Comenzar respuestas con etiqueta de modo `[Modo: X]`, el inicial es `[Modo: Investigación]`
|
||||
2. Seguir secuencia estricta: `Investigación → Ideación → Plan → Ejecución → Optimización → Revisión`
|
||||
3. Solicitar confirmación del usuario después de completar cada fase
|
||||
4. Forzar parada cuando la puntuación < 7 o el usuario no aprueba
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Ejecución
|
||||
|
||||
**Descripción de la Tarea**: $ARGUMENTS
|
||||
|
||||
### Fase 1: Investigación y Análisis
|
||||
|
||||
`[Modo: Investigación]` - Entender requisitos y recopilar contexto:
|
||||
|
||||
1. **Mejora del Prompt** (si el MCP ace-tool está disponible)
|
||||
2. **Recuperación de Contexto**
|
||||
3. **Puntuación de Completitud de Requisitos** (0-10):
|
||||
- Claridad del objetivo (0-3), Resultado esperado (0-3), Límites del alcance (0-2), Restricciones (0-2)
|
||||
- ≥7: Continuar | <7: Parar, hacer preguntas aclaratorias
|
||||
|
||||
### Fase 2: Ideación de Soluciones
|
||||
|
||||
`[Modo: Ideación]` - Análisis paralelo multi-modelo:
|
||||
|
||||
**Llamadas en Paralelo**:
|
||||
- Codex: Viabilidad técnica, soluciones, riesgos
|
||||
- Gemini: Viabilidad de UI, soluciones, evaluación de UX
|
||||
|
||||
**Guardar SESSION_ID** (`CODEX_SESSION` y `GEMINI_SESSION`).
|
||||
|
||||
### Fase 3: Planificación Detallada
|
||||
|
||||
`[Modo: Plan]` - Planificación colaborativa multi-modelo:
|
||||
|
||||
**Llamadas en Paralelo** (reanudar sesión):
|
||||
- Codex: Arquitectura backend
|
||||
- Gemini: Arquitectura frontend
|
||||
|
||||
**Síntesis de Claude**: Adoptar plan backend de Codex + plan frontend de Gemini.
|
||||
|
||||
### Fase 4: Implementación
|
||||
|
||||
`[Modo: Ejecutar]` - Desarrollo de código:
|
||||
|
||||
- Seguir estrictamente el plan aprobado
|
||||
- Seguir los estándares de código existentes del proyecto
|
||||
|
||||
### Fase 5: Optimización de Código
|
||||
|
||||
`[Modo: Optimizar]` - Revisión paralela multi-modelo:
|
||||
|
||||
**Llamadas en Paralelo**:
|
||||
- Codex: Seguridad, rendimiento, manejo de errores
|
||||
- Gemini: Accesibilidad, consistencia de diseño
|
||||
|
||||
### Fase 6: Revisión de Calidad
|
||||
|
||||
`[Modo: Revisión]` - Evaluación final:
|
||||
|
||||
- Verificar completitud contra el plan
|
||||
- Ejecutar pruebas para verificar la funcionalidad
|
||||
- Reportar problemas y recomendaciones
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. La secuencia de fases no puede omitirse (a menos que el usuario lo indique explícitamente)
|
||||
2. Los modelos externos tienen **cero acceso de escritura al sistema de archivos**, todas las modificaciones por Claude
|
||||
3. **Forzar parada** cuando la puntuación < 7 o el usuario no aprueba
|
||||
@@ -0,0 +1,231 @@
|
||||
---
|
||||
description: Guía de orquestación secuencial y tmux/worktree para flujos de trabajo multi-agente.
|
||||
---
|
||||
|
||||
# Comando Orchestrate
|
||||
|
||||
Flujo de trabajo secuencial de agentes para tareas complejas.
|
||||
|
||||
## Uso
|
||||
|
||||
`/orchestrate [tipo-workflow] [descripción-de-tarea]`
|
||||
|
||||
## Tipos de Workflow
|
||||
|
||||
### feature
|
||||
Flujo de trabajo completo de implementación de feature:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
```
|
||||
|
||||
### bugfix
|
||||
Flujo de trabajo de investigación y corrección de bugs:
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer
|
||||
```
|
||||
|
||||
### refactor
|
||||
Flujo de trabajo de refactoring seguro:
|
||||
```
|
||||
architect -> code-reviewer -> tdd-guide
|
||||
```
|
||||
|
||||
### security
|
||||
Revisión enfocada en seguridad:
|
||||
```
|
||||
security-reviewer -> code-reviewer -> architect
|
||||
```
|
||||
|
||||
## Patrón de Ejecución
|
||||
|
||||
Para cada agente en el flujo de trabajo:
|
||||
|
||||
1. **Invocar el agente** con el contexto del agente anterior
|
||||
2. **Recopilar la salida** como documento de handoff estructurado
|
||||
3. **Pasarlo al siguiente agente** en la cadena
|
||||
4. **Consolidar los resultados** en el reporte final
|
||||
|
||||
## Formato del Documento de Handoff
|
||||
|
||||
Entre agentes, crear el documento de handoff:
|
||||
|
||||
```markdown
|
||||
## HANDOFF: [agente-anterior] -> [agente-siguiente]
|
||||
|
||||
### Context
|
||||
[Resumen de lo que se hizo]
|
||||
|
||||
### Findings
|
||||
[Descubrimientos o decisiones clave]
|
||||
|
||||
### Files Modified
|
||||
[Lista de archivos tocados]
|
||||
|
||||
### Open Questions
|
||||
[Elementos sin resolver para el siguiente agente]
|
||||
|
||||
### Recommendations
|
||||
[Próximos pasos recomendados]
|
||||
```
|
||||
|
||||
## Ejemplo: Flujo de Trabajo Feature
|
||||
|
||||
```
|
||||
/orchestrate feature "Agregar autenticación de usuarios"
|
||||
```
|
||||
|
||||
Ejecuta:
|
||||
|
||||
1. **Agente Planner**
|
||||
- Analiza los requisitos
|
||||
- Crea un plan de implementación
|
||||
- Identifica dependencias
|
||||
- Salida: `HANDOFF: planner -> tdd-guide`
|
||||
|
||||
2. **Agente TDD Guide**
|
||||
- Lee el handoff del planner
|
||||
- Escribe las pruebas primero
|
||||
- Implementa para que las pruebas pasen
|
||||
- Salida: `HANDOFF: tdd-guide -> code-reviewer`
|
||||
|
||||
3. **Agente Code Reviewer**
|
||||
- Revisa la implementación
|
||||
- Verifica problemas
|
||||
- Sugiere mejoras
|
||||
- Salida: `HANDOFF: code-reviewer -> security-reviewer`
|
||||
|
||||
4. **Agente Security Reviewer**
|
||||
- Auditoría de seguridad
|
||||
- Verificación de vulnerabilidades
|
||||
- Aprobación final
|
||||
- Salida: Reporte Final
|
||||
|
||||
## Formato del Reporte Final
|
||||
|
||||
```
|
||||
ORCHESTRATION REPORT
|
||||
====================
|
||||
Workflow: feature
|
||||
Task: Agregar autenticación de usuarios
|
||||
Agents: planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
|
||||
SUMMARY
|
||||
-------
|
||||
[Resumen en un párrafo]
|
||||
|
||||
AGENT OUTPUTS
|
||||
-------------
|
||||
Planner: [resumen]
|
||||
TDD Guide: [resumen]
|
||||
Code Reviewer: [resumen]
|
||||
Security Reviewer: [resumen]
|
||||
|
||||
FILES CHANGED
|
||||
-------------
|
||||
[Lista de todos los archivos modificados]
|
||||
|
||||
TEST RESULTS
|
||||
------------
|
||||
[Resumen de pruebas pasadas/fallidas]
|
||||
|
||||
SECURITY STATUS
|
||||
---------------
|
||||
[Hallazgos de seguridad]
|
||||
|
||||
RECOMMENDATION
|
||||
--------------
|
||||
[SHIP / NEEDS WORK / BLOCKED]
|
||||
```
|
||||
|
||||
## Ejecución Paralela
|
||||
|
||||
Para verificaciones independientes, ejecutar agentes en paralelo:
|
||||
|
||||
```markdown
|
||||
### Fase Paralela
|
||||
Ejecutar simultáneamente:
|
||||
- code-reviewer (calidad)
|
||||
- security-reviewer (seguridad)
|
||||
- architect (diseño)
|
||||
|
||||
### Combinar Resultados
|
||||
Combinar las salidas en un único reporte
|
||||
```
|
||||
|
||||
Para workers externos en tmux pane con git worktrees separados, usar `node scripts/orchestrate-worktrees.js plan.json --execute`. El patrón de orquestación integrado permanece en proceso; el helper sirve para sesiones de larga duración o cross-harness.
|
||||
|
||||
Cuando los workers necesiten ver archivos locales no rastreados o sucios del checkout principal, agregar `seedPaths` al archivo de plan. ECC superpone solo esas rutas seleccionadas en cada worktree de worker después de `git worktree add`; esto muestra scripts, planes o documentos locales en progreso mientras mantiene el branch aislado.
|
||||
|
||||
```json
|
||||
{
|
||||
"sessionName": "workflow-e2e",
|
||||
"seedPaths": [
|
||||
"scripts/orchestrate-worktrees.js",
|
||||
"scripts/lib/tmux-worktree-orchestrator.js",
|
||||
".claude/plan/workflow-e2e-test.json"
|
||||
],
|
||||
"workers": [
|
||||
{ "name": "docs", "task": "Actualizar documentación de orquestación." }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Para exportar un snapshot del plano de control de una sesión tmux/worktree activa, ejecutar:
|
||||
|
||||
```bash
|
||||
node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
|
||||
```
|
||||
|
||||
El snapshot contiene actividad de sesión, metadatos de pane de tmux, estados de workers, objetivos, seed overlays y resúmenes de handoff recientes en formato JSON.
|
||||
|
||||
## Handoff al Centro de Control del Operador
|
||||
|
||||
Cuando el flujo de trabajo se extiende a múltiples sesiones, worktrees o panes de tmux, agregar un bloque de plano de control al handoff final:
|
||||
|
||||
```markdown
|
||||
CONTROL PLANE
|
||||
-------------
|
||||
Sessions:
|
||||
- ID o alias de sesión activa
|
||||
- branch + ruta de worktree para cada worker activo
|
||||
- nombre del pane de tmux o sesión detached donde aplique
|
||||
|
||||
Diffs:
|
||||
- resumen de git status
|
||||
- git diff --stat de archivos tocados
|
||||
- notas de riesgo de merge/conflictos
|
||||
|
||||
Approvals:
|
||||
- aprobaciones de usuario pendientes
|
||||
- pasos bloqueados esperando aprobación
|
||||
|
||||
Telemetry:
|
||||
- timestamp de última actividad o señal de idle
|
||||
- deriva estimada de tokens o costos
|
||||
- eventos de política reportados por hooks o revisores
|
||||
```
|
||||
|
||||
Esto mantiene al planner, implementador, revisor y workers del loop comprensibles desde la superficie del operador.
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `feature <descripción>` - Flujo de trabajo completo de feature
|
||||
- `bugfix <descripción>` - Flujo de trabajo de corrección de bug
|
||||
- `refactor <descripción>` - Flujo de trabajo de refactoring
|
||||
- `security <descripción>` - Flujo de trabajo de revisión de seguridad
|
||||
- `custom <agentes> <descripción>` - Secuencia de agentes personalizada
|
||||
|
||||
## Ejemplo de Workflow Personalizado
|
||||
|
||||
```
|
||||
/orchestrate custom "architect,tdd-guide,code-reviewer" "Rediseñar la capa de caché"
|
||||
```
|
||||
|
||||
## Consejos
|
||||
|
||||
1. **Comenzar con planner para features complejas**
|
||||
2. **Siempre incluir code-reviewer antes del merge**
|
||||
3. **Usar security-reviewer para auth/pagos/PII**
|
||||
4. **Mantener los handoffs concisos** - enfocarse en lo que el siguiente agente necesita
|
||||
5. **Ejecutar validación entre agentes si es necesario**
|
||||
@@ -0,0 +1,109 @@
|
||||
---
|
||||
description: Reformular requisitos, evaluar riesgos y crear un plan de implementación paso a paso. ESPERAR confirmación del usuario antes de tocar cualquier código.
|
||||
argument-hint: "[descripción de la funcionalidad | ruta/a/*.prd.md]"
|
||||
---
|
||||
|
||||
# Comando Plan
|
||||
|
||||
Este comando crea un plan de implementación completo antes de escribir cualquier código. Acepta tanto requisitos en texto libre como un archivo PRD en Markdown.
|
||||
|
||||
Ejecutar inline por defecto. No llamar a la herramienta Task ni a ningún subagente por defecto.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Reformular Requisitos** - Aclarar qué necesita construirse
|
||||
2. **Identificar Riesgos** - Detectar problemas potenciales y bloqueadores
|
||||
3. **Crear Plan de Pasos** - Descomponer la implementación en fases
|
||||
4. **Esperar Confirmación** - DEBE recibir aprobación del usuario antes de proceder
|
||||
|
||||
## Cuándo Usar
|
||||
|
||||
Usar `/plan` cuando:
|
||||
- Se empieza una nueva funcionalidad
|
||||
- Se hacen cambios arquitectónicos significativos
|
||||
- Se trabaja en refactorización compleja
|
||||
- Múltiples archivos/componentes se verán afectados
|
||||
- Los requisitos no están claros o son ambiguos
|
||||
|
||||
## Cómo Funciona
|
||||
|
||||
El asistente:
|
||||
|
||||
1. **Analiza la solicitud** y reformula los requisitos en términos claros
|
||||
2. **Fundamenta el plan** en patrones relevantes del código base cuando el repositorio está disponible
|
||||
3. **Descompone en fases** con pasos específicos y accionables
|
||||
4. **Identifica dependencias** entre componentes
|
||||
5. **Evalúa riesgos** y posibles bloqueadores
|
||||
6. **Estima la complejidad** (Alta/Media/Baja)
|
||||
7. **Presenta el plan** y ESPERA tu confirmación explícita
|
||||
|
||||
## Modos de Entrada
|
||||
|
||||
| Entrada | Modo | Comportamiento |
|
||||
|---------|------|---------------|
|
||||
| `ruta/al/nombre.prd.md` | Modo artefacto PRD | Leer el PRD, elegir el próximo hito de entrega pendiente y escribir `.claude/plans/{nombre}.plan.md` |
|
||||
| Cualquier otra ruta markdown | Modo referencia | Leer el archivo como contexto y producir un plan inline |
|
||||
| Texto libre | Modo conversacional | Producir un plan inline |
|
||||
| Entrada vacía | Modo aclaración | Preguntar qué debe planificarse |
|
||||
|
||||
## Fundamentación en Patrones
|
||||
|
||||
Antes de escribir el plan, buscar en el código base las convenciones que la implementación debe replicar:
|
||||
|
||||
| Categoría | Qué capturar |
|
||||
|-----------|-------------|
|
||||
| Nomenclatura | Archivo, función, tipo, comando o nomenclatura de scripts en el área afectada |
|
||||
| Manejo de errores | Cómo se generan, retornan, registran o manejan los fallos |
|
||||
| Logging | Niveles, formato y qué se registra |
|
||||
| Acceso a datos | Patrones de repositorio, servicio, consulta o sistema de archivos |
|
||||
| Pruebas | Ubicación de archivos de prueba, framework, fixtures y estilo de afirmaciones |
|
||||
|
||||
## Ejemplo de Uso
|
||||
|
||||
```
|
||||
Usuario: /plan Necesito añadir notificaciones en tiempo real cuando los mercados se resuelven
|
||||
|
||||
Asistente:
|
||||
# Plan de Implementación: Notificaciones de Resolución de Mercados en Tiempo Real
|
||||
|
||||
## Reformulación de Requisitos
|
||||
- Enviar notificaciones a usuarios cuando los mercados que observan se resuelven
|
||||
- Soporte para múltiples canales (en-app, email, webhook)
|
||||
- Asegurar entrega confiable de notificaciones
|
||||
|
||||
## Fases de Implementación
|
||||
|
||||
### Fase 1: Schema de Base de Datos
|
||||
- Añadir tabla de notificaciones con columnas: id, user_id, market_id, type, status, created_at
|
||||
|
||||
### Fase 2: Servicio de Notificaciones
|
||||
- Crear servicio en lib/notifications.ts
|
||||
- Implementar cola de notificaciones con BullMQ/Redis
|
||||
|
||||
## Riesgos
|
||||
- ALTO: Entregabilidad de email (SPF/DKIM requerido)
|
||||
- MEDIO: Rendimiento con 1000+ usuarios por mercado
|
||||
|
||||
## Complejidad Estimada: MEDIA
|
||||
|
||||
**ESPERANDO CONFIRMACIÓN**: ¿Proceder con este plan? (sí/no/modificar)
|
||||
```
|
||||
|
||||
## Notas Importantes
|
||||
|
||||
**CRÍTICO**: Este comando **NO** escribirá ningún código hasta que confirmes explícitamente el plan con "sí", "proceder" o respuesta afirmativa similar.
|
||||
|
||||
## Integración con Otros Comandos
|
||||
|
||||
Después de planificar:
|
||||
- Usar la skill `tdd-workflow` para implementar con desarrollo guiado por pruebas
|
||||
- Usar `/build-fix` si ocurren errores de build
|
||||
- Usar `/code-review` para revisar la implementación completada
|
||||
- Usar `/pr` o `/prp-pr` para abrir un pull request
|
||||
|
||||
## Agente Planificador Opcional
|
||||
|
||||
ECC también proporciona un agente `planner` para instalaciones manuales que incluyen archivos de agente. Usarlo solo cuando el runtime local ya expone ese subagente y el usuario lo pide explícitamente.
|
||||
|
||||
El archivo fuente se encuentra en:
|
||||
`agents/planner.md`
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
description: Analizar un proyecto y generar comandos de servicio PM2 para los servicios detectados de frontend, backend o base de datos.
|
||||
---
|
||||
|
||||
# PM2 Init
|
||||
|
||||
Auto-analizar el proyecto y generar comandos de servicio PM2.
|
||||
|
||||
**Comando**: `$ARGUMENTS`
|
||||
|
||||
---
|
||||
|
||||
## Flujo de Trabajo
|
||||
|
||||
1. Verificar PM2 (instalar mediante `npm install -g pm2` si falta)
|
||||
2. Escanear el proyecto para identificar servicios (frontend/backend/base de datos)
|
||||
3. Generar archivos de configuración y archivos de comando individuales
|
||||
|
||||
---
|
||||
|
||||
## Detección de Servicios
|
||||
|
||||
| Tipo | Detección | Puerto por Defecto |
|
||||
|------|-----------|-------------------|
|
||||
| Vite | vite.config.* | 5173 |
|
||||
| Next.js | next.config.* | 3000 |
|
||||
| Nuxt | nuxt.config.* | 3000 |
|
||||
| CRA | react-scripts en package.json | 3000 |
|
||||
| Express/Node | directorio server/backend/api + package.json | 3000 |
|
||||
| FastAPI/Flask | requirements.txt / pyproject.toml | 8000 |
|
||||
| Go | go.mod / main.go | 8080 |
|
||||
|
||||
**Prioridad de Detección de Puerto**: Usuario especificado > .env > archivo de config > args de scripts > puerto por defecto
|
||||
|
||||
---
|
||||
|
||||
## Archivos Generados
|
||||
|
||||
```
|
||||
project/
|
||||
├── ecosystem.config.cjs # Configuración PM2
|
||||
├── {backend}/start.cjs # Wrapper Python (si aplica)
|
||||
└── .claude/
|
||||
├── commands/
|
||||
│ ├── pm2-all.md # Iniciar todo + monit
|
||||
│ ├── pm2-all-stop.md # Detener todo
|
||||
│ ├── pm2-all-restart.md # Reiniciar todo
|
||||
│ ├── pm2-{puerto}.md # Iniciar único + logs
|
||||
│ ├── pm2-{puerto}-stop.md # Detener único
|
||||
│ ├── pm2-{puerto}-restart.md # Reiniciar único
|
||||
│ ├── pm2-logs.md # Ver todos los logs
|
||||
│ └── pm2-status.md # Ver estado
|
||||
└── scripts/
|
||||
├── pm2-logs-{puerto}.ps1 # Logs de servicio único
|
||||
└── pm2-monit.ps1 # Monitor PM2
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Configuración Windows (IMPORTANTE)
|
||||
|
||||
### ecosystem.config.cjs
|
||||
|
||||
**Debe usar extensión `.cjs`**
|
||||
|
||||
```javascript
|
||||
module.exports = {
|
||||
apps: [
|
||||
// Node.js (Vite/Next/Nuxt)
|
||||
{
|
||||
name: 'project-3000',
|
||||
cwd: './packages/web',
|
||||
script: 'node_modules/vite/bin/vite.js',
|
||||
args: '--port 3000',
|
||||
interpreter: 'C:/Program Files/nodejs/node.exe',
|
||||
env: { NODE_ENV: 'development' }
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Reglas Clave
|
||||
|
||||
1. **Archivo de config**: `ecosystem.config.cjs` (no .js)
|
||||
2. **Node.js**: Especificar ruta del bin directamente + intérprete
|
||||
3. **Python**: Script wrapper Node.js + `windowsHide: true`
|
||||
4. **Abrir nueva ventana**: `start wt.exe -d "{ruta}" pwsh -NoExit -c "comando"`
|
||||
5. **Contenido mínimo**: Cada archivo de comando tiene solo 1-2 líneas de descripción + bloque bash
|
||||
6. **Ejecución directa**: Sin necesidad de parseo por IA, solo ejecutar el comando bash
|
||||
|
||||
---
|
||||
|
||||
## Resumen Post-Init
|
||||
|
||||
Después de generar todos los archivos:
|
||||
|
||||
```
|
||||
## PM2 Init Completado
|
||||
|
||||
**Servicios:**
|
||||
|
||||
| Puerto | Nombre | Tipo |
|
||||
|--------|--------|------|
|
||||
| {puerto} | {nombre} | {tipo} |
|
||||
|
||||
**Comandos Claude:** /pm2-all, /pm2-all-stop, /pm2-{puerto}, /pm2-{puerto}-stop, /pm2-logs, /pm2-status
|
||||
|
||||
**Comandos de Terminal:**
|
||||
pm2 start ecosystem.config.cjs # Primera vez
|
||||
pm2 start all # Después de la primera vez
|
||||
pm2 stop all / pm2 restart all
|
||||
pm2 logs / pm2 status / pm2 monit
|
||||
pm2 resurrect # Restaurar lista guardada
|
||||
```
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
description: Identificar y eliminar de forma segura código muerto con verificación después de cada cambio.
|
||||
---
|
||||
|
||||
# Refactor Clean
|
||||
|
||||
Identificar y eliminar de forma segura código muerto con verificación de pruebas en cada paso.
|
||||
|
||||
## Paso 1: Detectar Código Muerto
|
||||
|
||||
Ejecutar herramientas de análisis según el tipo de proyecto:
|
||||
|
||||
| Herramienta | Qué Encuentra | Comando |
|
||||
|-------------|--------------|---------|
|
||||
| knip | Exportaciones, archivos, dependencias no usadas | `npx knip` |
|
||||
| depcheck | Dependencias npm no usadas | `npx depcheck` |
|
||||
| ts-prune | Exportaciones TypeScript no usadas | `npx ts-prune` |
|
||||
| vulture | Código Python no usado | `vulture src/` |
|
||||
| deadcode | Código Go no usado | `deadcode ./...` |
|
||||
| cargo-udeps | Dependencias Rust no usadas | `cargo +nightly udeps` |
|
||||
|
||||
Si no hay ninguna herramienta disponible, usar Grep para encontrar exportaciones con cero imports.
|
||||
|
||||
## Paso 2: Categorizar Hallazgos
|
||||
|
||||
Ordenar los hallazgos en niveles de seguridad:
|
||||
|
||||
| Nivel | Ejemplos | Acción |
|
||||
|-------|----------|--------|
|
||||
| **SEGURO** | Utilidades no usadas, helpers de prueba, funciones internas | Eliminar con confianza |
|
||||
| **PRECAUCIÓN** | Componentes, rutas de API, middleware | Verificar que no haya imports dinámicos ni consumidores externos |
|
||||
| **PELIGRO** | Archivos de config, puntos de entrada, definiciones de tipos | Investigar antes de tocar |
|
||||
|
||||
## Paso 3: Bucle de Eliminación Segura
|
||||
|
||||
Para cada elemento SEGURO:
|
||||
|
||||
1. **Ejecutar la suite de pruebas completa** — Establecer línea base (todo verde)
|
||||
2. **Eliminar el código muerto** — Usar la herramienta Edit para eliminación quirúrgica
|
||||
3. **Re-ejecutar la suite de pruebas** — Verificar que nada se rompió
|
||||
4. **Si las pruebas fallan** — Revertir inmediatamente con `git checkout -- <archivo>` y omitir este elemento
|
||||
5. **Si las pruebas pasan** — Continuar con el siguiente elemento
|
||||
|
||||
## Paso 4: Manejar Elementos de PRECAUCIÓN
|
||||
|
||||
Antes de eliminar elementos de PRECAUCIÓN:
|
||||
- Buscar imports dinámicos: `import()`, `require()`, `__import__`
|
||||
- Buscar referencias de string: nombres de rutas, nombres de componentes en configs
|
||||
- Verificar si se exporta desde una API pública de paquete
|
||||
- Verificar que no haya consumidores externos (revisar dependientes si está publicado)
|
||||
|
||||
## Paso 5: Consolidar Duplicados
|
||||
|
||||
Después de eliminar código muerto, buscar:
|
||||
- Funciones casi duplicadas (>80% similares) — fusionar en una
|
||||
- Definiciones de tipo redundantes — consolidar
|
||||
- Funciones wrapper que no añaden valor — inline
|
||||
- Re-exports que no tienen propósito — eliminar la indirección
|
||||
|
||||
## Paso 6: Resumen
|
||||
|
||||
Reportar resultados:
|
||||
|
||||
```
|
||||
Limpieza de Código Muerto
|
||||
──────────────────────────────
|
||||
Eliminado: 12 funciones no usadas
|
||||
3 archivos no usados
|
||||
5 dependencias no usadas
|
||||
Omitido: 2 elementos (pruebas fallaron)
|
||||
Guardado: ~450 líneas eliminadas
|
||||
──────────────────────────────
|
||||
Todas las pruebas pasando ✓
|
||||
```
|
||||
|
||||
## Reglas
|
||||
|
||||
- **Nunca eliminar sin ejecutar las pruebas primero**
|
||||
- **Una eliminación a la vez** — Los cambios atómicos facilitan el rollback
|
||||
- **Omitir si hay incertidumbre** — Mejor conservar código muerto que romper producción
|
||||
- **No refactorizar mientras se limpia** — Separar las preocupaciones (limpiar primero, refactorizar después)
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
description: Gestionar el historial de sesiones de Claude Code, alias y metadatos de sesión.
|
||||
---
|
||||
|
||||
# Comando Sessions
|
||||
|
||||
Gestionar el historial de sesiones de Claude Code - listar, cargar, crear alias y editar sesiones almacenadas en `~/.claude/session-data/` con lecturas heredadas desde `~/.claude/sessions/`.
|
||||
|
||||
## Uso
|
||||
|
||||
`/sessions [list|load|alias|info|help] [opciones]`
|
||||
|
||||
## Acciones
|
||||
|
||||
### Listar Sesiones
|
||||
|
||||
Mostrar todas las sesiones con metadatos, filtrado y paginación.
|
||||
|
||||
```bash
|
||||
/sessions # Listar todas las sesiones (por defecto)
|
||||
/sessions list # Igual que el anterior
|
||||
/sessions list --limit 10 # Mostrar 10 sesiones
|
||||
/sessions list --date 2026-02-01 # Filtrar por fecha
|
||||
/sessions list --search abc # Buscar por ID de sesión
|
||||
```
|
||||
|
||||
### Cargar Sesión
|
||||
|
||||
Cargar y mostrar el contenido de una sesión (por ID o alias).
|
||||
|
||||
```bash
|
||||
/sessions load <id|alias> # Cargar sesión
|
||||
/sessions load 2026-02-01 # Por fecha (para sesiones sin ID)
|
||||
/sessions load a1b2c3d4 # Por ID corto
|
||||
/sessions load my-alias # Por nombre de alias
|
||||
```
|
||||
|
||||
### Crear Alias
|
||||
|
||||
Crear un alias memorable para una sesión.
|
||||
|
||||
```bash
|
||||
/sessions alias <id> <nombre> # Crear alias
|
||||
/sessions alias 2026-02-01 hoy-trabajo # Crear alias llamado "hoy-trabajo"
|
||||
```
|
||||
|
||||
### Eliminar Alias
|
||||
|
||||
Eliminar un alias existente.
|
||||
|
||||
```bash
|
||||
/sessions alias --remove <nombre> # Eliminar alias
|
||||
/sessions unalias <nombre> # Igual que el anterior
|
||||
```
|
||||
|
||||
### Información de Sesión
|
||||
|
||||
Mostrar información detallada sobre una sesión.
|
||||
|
||||
```bash
|
||||
/sessions info <id|alias> # Mostrar detalles de la sesión
|
||||
```
|
||||
|
||||
### Listar Aliases
|
||||
|
||||
Mostrar todos los aliases de sesión.
|
||||
|
||||
```bash
|
||||
/sessions aliases # Listar todos los aliases
|
||||
```
|
||||
|
||||
## Notas del Operador
|
||||
|
||||
- Los archivos de sesión persisten `Project`, `Branch` y `Worktree` en el encabezado para que `/sessions info` pueda distinguir ejecuciones paralelas de tmux/worktree.
|
||||
- Para monitoreo estilo command-center, combinar `/sessions info`, `git diff --stat` y las métricas de costo emitidas por `scripts/hooks/cost-tracker.js`.
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS:
|
||||
- `list [opciones]` - Listar sesiones
|
||||
- `--limit <n>` - Máximo de sesiones a mostrar (por defecto: 50)
|
||||
- `--date <AAAA-MM-DD>` - Filtrar por fecha
|
||||
- `--search <patrón>` - Buscar en el ID de sesión
|
||||
- `load <id|alias>` - Cargar contenido de sesión
|
||||
- `alias <id> <nombre>` - Crear alias para la sesión
|
||||
- `alias --remove <nombre>` - Eliminar alias
|
||||
- `unalias <nombre>` - Igual que `--remove`
|
||||
- `info <id|alias>` - Mostrar estadísticas de la sesión
|
||||
- `aliases` - Listar todos los aliases
|
||||
- `help` - Mostrar esta ayuda
|
||||
|
||||
## Ejemplos
|
||||
|
||||
```bash
|
||||
# Listar todas las sesiones
|
||||
/sessions list
|
||||
|
||||
# Crear un alias para la sesión de hoy
|
||||
/sessions alias 2026-02-01 hoy
|
||||
|
||||
# Cargar sesión por alias
|
||||
/sessions load hoy
|
||||
|
||||
# Mostrar información de la sesión
|
||||
/sessions info hoy
|
||||
|
||||
# Eliminar alias
|
||||
/sessions alias --remove hoy
|
||||
|
||||
# Listar todos los aliases
|
||||
/sessions aliases
|
||||
```
|
||||
|
||||
## Notas
|
||||
|
||||
- Las sesiones se almacenan como archivos markdown en `~/.claude/session-data/` con lecturas heredadas desde `~/.claude/sessions/`
|
||||
- Los aliases se almacenan en `~/.claude/session-aliases.json`
|
||||
- Los IDs de sesión pueden abreviarse (los primeros 4-8 caracteres suelen ser suficientemente únicos)
|
||||
- Usar aliases para sesiones referenciadas frecuentemente
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
description: Configurar tu gestor de paquetes preferido (npm/pnpm/yarn/bun)
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Configuración del Gestor de Paquetes
|
||||
|
||||
Configurar tu gestor de paquetes preferido para este proyecto o globalmente.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
# Detectar el gestor de paquetes actual
|
||||
node scripts/setup-package-manager.js --detect
|
||||
|
||||
# Establecer preferencia global
|
||||
node scripts/setup-package-manager.js --global pnpm
|
||||
|
||||
# Establecer preferencia del proyecto
|
||||
node scripts/setup-package-manager.js --project bun
|
||||
|
||||
# Listar gestores de paquetes disponibles
|
||||
node scripts/setup-package-manager.js --list
|
||||
```
|
||||
|
||||
## Prioridad de Detección
|
||||
|
||||
Al determinar qué gestor de paquetes usar, se verifica el siguiente orden:
|
||||
|
||||
1. **Variable de entorno**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Config del proyecto**: `.claude/package-manager.json`
|
||||
3. **package.json**: campo `packageManager`
|
||||
4. **Lock file**: Presencia de package-lock.json, yarn.lock, pnpm-lock.yaml o bun.lockb
|
||||
5. **Config global**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: Primer gestor de paquetes disponible (pnpm > bun > yarn > npm)
|
||||
|
||||
## Archivos de Configuración
|
||||
|
||||
### Configuración Global
|
||||
```json
|
||||
// ~/.claude/package-manager.json
|
||||
{
|
||||
"packageManager": "pnpm"
|
||||
}
|
||||
```
|
||||
|
||||
### Configuración del Proyecto
|
||||
```json
|
||||
// .claude/package-manager.json
|
||||
{
|
||||
"packageManager": "bun"
|
||||
}
|
||||
```
|
||||
|
||||
### package.json
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.6.0"
|
||||
}
|
||||
```
|
||||
|
||||
## Variable de Entorno
|
||||
|
||||
Establecer `CLAUDE_PACKAGE_MANAGER` para anular todos los demás métodos de detección:
|
||||
|
||||
```bash
|
||||
# Windows (PowerShell)
|
||||
$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
|
||||
|
||||
# macOS/Linux
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
```
|
||||
|
||||
## Ejecutar la Detección
|
||||
|
||||
Para ver los resultados actuales de detección del gestor de paquetes:
|
||||
|
||||
```bash
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: skill-create
|
||||
description: Analizar el historial local de git para extraer patrones de codificación y generar archivos SKILL.md. Versión local de la Skill Creator GitHub App.
|
||||
allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
|
||||
---
|
||||
|
||||
# /skill-create - Generación Local de Skills
|
||||
|
||||
Analizar el historial de git de tu repositorio para extraer patrones de codificación y generar archivos SKILL.md que enseñan a Claude las prácticas de tu equipo.
|
||||
|
||||
## Uso
|
||||
|
||||
```bash
|
||||
/skill-create # Analizar el repositorio actual
|
||||
/skill-create --commits 100 # Analizar los últimos 100 commits
|
||||
/skill-create --output ./skills # Directorio de salida personalizado
|
||||
/skill-create --instincts # También generar instintos para continuous-learning-v2
|
||||
```
|
||||
|
||||
## Qué Hace
|
||||
|
||||
1. **Parsear Historial de Git** - Analizar commits, cambios de archivos y patrones
|
||||
2. **Detectar Patrones** - Identificar flujos de trabajo y convenciones recurrentes
|
||||
3. **Generar SKILL.md** - Crear archivos de skill válidos de Claude Code
|
||||
4. **Opcionalmente Crear Instintos** - Para el sistema continuous-learning-v2
|
||||
|
||||
## Pasos de Análisis
|
||||
|
||||
### Paso 1: Recopilar Datos de Git
|
||||
|
||||
```bash
|
||||
# Obtener commits recientes con cambios de archivos
|
||||
git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
|
||||
|
||||
# Obtener frecuencia de commits por archivo
|
||||
git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
|
||||
|
||||
# Obtener patrones de mensajes de commit
|
||||
git log --oneline -n 200 | cut -d' ' -f2- | head -50
|
||||
```
|
||||
|
||||
### Paso 2: Detectar Patrones
|
||||
|
||||
| Patrón | Método de Detección |
|
||||
|--------|---------------------|
|
||||
| **Convenciones de commit** | Regex en mensajes de commit (feat:, fix:, chore:) |
|
||||
| **Co-cambios de archivos** | Archivos que siempre cambian juntos |
|
||||
| **Secuencias de flujo de trabajo** | Patrones de cambio de archivos repetidos |
|
||||
| **Arquitectura** | Estructura de carpetas y convenciones de nomenclatura |
|
||||
| **Patrones de testing** | Ubicaciones de archivos de prueba, nomenclatura, cobertura |
|
||||
|
||||
### Paso 3: Generar SKILL.md
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: {nombre-repo}-patterns
|
||||
description: Patrones de codificación extraídos de {nombre-repo}
|
||||
version: 1.0.0
|
||||
source: local-git-analysis
|
||||
analyzed_commits: {cantidad}
|
||||
---
|
||||
|
||||
# Patrones de {Nombre Repo}
|
||||
|
||||
## Convenciones de Commit
|
||||
{patrones detectados en mensajes de commit}
|
||||
|
||||
## Arquitectura del Código
|
||||
{estructura de carpetas y organización detectadas}
|
||||
|
||||
## Flujos de Trabajo
|
||||
{patrones de cambio de archivos repetidos detectados}
|
||||
|
||||
## Patrones de Testing
|
||||
{convenciones de pruebas detectadas}
|
||||
```
|
||||
|
||||
## Integración con GitHub App
|
||||
|
||||
Para funciones avanzadas (10k+ commits, compartir en equipo, PRs automáticos), usar la [Skill Creator GitHub App](https://github.com/apps/skill-creator):
|
||||
|
||||
- Comentar `/skill-creator analyze` en cualquier issue
|
||||
- Recibe un PR con las skills generadas
|
||||
|
||||
## Comandos Relacionados
|
||||
|
||||
- `/instinct-import` - Importar instintos generados
|
||||
- `/instinct-status` - Ver instintos aprendidos
|
||||
- `/evolve` - Agrupar instintos en skills/agentes
|
||||
@@ -0,0 +1,328 @@
|
||||
---
|
||||
description: Aplicar el flujo de trabajo de desarrollo guiado por pruebas (TDD). Diseña interfaces, crea las pruebas PRIMERO, luego implementa el código mínimo. Garantiza 80%+ de cobertura de código.
|
||||
---
|
||||
|
||||
# Comando TDD
|
||||
|
||||
Este comando invoca al agente **tdd-guide** para aplicar la metodología de desarrollo guiado por pruebas.
|
||||
|
||||
## Qué Hace Este Comando
|
||||
|
||||
1. **Diseñar Interfaces** - Definir primero los tipos/interfaces
|
||||
2. **Crear Pruebas Primero** - Escribir pruebas que fallan (RED)
|
||||
3. **Implementar Código Mínimo** - Escribir el código justo para que pasen (GREEN)
|
||||
4. **Refactorizar** - Mejorar el código mientras las pruebas siguen en verde (REFACTOR)
|
||||
5. **Verificar Cobertura** - Garantizar 80%+ de cobertura de pruebas
|
||||
|
||||
## Cuándo Usarlo
|
||||
|
||||
Usa el comando `/tdd` cuando:
|
||||
- Implementes nuevas features
|
||||
- Agregues nuevas funciones/componentes
|
||||
- Corrijas bugs (primero escribe la prueba que reproduce el bug)
|
||||
- Refactorices código existente
|
||||
- Construyas lógica de negocio crítica
|
||||
|
||||
## Cómo Funciona
|
||||
|
||||
El agente tdd-guide:
|
||||
|
||||
1. **Definirá las interfaces** para entradas/salidas
|
||||
2. **Escribirá pruebas que FALLARÁN** (porque el código aún no existe)
|
||||
3. **Ejecutará las pruebas** y verificará que fallen por la razón correcta
|
||||
4. **Escribirá la implementación mínima** para que las pruebas pasen
|
||||
5. **Ejecutará las pruebas** y verificará que pasen
|
||||
6. **Refactorizará el código** mientras las pruebas siguen en verde
|
||||
7. **Verificará la cobertura** y agregará más pruebas si está por debajo del 80%
|
||||
|
||||
## El Ciclo TDD
|
||||
|
||||
```
|
||||
ROJO → VERDE → REFACTORIZAR → REPETIR
|
||||
|
||||
ROJO: Escribir una prueba que falla
|
||||
VERDE: Escribir el código mínimo para que pase
|
||||
REFACTORIZAR: Mejorar el código, las pruebas siguen pasando
|
||||
REPETIR: Siguiente feature/escenario
|
||||
```
|
||||
|
||||
## Ejemplo de Uso
|
||||
|
||||
```
|
||||
Usuario: /tdd Necesito una función para calcular el puntaje de liquidez de un mercado
|
||||
|
||||
Agente (tdd-guide):
|
||||
# Sesión TDD: Calculadora de Puntaje de Liquidez de Mercado
|
||||
|
||||
## Paso 1: Definir Interface (SCAFFOLD)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export interface MarketData {
|
||||
totalVolume: number
|
||||
bidAskSpread: number
|
||||
activeTraders: number
|
||||
lastTradeTime: Date
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// TODO: Implementación
|
||||
throw new Error('Not implemented')
|
||||
}
|
||||
```
|
||||
|
||||
## Paso 2: Escribir Prueba que Falla (ROJO)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.test.ts
|
||||
import { calculateLiquidityScore } from './liquidity'
|
||||
|
||||
describe('calculateLiquidityScore', () => {
|
||||
it('debe retornar puntaje alto para mercado líquido', () => {
|
||||
const market = {
|
||||
totalVolume: 100000,
|
||||
bidAskSpread: 0.01,
|
||||
activeTraders: 500,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeGreaterThan(80)
|
||||
expect(score).toBeLessThanOrEqual(100)
|
||||
})
|
||||
|
||||
it('debe retornar puntaje bajo para mercado poco líquido', () => {
|
||||
const market = {
|
||||
totalVolume: 100,
|
||||
bidAskSpread: 0.5,
|
||||
activeTraders: 2,
|
||||
lastTradeTime: new Date(Date.now() - 86400000) // hace 1 día
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBeLessThan(30)
|
||||
expect(score).toBeGreaterThanOrEqual(0)
|
||||
})
|
||||
|
||||
it('debe manejar caso límite: volumen cero', () => {
|
||||
const market = {
|
||||
totalVolume: 0,
|
||||
bidAskSpread: 0,
|
||||
activeTraders: 0,
|
||||
lastTradeTime: new Date()
|
||||
}
|
||||
|
||||
const score = calculateLiquidityScore(market)
|
||||
|
||||
expect(score).toBe(0)
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Paso 3: Ejecutar Pruebas - Verificar el Fallo
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
FAIL lib/liquidity.test.ts
|
||||
✕ debe retornar puntaje alto para mercado líquido (2 ms)
|
||||
Error: Not implemented
|
||||
|
||||
1 test failed, 0 passed
|
||||
```
|
||||
|
||||
PASS: Las pruebas fallan como se esperaba. Listo para implementar.
|
||||
|
||||
## Paso 4: Implementar Código Mínimo (VERDE)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
// Manejar caso límite de volumen cero
|
||||
if (market.totalVolume === 0) {
|
||||
return 0
|
||||
}
|
||||
|
||||
// Calcular puntajes de componentes (escala 0-100)
|
||||
const volumeScore = Math.min(market.totalVolume / 1000, 100)
|
||||
const spreadScore = Math.max(100 - (market.bidAskSpread * 1000), 0)
|
||||
const traderScore = Math.min(market.activeTraders / 10, 100)
|
||||
|
||||
// Bonus por actividad reciente
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = Math.max(100 - (hoursSinceLastTrade * 10), 0)
|
||||
|
||||
// Promedio ponderado
|
||||
const score = (
|
||||
volumeScore * 0.4 +
|
||||
spreadScore * 0.3 +
|
||||
traderScore * 0.2 +
|
||||
recencyScore * 0.1
|
||||
)
|
||||
|
||||
return Math.min(Math.max(score, 0), 100) // Limitar entre 0-100
|
||||
}
|
||||
```
|
||||
|
||||
## Paso 5: Ejecutar Pruebas - Verificar el Éxito
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ debe retornar puntaje alto para mercado líquido (3 ms)
|
||||
✓ debe retornar puntaje bajo para mercado poco líquido (2 ms)
|
||||
✓ debe manejar caso límite: volumen cero (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
PASS: ¡Todas las pruebas pasan!
|
||||
|
||||
## Paso 6: Refactorizar (MEJORAR)
|
||||
|
||||
```typescript
|
||||
// lib/liquidity.ts - Refactorizado con constantes y mejor legibilidad
|
||||
const WEIGHTS = {
|
||||
VOLUME: 0.4,
|
||||
SPREAD: 0.3,
|
||||
TRADERS: 0.2,
|
||||
RECENCY: 0.1,
|
||||
} as const
|
||||
|
||||
const SCALE_FACTORS = {
|
||||
VOLUME: 1000,
|
||||
SPREAD: 1000,
|
||||
TRADERS: 10,
|
||||
RECENCY_PENALTY: 10,
|
||||
} as const
|
||||
|
||||
function clamp(value: number, min: number, max: number): number {
|
||||
return Math.min(Math.max(value, min), max)
|
||||
}
|
||||
|
||||
export function calculateLiquidityScore(market: MarketData): number {
|
||||
if (market.totalVolume === 0) return 0
|
||||
|
||||
const volumeScore = Math.min(market.totalVolume / SCALE_FACTORS.VOLUME, 100)
|
||||
const spreadScore = clamp(100 - (market.bidAskSpread * SCALE_FACTORS.SPREAD), 0, 100)
|
||||
const traderScore = Math.min(market.activeTraders / SCALE_FACTORS.TRADERS, 100)
|
||||
|
||||
const hoursSinceLastTrade = (Date.now() - market.lastTradeTime.getTime()) / (1000 * 60 * 60)
|
||||
const recencyScore = clamp(100 - (hoursSinceLastTrade * SCALE_FACTORS.RECENCY_PENALTY), 0, 100)
|
||||
|
||||
const weightedScore =
|
||||
volumeScore * WEIGHTS.VOLUME +
|
||||
spreadScore * WEIGHTS.SPREAD +
|
||||
traderScore * WEIGHTS.TRADERS +
|
||||
recencyScore * WEIGHTS.RECENCY
|
||||
|
||||
return clamp(weightedScore, 0, 100)
|
||||
}
|
||||
```
|
||||
|
||||
## Paso 7: Verificar que las Pruebas Siguen Pasando
|
||||
|
||||
```bash
|
||||
npm test lib/liquidity.test.ts
|
||||
|
||||
PASS lib/liquidity.test.ts
|
||||
✓ debe retornar puntaje alto para mercado líquido (3 ms)
|
||||
✓ debe retornar puntaje bajo para mercado poco líquido (2 ms)
|
||||
✓ debe manejar caso límite: volumen cero (1 ms)
|
||||
|
||||
3 tests passed
|
||||
```
|
||||
|
||||
PASS: ¡Refactoring completo, las pruebas siguen pasando!
|
||||
|
||||
## Paso 8: Verificar Cobertura
|
||||
|
||||
```bash
|
||||
npm test -- --coverage lib/liquidity.test.ts
|
||||
|
||||
File | % Stmts | % Branch | % Funcs | % Lines
|
||||
---------------|---------|----------|---------|--------
|
||||
liquidity.ts | 100 | 100 | 100 | 100
|
||||
|
||||
Coverage: 100% PASS (Objetivo: 80%)
|
||||
```
|
||||
|
||||
PASS: ¡Sesión TDD completada!
|
||||
```
|
||||
|
||||
## Buenas Prácticas de TDD
|
||||
|
||||
**HAZ:**
|
||||
- PASS: Escribe la prueba ANTES de cualquier implementación
|
||||
- PASS: Ejecuta las pruebas y verifica que fallen antes de implementar
|
||||
- PASS: Escribe el código mínimo para que las pruebas pasen
|
||||
- PASS: Refactoriza después de que las pruebas estén en verde
|
||||
- PASS: Agrega casos límite y escenarios de error
|
||||
- PASS: Apunta a 80%+ de cobertura (100% para código crítico)
|
||||
|
||||
**NO HAGAS:**
|
||||
- FAIL: No escribas implementación antes de las pruebas
|
||||
- FAIL: No omitas ejecutar las pruebas después de cada cambio
|
||||
- FAIL: No escribas demasiado código de una vez
|
||||
- FAIL: No ignores pruebas que fallan
|
||||
- FAIL: No pruebes detalles de implementación (prueba el comportamiento)
|
||||
- FAIL: No hagas mock de todo (prefiere pruebas de integración)
|
||||
|
||||
## Tipos de Pruebas a Incluir
|
||||
|
||||
**Pruebas Unitarias** (nivel de función):
|
||||
- Escenarios de camino feliz
|
||||
- Casos límite (vacío, null, valores máximos)
|
||||
- Condiciones de error
|
||||
- Valores límite
|
||||
|
||||
**Pruebas de Integración** (nivel de componente):
|
||||
- Endpoints de API
|
||||
- Operaciones de base de datos
|
||||
- Llamadas a servicios externos
|
||||
- Componentes React con hooks
|
||||
|
||||
**Pruebas E2E** (usar el comando `/e2e`):
|
||||
- Flujos de usuario críticos
|
||||
- Procesos de múltiples pasos
|
||||
- Integración full stack
|
||||
|
||||
## Requisitos de Cobertura
|
||||
|
||||
- **Mínimo 80%** para todo el código
|
||||
- **100% requerido**:
|
||||
- Cálculos financieros
|
||||
- Lógica de autenticación
|
||||
- Código crítico de seguridad
|
||||
- Lógica de negocio principal
|
||||
|
||||
## Notas Importantes
|
||||
|
||||
**OBLIGATORIO**: Las pruebas deben escribirse ANTES de la implementación. El ciclo TDD:
|
||||
|
||||
1. **ROJO** - Escribir prueba que falla
|
||||
2. **VERDE** - Implementar para que pase
|
||||
3. **REFACTORIZAR** - Mejorar el código
|
||||
|
||||
Nunca omitas la fase ROJO. Nunca escribas código antes de las pruebas.
|
||||
|
||||
## Integración con Otros Comandos
|
||||
|
||||
- Usa `/plan` primero para entender qué construir
|
||||
- Usa `/tdd` para implementar con pruebas
|
||||
- Usa `/build-fix` si surgen errores de build
|
||||
- Usa `/code-review` para revisar la implementación
|
||||
- Usa `/test-coverage` para verificar la cobertura
|
||||
|
||||
## Agentes Relacionados
|
||||
|
||||
Este comando invoca al agente `tdd-guide` proporcionado por ECC.
|
||||
|
||||
La skill relacionada `tdd-workflow` también viene incluida con ECC.
|
||||
|
||||
Para instalaciones manuales, los archivos fuente se encuentran en:
|
||||
- `agents/tdd-guide.md`
|
||||
- `skills/tdd-workflow/SKILL.md`
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
description: Analizar la cobertura, identificar brechas y generar pruebas faltantes hacia el umbral objetivo.
|
||||
---
|
||||
|
||||
# Cobertura de Pruebas
|
||||
|
||||
Analizar la cobertura de pruebas, identificar brechas y generar las pruebas faltantes para alcanzar 80%+ de cobertura.
|
||||
|
||||
## Paso 1: Detectar el Framework de Pruebas
|
||||
|
||||
| Indicador | Comando de Cobertura |
|
||||
|-----------|---------------------|
|
||||
| `jest.config.*` o `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
|
||||
| `vitest.config.*` | `npx vitest run --coverage` |
|
||||
| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
|
||||
| `Cargo.toml` | `cargo llvm-cov --json` |
|
||||
| `pom.xml` con JaCoCo | `mvn test jacoco:report` |
|
||||
| `go.mod` | `go test -coverprofile=coverage.out ./...` |
|
||||
|
||||
## Paso 2: Analizar el Reporte de Cobertura
|
||||
|
||||
1. Ejecutar el comando de cobertura
|
||||
2. Parsear la salida (resumen JSON o salida del terminal)
|
||||
3. Listar archivos **por debajo del 80% de cobertura**, ordenados del peor al mejor
|
||||
4. Para cada archivo con cobertura insuficiente, identificar:
|
||||
- Funciones o métodos no probados
|
||||
- Cobertura de ramas faltante (if/else, switch, rutas de error)
|
||||
- Código muerto que infla el denominador
|
||||
|
||||
## Paso 3: Generar Pruebas Faltantes
|
||||
|
||||
Para cada archivo con cobertura insuficiente, generar pruebas siguiendo esta prioridad:
|
||||
|
||||
1. **Ruta feliz** — Funcionalidad principal con entradas válidas
|
||||
2. **Manejo de errores** — Entradas inválidas, datos faltantes, fallos de red
|
||||
3. **Casos límite** — Arrays vacíos, null/undefined, valores límite (0, -1, MAX_INT)
|
||||
4. **Cobertura de ramas** — Cada if/else, case de switch, ternario
|
||||
|
||||
### Reglas de Generación de Pruebas
|
||||
|
||||
- Colocar pruebas adyacentes al fuente: `foo.ts` → `foo.test.ts` (o convención del proyecto)
|
||||
- Usar patrones de prueba existentes del proyecto (estilo de import, librería de afirmaciones, enfoque de mocking)
|
||||
- Mockear dependencias externas (base de datos, APIs, sistema de archivos)
|
||||
- Cada prueba debe ser independiente — sin estado mutable compartido entre pruebas
|
||||
- Nombrar las pruebas descriptivamente: `test_create_user_with_duplicate_email_returns_409`
|
||||
|
||||
## Paso 4: Verificar
|
||||
|
||||
1. Ejecutar la suite de pruebas completa — todas las pruebas deben pasar
|
||||
2. Re-ejecutar la cobertura — verificar mejora
|
||||
3. Si aún está por debajo del 80%, repetir el Paso 3 para las brechas restantes
|
||||
|
||||
## Paso 5: Reportar
|
||||
|
||||
Mostrar comparación antes/después:
|
||||
|
||||
```
|
||||
Reporte de Cobertura
|
||||
──────────────────────────────
|
||||
Archivo Antes Después
|
||||
src/services/auth.ts 45% 88%
|
||||
src/utils/validation.ts 32% 82%
|
||||
──────────────────────────────
|
||||
Total: 67% 84% ✓
|
||||
```
|
||||
|
||||
## Áreas de Enfoque
|
||||
|
||||
- Funciones con ramificación compleja (alta complejidad ciclomática)
|
||||
- Manejadores de errores y bloques catch
|
||||
- Funciones de utilidad usadas en toda la base de código
|
||||
- Manejadores de endpoints de API (flujo solicitud → respuesta)
|
||||
- Casos límite: null, undefined, string vacío, array vacío, cero, números negativos
|
||||
@@ -0,0 +1,88 @@
|
||||
---
|
||||
description: Sincronizar la documentación desde archivos de fuente de verdad como scripts, schemas, rutas y exportaciones.
|
||||
---
|
||||
|
||||
# Actualizar Documentación
|
||||
|
||||
Sincronizar la documentación con el código base, generándola desde archivos de fuente de verdad.
|
||||
|
||||
## Paso 1: Identificar Fuentes de Verdad
|
||||
|
||||
| Fuente | Genera |
|
||||
|--------|--------|
|
||||
| Scripts de `package.json` | Referencia de comandos disponibles |
|
||||
| `.env.example` | Documentación de variables de entorno |
|
||||
| `openapi.yaml` / archivos de rutas | Referencia de endpoints de API |
|
||||
| Exportaciones del código fuente | Documentación de la API pública |
|
||||
| `Dockerfile` / `docker-compose.yml` | Docs de configuración de infraestructura |
|
||||
|
||||
## Paso 2: Generar Referencia de Scripts
|
||||
|
||||
1. Leer `package.json` (o `Makefile`, `Cargo.toml`, `pyproject.toml`)
|
||||
2. Extraer todos los scripts/comandos con sus descripciones
|
||||
3. Generar una tabla de referencia:
|
||||
|
||||
```markdown
|
||||
| Comando | Descripción |
|
||||
|---------|-------------|
|
||||
| `npm run dev` | Iniciar servidor de desarrollo con recarga en caliente |
|
||||
| `npm run build` | Build de producción con verificación de tipos |
|
||||
| `npm test` | Ejecutar suite de pruebas con cobertura |
|
||||
```
|
||||
|
||||
## Paso 3: Generar Documentación de Entorno
|
||||
|
||||
1. Leer `.env.example` (o `.env.template`, `.env.sample`)
|
||||
2. Extraer todas las variables con sus propósitos
|
||||
3. Categorizar como requeridas vs opcionales
|
||||
4. Documentar el formato esperado y los valores válidos
|
||||
|
||||
```markdown
|
||||
| Variable | Requerida | Descripción | Ejemplo |
|
||||
|----------|-----------|-------------|---------|
|
||||
| `DATABASE_URL` | Sí | String de conexión PostgreSQL | `postgres://user:pass@host:5432/db` |
|
||||
| `LOG_LEVEL` | No | Verbosidad de logging (por defecto: info) | `debug`, `info`, `warn`, `error` |
|
||||
```
|
||||
|
||||
## Paso 4: Actualizar Guía de Contribución
|
||||
|
||||
Generar o actualizar `docs/CONTRIBUTING.md` con:
|
||||
- Configuración del entorno de desarrollo (prerrequisitos, pasos de instalación)
|
||||
- Scripts disponibles y sus propósitos
|
||||
- Procedimientos de testing (cómo ejecutar, cómo escribir nuevas pruebas)
|
||||
- Aplicación del estilo de código (linter, formateador, hooks de pre-commit)
|
||||
- Lista de verificación para envío de PRs
|
||||
|
||||
## Paso 5: Actualizar Runbook
|
||||
|
||||
Generar o actualizar `docs/RUNBOOK.md` con:
|
||||
- Procedimientos de despliegue (paso a paso)
|
||||
- Endpoints de health check y monitoreo
|
||||
- Problemas comunes y sus soluciones
|
||||
- Procedimientos de rollback
|
||||
- Rutas de alertas y escalada
|
||||
|
||||
## Paso 6: Verificación de Obsolescencia
|
||||
|
||||
1. Encontrar archivos de documentación no modificados en 90+ días
|
||||
2. Hacer referencia cruzada con cambios recientes en el código fuente
|
||||
3. Marcar documentos potencialmente desactualizados para revisión manual
|
||||
|
||||
## Paso 7: Mostrar Resumen
|
||||
|
||||
```
|
||||
Actualización de Documentación
|
||||
──────────────────────────────
|
||||
Actualizado: docs/CONTRIBUTING.md (tabla de scripts)
|
||||
Actualizado: docs/ENV.md (3 nuevas variables)
|
||||
Marcado: docs/DEPLOY.md (142 días sin actualizar)
|
||||
Omitido: docs/API.md (sin cambios detectados)
|
||||
──────────────────────────────
|
||||
```
|
||||
|
||||
## Reglas
|
||||
|
||||
- **Fuente única de verdad**: Siempre generar desde el código, nunca editar manualmente secciones generadas
|
||||
- **Preservar secciones manuales**: Solo actualizar secciones generadas; dejar la prosa escrita a mano intacta
|
||||
- **Marcar contenido generado**: Usar marcadores `<!-- AUTO-GENERATED -->` alrededor de las secciones generadas
|
||||
- **No crear docs sin instrucción**: Solo crear nuevos archivos de documentación si el comando lo solicita explícitamente
|
||||
@@ -0,0 +1,59 @@
|
||||
# Comando Verify
|
||||
|
||||
Ejecutar verificación exhaustiva sobre el estado actual del código base.
|
||||
|
||||
## Instrucciones
|
||||
|
||||
Ejecutar la verificación exactamente en este orden:
|
||||
|
||||
1. **Verificación de Build**
|
||||
- Ejecutar el comando de build para este proyecto
|
||||
- Si falla, reportar los errores y DETENER
|
||||
|
||||
2. **Verificación de Tipos**
|
||||
- Ejecutar TypeScript/verificador de tipos
|
||||
- Reportar todos los errores con archivo:línea
|
||||
|
||||
3. **Verificación de Lint**
|
||||
- Ejecutar el linter
|
||||
- Reportar advertencias y errores
|
||||
|
||||
4. **Suite de Pruebas**
|
||||
- Ejecutar todas las pruebas
|
||||
- Reportar cantidad de pasadas/fallidas
|
||||
- Reportar porcentaje de cobertura
|
||||
|
||||
5. **Auditoría de console.log**
|
||||
- Buscar console.log en los archivos fuente
|
||||
- Reportar las ubicaciones
|
||||
|
||||
6. **Estado de Git**
|
||||
- Mostrar cambios no confirmados
|
||||
- Mostrar archivos modificados desde el último commit
|
||||
|
||||
## Salida
|
||||
|
||||
Generar un reporte de verificación resumido:
|
||||
|
||||
```
|
||||
VERIFICACIÓN: [PASÓ/FALLÓ]
|
||||
|
||||
Build: [OK/FALLÓ]
|
||||
Tipos: [OK/X errores]
|
||||
Lint: [OK/X problemas]
|
||||
Pruebas: [X/Y pasaron, Z% cobertura]
|
||||
Secretos: [OK/X encontrados]
|
||||
Logs: [OK/X console.log]
|
||||
|
||||
Listo para PR: [SÍ/NO]
|
||||
```
|
||||
|
||||
Si hay algún problema crítico, listarlos con sugerencias de corrección.
|
||||
|
||||
## Argumentos
|
||||
|
||||
$ARGUMENTS puede ser:
|
||||
- `quick` - Solo build + tipos
|
||||
- `full` - Todas las verificaciones (por defecto)
|
||||
- `pre-commit` - Verificaciones relevantes para commits
|
||||
- `pre-pr` - Escaneo de seguridad más verificaciones completas
|
||||
Reference in New Issue
Block a user