merge: quick/install-commands — agregar commands a repo e instalación

2026-04-09 23:27:15 +02:00
parent 9da1660a59 be97d03c97
commit 3d77f4a5d2
29 changed files with 1044 additions and 2831 deletions
@@ -0,0 +1,154 @@
 # Command: create issue
 Crea un issue nuevo en `dev/issues/` siguiendo **estrictamente** la regla `create_issue.md`. Si el issue es grande, lo desglosa automaticamente en sub-issues con feature flags.
 ## Inputs
 Se necesitan los datos del issue. Si no se proporcionan, preguntar.
 - `titulo`: titulo corto y descriptivo (ej: "Hot reload de configuracion")
 - `descripcion`: objetivo/descripcion de lo que se quiere lograr
 - `dependencias` (opcional): issues de los que depende (ej: "Requiere issue 0010")
 ## Flujo obligatorio
 ### 1. Determinar el numero del issue
 Buscar el numero mas alto en `dev/issues/` y `dev/issues/completed/` y usar el siguiente.
 Formato: 4 digitos con ceros a la izquierda (`0023`, `0024`, etc.).
 ```bash
 ls dev/issues/ dev/issues/completed/ | grep -oP '^\d{4}' | sort -rn | head -1
 ```
 ### 2. Generar slug
 A partir del titulo:
 - Lowercase
 - Palabras separadas por guiones
 - Conciso (2-4 palabras)
 - Ejemplo: "Hot reload de configuracion" → `hot-reload`
 ### 3. Evaluar tamano del issue
 Antes de escribir el issue, analizar el alcance y determinar si cabe en **una sola rama corta (horas)**.
 **Criterios para desglosar en sub-issues:**
 - Toca mas de 2 capas del patron (pkg/ + shell/ + agents/ + tools/)
 - Requiere mas de ~3 fases de implementacion
 - El usuario lo indica explicitamente
 - La descripcion implica multiples componentes independientes
 **Si es un issue simple** (cabe en una rama):
 - Crear un solo archivo `dev/issues/<NNNN>-<slug>.md`
 - Seguir directo al paso 4
 **Si es un issue grande** (necesita desglose):
 - Crear el issue principal `dev/issues/<NNNN>-<slug>.md` con seccion `## Desglose multi-issue`
 - Crear cada sub-issue como `dev/issues/<NNNN><letra>-<sub-slug>.md` (ej: `0023a-types`, `0023b-client`)
 - Cada sub-issue es autocontenido: debe compilar, pasar tests, no romper master
 - Agregar feature flag en la descripcion del issue principal
 - Registrar todos los sub-issues en `dev/issues/README.md`
 ### 4. Crear el issue desde el template
 Copiar `.claude/templates/issue.md` y rellenar **todas** las secciones:
 - **Objetivo**: 1-3 frases claras
 - **Contexto**: que existe, que falta, dependencias
 - **Arquitectura**: archivos afectados (marcar `NEW` los nuevos). Explicar que va en `pkg/` (puro) vs `shell/` (impuro)
 - **Tareas**: fases con tareas numeradas (`1.1`, `1.2`, etc.). Cada tarea concreta y verificable. Siempre incluir fase de tests y fase de cleanup/docs
 - **Ejemplo de uso**: flujo concreto
 - **Decisiones de diseno**: justificaciones clave
 - **Prerequisitos**: que debe existir antes
 - **Riesgos**: problemas potenciales y mitigacion
 ### 5. Para issues multi-issue — contenido adicional
 En el issue principal, agregar despues de las tareas:
 ```markdown
 ## Desglose multi-issue
 Este issue se implementa en sub-issues independientes, cada uno en su propia rama.
 | Sub-issue | Rama | Alcance | Estado |
 |-----------|------|---------|--------|
 | <NNNN>a-<slug> | issue/<NNNN>a-<slug> | <que cubre> | pendiente |
 | <NNNN>b-<slug> | issue/<NNNN>b-<slug> | <que cubre> | pendiente |
 | ...
 ### Feature flag
 Nombre: `<nombre-del-flag>`
 Se activa en el ultimo sub-issue cuando todo esta integrado.
 ### Progreso por tarea
 - [ ] **1.1** <tarea> — sub-issue <NNNN>a
 - [ ] **1.2** <tarea> — sub-issue <NNNN>a
 - [ ] **2.1** <tarea> — sub-issue <NNNN>b
 ...
 ```
 Cada sub-issue individual debe tener su propio archivo con:
 - Objetivo especifico del sub-issue
 - Tareas que le corresponden del issue principal
 - Nota de que es parte de un issue mayor
 ### 6. Registrar feature flag (solo multi-issue)
 Actualizar `dev/feature_flags.json`:
 ```json
 {
  "<nombre-del-flag>": {
    "enabled": false,
    "issue": "<NNNN>",
    "description": "<descripcion breve>",
    "added": "<YYYY-MM-DD>"
  }
 }
 ```
 ### 7. Actualizar el indice
 En `dev/issues/README.md`, agregar filas al final de la tabla.
 **Issue simple:**
 ```markdown
 | <N> | <Titulo> | [<NNNN>-<slug>.md](<NNNN>-<slug>.md) | pendiente |
 ```
 **Issue multi-issue (agregar fila por cada sub-issue tambien):**
 ```markdown
 | <N>  | <Titulo>           | [<NNNN>-<slug>.md](<NNNN>-<slug>.md)   | pendiente |
 | <N>a | <Titulo> (parte a) | [<NNNN>a-<slug>.md](<NNNN>a-<slug>.md) | pendiente |
 | <N>b | <Titulo> (parte b) | [<NNNN>b-<slug>.md](<NNNN>b-<slug>.md) | pendiente |
 ```
 ### 8. Verificar
 - [ ] Archivo(s) creado(s) en `dev/issues/`
 - [ ] Todas las secciones del template rellenadas
 - [ ] Fila(s) agregada(s) en `dev/issues/README.md`
 - [ ] Numero de issue es consecutivo (sin saltos ni duplicados)
 - [ ] Si es multi-issue: sub-issues creados, feature flag en `dev/feature_flags.json`, seccion de desglose en issue principal
 ### 9. Reportar al usuario
 Mostrar resumen:
 - Numero y titulo del issue
 - Si fue desglosado: listar sub-issues con su alcance
 - Recordar: usar `/fix-issue <NNNN>` (o `/fix-issue <NNNN>a`, `<NNNN>b`, etc.) para implementar
 ## Reglas criticas
 - Seguir `create_issue.md` de forma estricta
 - **Patron pure core / impure shell**: toda feature debe explicar que va en `pkg/` vs `shell/`
 - **Tareas atomicas**: cada tarea debe ser implementable de forma independiente
 - **Numeracion continua**: nunca reusar numeros
 - **Estado**: issues nuevos siempre `pendiente`
 - **Issues grandes**: desglosar en sub-issues con feature flags, nunca dejar una rama abierta por dias
 - **Feature flag != WIP**: un flag protege codigo terminado y testeado, no codigo a medias
 - **No commitear**: este comando solo crea archivos en `dev/issues/`. No hace commits ni crea ramas
@@ -0,0 +1,96 @@
 # Command: fix issue
 Ejecuta de punta a punta el flujo de implementacion/cierre de un issue siguiendo **estrictamente** la regla `fix_issue.md`.
 ## Inputs
 Se necesita el issue objetivo. Si no se proporciona, preguntar.
 - `issue`: numero o nombre (ej: `0010` o `0010-access-control`)
 ## Flujo obligatorio
 1. Resolver el issue objetivo:
 - Si viene solo numero (`0010`), buscar `dev/issues/0010-*.md`.
 - Si viene slug completo (`0010-access-control`), usar `dev/issues/0010-access-control.md`.
 - Si no existe en `dev/issues/`, **STOP** e informar al usuario.
 - Si ya esta en `dev/issues/completed/`, **STOP** e informar al usuario.
 2. Leer completo el issue y extraer:
 - objetivo
 - tareas/fases
 - arquitectura y limites (pure core / impure shell)
 3. Crear rama de trabajo (inline, sin invocar `/git-branch`):
 Verificar la rama actual:
 ```bash
 git branch --show-current
 ```
 - Si ya estamos en `issue/<NNNN>-<slug>` que coincide con el issue → continuar directamente a paso 4.
 - Si estamos en `master` o cualquier otra rama → crear la rama:
 ```bash
 git checkout master
 git pull --rebase
 git checkout -b issue/<NNNN>-<slug>
 ```
 Nunca trabajar directamente en `master`.
 4. Planificar con `TodoWrite`:
 - Crear plan basado en las tareas del issue.
 - Respetar el orden de fases.
 - Incluir siempre una tarea de tests.
 5. Implementar el issue completo:
 - Ejecutar tareas en orden.
 - Respetar pure core / impure shell (`pkg/` puro, `shell/` impuro).
 - Compilar frecuentemente: `go build -tags goolm ./...`.
 - Marcar progreso en `TodoWrite` al completar cada bloque.
 6. Tests obligatorios:
 ```bash
 go test -tags goolm ./...
 ```
 - Si falla, corregir antes de continuar.
 - No cerrar el issue sin tests pasando.
 7. Feature flags (si aplica):
 - Evaluar si es feature multi-issue o despliegue gradual.
 - Si aplica, actualizar `dev/feature_flags.json` en el commit correspondiente.
 - No usar flags para esconder codigo incompleto.
 8. Cerrar el issue al terminar:
 ```bash
 mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
 ```
 Actualizar `dev/issues/README.md`:
 - Link a `completed/<NNNN>-<slug>.md`
 - Estado a `completado`
 9. Integrar/publicar con `/git-push`:
 ```text
 /git-push
 ```
 ## Reglas criticas
 - Seguir `fix_issue.md` de forma estricta.
 - No saltear tareas del issue.
 - No hacer commits WIP.
 - Commits atomicos por bloque logico (`feat:`, `fix:`, `test:`, `docs:`, `refactor:`, `chore:`).
 - Siempre usar `-tags goolm` en build/test.
@@ -0,0 +1,86 @@
 # Command: git branch (TBD)
 Crea una rama de trabajo. **Nunca trabajar directamente en master.**
 Soporta dos tipos de rama:
 - `issue/<NNNN>-<slug>` — para implementar un issue existente de `dev/issues/`
 - `quick/<slug>` — para cambios pequeños sin issue asociado (fixes, config, docs, etc.)
 ## Inputs
 Preguntar al usuario si el cambio esta asociado a un issue o no.
 ### Si es un issue:
 - `issue_number`: numero de 4 digitos (e.g. `0020`)
 - `slug`: nombre corto separado por guiones (e.g. `hot-reload`)
 ### Si es un cambio rapido (sin issue):
 - `slug`: nombre corto descriptivo separado por guiones (e.g. `fix-typo-readme`)
 ## Flujo obligatorio
 1. Verificar que estamos en master y limpio:
 ```bash
 git branch --show-current
 git status --short
 ```
 Si no estamos en master, cambiar primero:
 ```bash
 git checkout master
 ```
 Si hay cambios sin commitear, **avisar al usuario** y no continuar hasta resolver.
 2. Actualizar master desde remoto:
 ```bash
 git pull --rebase
 ```
 3. Crear la rama y cambiar a ella:
 **Para issues:**
 ```bash
 git checkout -b issue/<issue_number>-<slug>
 ```
 Ejemplo: `git checkout -b issue/0013-hot-reload`
 **Para cambios rapidos:**
 ```bash
 git checkout -b quick/<slug>
 ```
 Ejemplo: `git checkout -b quick/fix-typo-readme`
 4. Confirmar al usuario:
 ```
 Rama `<nombre-rama>` creada desde master actualizado.
 Puedes empezar a trabajar. Cuando termines, usa `/git-push` para integrar a master.
 ```
 ## Convenciones
 - **Formato de rama issue**: `issue/<NNNN>-<slug>` (siempre 4 digitos)
 - **Formato de rama quick**: `quick/<slug>` (sin numero)
 - **Ramas cortas**: idealmente horas, no dias
 - **Una rama por issue**: no mezclar issues en la misma rama
 - **Nunca pushear la rama al remoto**: el push se hace desde master despues del merge
 - **No rebase interactivo**: si los commits son limpios desde el inicio, no reescribir historia
 - **No commits WIP**: cada commit en la rama debe ser atomico y con mensaje real (ver convencion en `/git-push`)
 ## Features multi-issue
 Para features que no caben en una sola rama, usar sub-issues con sufijo letra:
 ```
 issue/0015a-telegram-types
 issue/0015b-telegram-client
 issue/0015c-telegram-listener
 issue/0015d-telegram-enable
 ```
 Cada sub-rama sigue el mismo flujo: crear → implementar → merge --no-ff → delete.
 El codigo parcial se protege con **feature flags** en `dev/feature_flags.json` (no con commits WIP).
@@ -0,0 +1,157 @@
 # Command: git push
 Integra cambios a master y publica. Soporta ramas `issue/*` y `quick/*`.
 ## Flujo obligatorio
 ### 1. Verificar rama actual y estado
 ```bash
 git branch --show-current
 git status --short
 ```
 #### Si estamos en una rama `issue/*` o `quick/*`
 Continuar directamente al paso 2.
 #### Si estamos en `master` con cambios pendientes
 Crear una rama automaticamente antes de continuar:
 1. Preguntar al usuario: **¿Este cambio esta asociado a un issue existente?**
 2. **Si es un issue**: pedir el numero y slug, crear rama `issue/<NNNN>-<slug>`.
 3. **Si NO es un issue**: pedir un slug descriptivo, crear rama `quick/<slug>`.
 ```bash
 # Para issues:
 git checkout -b issue/<NNNN>-<slug>
 # Para cambios rapidos:
 git checkout -b quick/<slug>
 ```
 4. Continuar al paso 2 con los cambios ya en la rama nueva.
 **IMPORTANTE**: No inventar numeros de issue. Solo usar `issue/` si el issue existe en `dev/issues/`.
 #### Si estamos en `master` sin cambios
 **STOP**: no hay nada que publicar.
 ### 2. Revisar cambios y crear commits por bloque
 ```bash
 git status --short
 git diff --stat
 git diff
 ```
 Crear commits **atomicos por bloque logico**. Cada commit agrupa cambios de la misma naturaleza:
 ```bash
 git add <archivos_del_bloque_1>
 git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol explicando que cambia, por que se hizo, impacto esperado y alcance del bloque."
 git add <archivos_del_bloque_2>
 git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol."
 ```
 **Reglas criticas de commits:**
 - **No WIP**: nunca commitear "wip", "tmp", "fix fix" ni codigo a medias. Cada commit debe ser atomico y completo.
 - **No mezclar tipos**: no combinar `feat:` + `test:` en un mismo commit. Separar por bloque logico.
 - **No squash**: los commits individuales se preservan en master via `--no-ff`. Usar `git log --first-parent master` para ver solo merge commits.
 - **No rebase interactivo**: si los commits ya son limpios, no reescribir historia.
 ### 3. Ejecutar tests
 **Obligatorio antes de mergear.** Si el proyecto tiene tests, ejecutarlos:
 ```bash
 go test -tags goolm ./...
 ```
 - Si los tests **fallan** → **STOP**: corregir antes de continuar. No mergear codigo roto.
 - Si los tests **pasan** → continuar al paso 4.
 - Si no hay tests aplicables (e.g. solo cambios de docs/config) → indicar al usuario y continuar.
 ### 4. Evaluar feature flags
 Feature flags se usan cuando el issue es **parte de una feature multi-issue** o el cambio tiene riesgo y necesita poder desactivarse. **Feature flag ≠ WIP** — un flag protege codigo terminado y testeado, no codigo a medias.
 Si se modifico `dev/feature_flags.json` o si los cambios son parte de una feature que se despliega en fases:
 1. Verificar que `dev/feature_flags.json` existe y esta actualizado.
 2. Confirmar que el flag correspondiente tiene el estado correcto (`enabled: true/false`).
 3. Incluir el archivo en el commit correspondiente (no crear commit separado solo para flags).
 Si el issue es autocontenido (se completa en esta rama), no necesita flag. Saltar este paso.
 ### 5. Actualizar master y hacer merge --no-ff
 ```bash
 git checkout master
 git pull --rebase
 git merge --no-ff <rama> -m "merge: <rama> — <titulo breve>"
 ```
 El merge commit debe tener formato:
 - Titulo: `merge: <rama> — <descripcion corta>`
 - Cuerpo (opcional): resumen de lo que entra
 Ejemplos:
 - `merge: issue/0021-threads-default-config — habilitar threads en agentes`
 - `merge: quick/fix-typo-readme — corregir typo en README`
 Si hay conflictos durante el merge:
 1. Resolver los conflictos
 2. `git add` los archivos resueltos
 3. `git commit` (sin -m, para mantener el mensaje de merge)
 ### 6. Push a remoto
 ```bash
 git push
 ```
 ### 7. Limpiar rama local
 ```bash
 git branch -d <rama>
 ```
 ### 8. Confirmar al usuario
 ```
 Rama `<rama>` integrada a master y publicada.
 Rama local eliminada.
 ```
 ## Convencion de commits
 - `feat:` nueva funcionalidad
 - `fix:` correccion de error
 - `refactor:` cambio estructural sin cambio funcional
 - `docs:` documentacion
 - `chore:` mantenimiento
 - `test:` tests nuevos o modificados
 - `merge:` commit de merge (generado por --no-ff)
 ## Regla de mensajes
 - El titulo (`-m` corto) debe resumir el bloque.
 - El cuerpo (`-m` largo) debe estar en espanol y explicar:
  - que se cambio,
  - por que se cambio,
  - que impacto tiene,
  - que no se toco.
 ## Checklist rapido
 - [ ] Todos los cambios estan commiteados en una rama `issue/*` o `quick/*`.
 - [ ] Se separaron cambios distintos en commits diferentes.
 - [ ] Cada commit tiene descripcion larga en espanol.
 - [ ] Tests ejecutados y pasando (o no aplican).
 - [ ] Feature flags evaluados (o no aplican).
 - [ ] `git merge --no-ff` ejecutado desde master.
 - [ ] `git push` ejecutado correctamente.
 - [ ] Rama local eliminada.
@@ -1,75 +0,0 @@
 ---
 name: auto-create
 description: Crea un issue nuevo e integra automáticamente SIN pedir confirmación
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # auto-create
 Crea un issue nuevo y lo integra automáticamente **sin pedir confirmación**.
 ## Sintaxis
 ```bash
 /auto-create
 ```
 ## Diferencia con /create-issue
 Este comando NO pausa para confirmación. Solicita datos pero integra automáticamente.
 ## Flujo
 ### 1-7. Crear issue (igual que /create-issue)
 1. Determinar número
 2. Solicitar inputs (titulo, descripción)
 3. Generar slug
 4. Evaluar tamaño
 5. Crear desde template
 6. Feature flag (si aplica)
 7. Actualizar índice
 **Sin confirmación** - continuar directamente.
 ### 8. Integración automática
 ```bash
 git checkout master
 git pull --rebase
 git checkout -b quick/create-issue-<NNNN>
 # Commit
 git add dev/issues/<NNNN>*.md dev/issues/README.md
 git commit -m "docs: crear issue <NNNN>-<slug>"
 # Si multi-issue, commit de feature flag
 git add dev/feature_flags.json
 git commit -m "feat: agregar feature flag <nombre>"
 # Tests (si aplican)
 go test -tags goolm ./...
 # Merge
 git checkout master
 git merge --no-ff quick/create-issue-<NNNN>
 git push
 git branch -d quick/create-issue-<NNNN>
 ```
 ### 9. Mostrar resultado
 ```
 Issue <NNNN>-<slug> creado e integrado automáticamente
 Para implementar:
  /fix-issue <NNNN>
 ```
 ## Convenciones
 - Sin confirmación
 - Mismo formato que /create-issue
 - Trunk-based con rama quick/
@@ -1,75 +0,0 @@
 ---
 name: auto-fix
 description: Implementa un issue completo automáticamente SIN pedir confirmación
 argument-hint: <NNNN>
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit, TodoWrite
 ---
 # auto-fix
 Implementa un issue completo automáticamente **sin pedir confirmación** antes de integrar.
 ## Sintaxis
 ```bash
 /auto-fix <NNNN>
 /auto-fix <NNNN>-<slug>
 ```
 ## Diferencia con /fix-issue
 Este comando NO pausa para confirmación. Ejecuta todo el flujo automáticamente.
 **Usar cuando:** estés completamente seguro de que el issue puede implementarse automáticamente.
 ## Flujo
 ### 1-8. Implementar (igual que /fix-issue)
 1. Resolver issue objetivo
 2. Leer issue completo
 3. Crear rama `issue/<NNNN>-<slug>`
 4. Planificar con TodoWrite
 5. Implementar completo
 6. Tests obligatorios
 7. Feature flags (si aplica)
 8. Cerrar issue
 **Sin confirmación** - continuar directamente.
 ### 9. Integración automática
 ```bash
 git checkout master
 git pull --rebase
 go test -tags goolm ./...  # verificación final
 git merge --no-ff issue/<NNNN>-<slug> -m "merge: issue/<NNNN>-<slug>"
 git push
 git branch -d issue/<NNNN>-<slug>
 ```
 ### 10. Mostrar resultado
 ```
 Issue <NNNN> completado e integrado automáticamente
 Commits integrados: N
 Tests: pasando
 Issue: movido a completed/
 NOTA: Integración automática sin confirmación.
 ```
 ## Convenciones
 - Sin confirmación (diferencia clave)
 - Misma calidad que /fix-issue
 - STOP si tests fallan
 ## Reglas
 - NO pedir confirmación
 - MISMA calidad que /fix-issue
 - STOP si tests fallan (no integrar código roto)
@@ -1,74 +0,0 @@
 ---
 name: cleanup-worktrees
 description: Limpia worktrees y ramas locales después de merge
 argument-hint: <issue_number> | --all
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read
 ---
 # cleanup-worktrees
 Elimina worktrees y sus ramas locales asociadas después de haber sido mergeadas.
 ## Sintaxis
 ```bash
 /cleanup-worktrees <NNNN>   # Limpiar worktree específico
 /cleanup-worktrees --all     # Limpiar todos
 ```
 ## Flujo
 ### 1. Validar argumentos
 - Número de issue (4 dígitos): limpiar ese worktree
 - `--all`: limpiar todos en `worktrees/`
 ### 2. Determinar worktrees a limpiar
 ```bash
 # Para issue específica
 WORKTREE_PATH="worktrees/issue-$ISSUE_NUM"
 # Para --all
 find worktrees -maxdepth 1 -type d -name "issue-*"
 ```
 ### 3. Confirmar con usuario
 ```
 Se eliminarán:
  - worktrees/issue-0003 (rama: quick/fix-issue-0003)
 ¿Continuar? (y/N):
 ```
 ### 4. Limpiar cada worktree
 Para cada uno:
 1. Verificar si rama fue mergeada
 2. Si NO mergeada: advertir y preguntar
 3. Eliminar worktree: `git worktree remove <path> --force`
 4. Eliminar rama: `git branch -D <branch>`
 ### 5. Reportar resultado
 ```
 Limpieza completada
 Worktrees restantes:
  (ninguno)
 ```
 ## Convenciones
 - Nomenclatura worktrees: `worktrees/issue-NNNN`
 - Nomenclatura ramas: `quick/fix-issue-NNNN`
 - Confirmación interactiva siempre
 ## Reglas
 - SIEMPRE verificar merge antes de eliminar
 - NUNCA eliminar sin confirmación
 - SIEMPRE usar --force en worktree remove
@@ -1,439 +0,0 @@
 ---
 name: create-agent
 description: Crea un nuevo agente especializado en .claude/agents/ con su SKILL.md y estructura completa
 argument-hint: [nombre]
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit, AskUserQuestion
 ---
 # create-agent
 Crea un nuevo agente especializado en `.claude/agents/` con archivo `SKILL.md` obligatorio siguiendo la estructura oficial de Claude Code.
 ## Sintaxis
 ```bash
 /create-agent [nombre]
 /create-agent api-client
 /create-agent cloud-deploy
 ```
 ## Precondiciones
 - [ ] Carpeta `.claude/agents/` existe
 - [ ] No existe agente con el mismo nombre
 - [ ] Nombre cumple convenciones (minúsculas, guiones)
 ## Flujo
 ### 1. Validar nombre
 - Solo minúsculas, números y guiones
 - No nombres reservados (help, clear, exit)
 - Máximo 64 caracteres
 ```bash
 ls -d .claude/agents/*/ 2>/dev/null | xargs -n1 basename | grep -E "^${nombre}$"
 ```
 Si existe, STOP.
 ### 2. Solicitar inputs usando AskUserQuestion
 Usar `AskUserQuestion` para obtener:
 #### Input 1: Información básica
 - **nombre**: minúsculas y guiones (ej: `api-client`)
 - **descripcion**: qué hace el agente y cuándo invocarlo (1-2 frases claras)
 #### Input 2: Configuración técnica
 - **model**: Modelo Claude a usar
  - `sonnet` (default): Balance costo/capacidad
  - `opus`: Tareas complejas que requieren máximo razonamiento
  - `haiku`: Tareas simples y rápidas
 - **tools**: Herramientas necesarias (separadas por coma)
  - Default: `Read, Write, Bash, Glob, Grep, Edit`
  - Opcionales: `WebFetch, WebSearch, NotebookEdit`
 #### Input 3: Configuración de proyecto
 - **gestiona_repo**: ¿Gestiona un repositorio local?
  - `si`: Crear carpeta en `~/.local_agentes/`
  - `no`: Solo definición de agente
 - **usa_mcp**: ¿Usa MCP servers? (gitea, sqlite, etc)
  - `si`: Solicitar configuración de MCP
  - `no`: Omitir mcpServers
 #### Input 4: MCP Servers (si usa_mcp = si)
 Preguntar qué MCP servers necesita:
 - `gitea`: Gestión de repositorios Gitea
 - `sqlite`: Bases de datos SQLite
 - `filesystem`: Sistema de archivos
 - `otro`: Configuración personalizada
 #### Input 5: Documentación
 - **rol**: Rol del agente (ej: "Eres un experto en...")
 - **capacidades**: Lista de capacidades principales
 - **flujo_trabajo**: Descripción del flujo de trabajo típico
 - **ejemplos_uso**: Ejemplos de cuándo invocar al agente
 ### 3. Crear carpeta del agente
 ```bash
 mkdir -p .claude/agents/${nombre}
 ```
 ### 4. Crear carpeta local (si gestiona_repo = si)
 ```bash
 mkdir -p ~/.local_agentes/${nombre}
 ```
 ### 5. Generar frontmatter YAML
 Estructura base:
 ```yaml
 ---
 name: ${nombre}
 description: ${descripcion}
 model: ${model}
 tools: ${tools}
 mcpServers:  # Solo si usa_mcp = si
  - ${mcp_config}
 ---
 ```
 ### 6. Generar SKILL.md completo
 Template oficial de agente:
 ```markdown
 ---
 name: ${nombre}
 description: ${descripcion}
 model: ${model}
 tools: ${tools}
 ${mcp_servers_section}
 ---
 # Agente ${nombre}
 ${rol}
 ## Tu entorno
 ${descripcion_entorno}
 ## Capacidades principales
 ${capacidades}
 ## Flujo de trabajo
 ${flujo_trabajo}
 ## Templates disponibles
 ${templates_codigo}
 ## Integración con otros agentes
 ${integracion}
 ## Ejemplos de uso
 ${ejemplos_uso}
 ## Comandos útiles
 ${comandos}
 ## Notas y convenciones
 ${notas}
 ```
 ### 7. Templates de MCP Servers
 #### Gitea MCP
 ```yaml
 mcpServers:
  - gitea:
      type: stdio
      command: gitea-mcp
      args:
        - -t
        - stdio
        - --host
        - "${GITEA_URL}"
        - --token
        - "${GITEA_TOKEN}"
 ```
 #### SQLite MCP
 ```yaml
 mcpServers:
  - sqlite:
      type: stdio
      command: sqlite-mcp
      args:
        - --db
        - "${DB_PATH}"
 ```
 #### Filesystem MCP
 ```yaml
 mcpServers:
  - filesystem:
      type: stdio
      command: mcp-server-filesystem
      args:
        - --allowed-directories
        - "${ALLOWED_DIR}"
 ```
 ### 8. Mostrar y confirmar
 ```
 Agente creado: ${nombre}
 Ubicación: .claude/agents/${nombre}/SKILL.md
 ${carpeta_local ? "Carpeta local: ~/.local_agentes/" + nombre : ""}
 Configuración:
 - Model: ${model}
 - Tools: ${tools}
 - MCP: ${usa_mcp ? "Sí" : "No"}
 - Repositorio local: ${gestiona_repo ? "Sí" : "No"}
 ¿Te parece bien?
 - Si correcto: commit e integrar automáticamente
 - Si ajustes: edita manualmente antes de integrar
 ```
 ### 9. Crear README.md en carpeta local (si gestiona_repo = si)
 ```bash
 cat > ~/.local_agentes/${nombre}/README.md <<EOF
 # ${nombre}
 ${descripcion}
 ## Estructura del proyecto
 \`\`\`
 ~/.local_agentes/${nombre}/
 ├── README.md
 ├── CLAUDE.md           # Instrucciones para Claude
 └── ...                 # Archivos del proyecto
 \`\`\`
 ## Sincronización con Gitea
 \`\`\`bash
 cd ~/.local_agentes/${nombre}
 git remote add origin \${GITEA_URL}/\${user}/${nombre}.git
 git push -u origin main
 \`\`\`
 ## Uso
 Invocar con:
 \`\`\`
 Hablar con el agente ${nombre} para [tarea]
 \`\`\`
 EOF
 ```
 ### 10. Ejecutar /git-push
 Si confirma, crear rama `quick/create-agent-${nombre}` e integrar.
 ### 11. Verificar disponibilidad
 ```
 Agente "${nombre}" creado e integrado
 El agente está disponible en:
  .claude/agents/${nombre}/SKILL.md
 ${gestiona_repo ? "Carpeta de trabajo:\n  ~/.local_agentes/" + nombre : ""}
 Para usar, solicita al usuario:
  "Trabajar con el agente ${nombre} para [tarea]"
 Configuración:
 - Model: ${model}
 - Tools: ${tools}
 - MCP Servers: ${usa_mcp ? "Sí" : "No"}
 ```
 ## Campos del frontmatter de agentes
 | Campo | Descripción | Requerido |
 |-------|-------------|-----------|
 | name | Nombre del agente | Sí |
 | description | Qué hace y cuándo invocarlo | Sí |
 | model | Model Claude (sonnet, opus, haiku) | Sí |
 | tools | Herramientas disponibles | Sí |
 | mcpServers | Servidores MCP (opcional) | No |
 ## Estructura de documentación de agentes
 Seguir este orden en el contenido Markdown:
 1. **Título y rol**: Descripción del rol del agente
 2. **Tu entorno**: Dónde trabaja, qué repositorios gestiona
 3. **Capacidades principales**: Lista de lo que puede hacer
 4. **Flujo de trabajo**: Cómo abordar tareas típicas
 5. **Templates disponibles**: Código de ejemplo
 6. **Integración con otros agentes**: Cómo colabora con otros
 7. **Ejemplos de uso**: Cuándo invocar al agente
 8. **Comandos útiles**: Comandos CLI relevantes
 9. **Notas y convenciones**: Reglas y mejores prácticas
 ## Convenciones
 - Nombres descriptivos con guiones (ej: `api-client`, `cloud-deploy`)
 - Descripciones claras para invocación automática por Claude
 - Un agente por dominio/especialización
 - Documentación completa con ejemplos prácticos
 - Templates de código cuando sea aplicable
 ## Diferencia entre Agentes y Skills
 | Característica | Agente | Skill |
 |----------------|--------|-------|
 | Ubicación | `.claude/agents/` | `.claude/skills/` |
 | Propósito | Experto especializado | Automatización/herramienta |
 | Invocación | Claude decide cuándo | Usuario con `/nombre` |
 | Contenido | Conocimiento de dominio | Flujo de trabajo |
 | Ejemplo | `backend-lib`, `docker` | `git-push`, `create-issue` |
 ## Ejemplos de agentes
 ### Agente simple (sin repo ni MCP)
 ```yaml
 ---
 name: code-review
 description: Agente para revisar código y sugerir mejoras
 model: sonnet
 tools: Read, Grep, Glob
 ---
 # Agente Code Review
 Eres un experto en revisión de código...
 ```
 ### Agente complejo (con repo y MCP)
 ```yaml
 ---
 name: api-client
 description: Agente para generar clientes API desde especificaciones OpenAPI
 model: sonnet
 tools: Read, Write, Bash, Glob, Grep, Edit
 mcpServers:
  - gitea:
      type: stdio
      command: gitea-mcp
      args:
        - -t
        - stdio
        - --host
        - "${GITEA_URL}"
        - --token
        - "${GITEA_TOKEN}"
 ---
 # Agente API Client
 Eres un experto en generación de clientes API...
 ## Tu entorno
 - **Repositorio**: `Bl4cksmith/api-clients` (Gitea)
 - **Carpeta local**: `~/.local_agentes/api-client`
 - **Stack**: TypeScript, Go, Python
 ...
 ```
 ## Reglas
 - Validar nombre antes de crear
 - SKILL.md es obligatorio
 - Confirmación antes de integrar
 - Crear carpeta local solo si gestiona_repo = si
 - MCP servers solo si usa_mcp = si
 - Documentación completa y con ejemplos
 ## Integración con otros agentes
 ### Con gitea
 ```bash
 # Crear repositorio para el agente (si gestiona_repo = si)
 cd ~/.local_agentes/${nombre}
 git init
 git add .
 git commit -m "Initial commit"
 # Usar agente gitea para crear repo y push
 ```
 ### Con backend-lib / frontend-lib
 ```markdown
 # En SKILL.md del nuevo agente, documentar integración:
 ## Integración con otros agentes
 ### Con backend-lib (DevFactory)
 - Usar DevFactory para estructuras funcionales Go
 - Integrar via go.work
 ### Con frontend-lib
 - Usar Frontend_Library para componentes React
 - Integrar via pnpm link
 ```
 ## Variables dinámicas
 | Variable | Descripción |
 |----------|-------------|
 | ${nombre} | Nombre del agente |
 | ${descripcion} | Descripción del agente |
 | ${model} | Model Claude |
 | ${tools} | Herramientas disponibles |
 | ${CLAUDE_SKILL_DIR} | Ruta del skill |
 ## Flujo completo de ejemplo
 ```bash
 # Usuario invoca
 /create-agent api-client
 # Skill valida nombre
 ✓ Nombre válido
 # Skill pregunta configuración con AskUserQuestion
 ? Descripción: Agente para generar clientes API desde OpenAPI
 ? Model: sonnet
 ? Tools: Read, Write, Bash, Glob, Grep, Edit
 ? ¿Gestiona repositorio?: Sí
 ? ¿Usa MCP?: Sí
 ? MCP servers: gitea
 # Skill crea estructura
 ✓ Carpeta creada: .claude/agents/api-client/
 ✓ Carpeta local creada: ~/.local_agentes/api-client/
 ✓ SKILL.md generado
 ✓ README.md generado
 # Skill confirma
 Agente "api-client" creado
 # Skill integra con git
 ✓ Rama: quick/create-agent-api-client
 ✓ Commit: "feat: crear agente api-client"
 ✓ Push exitoso
 ```
@@ -1,99 +0,0 @@
 ---
 name: create-issue
 description: Crea un issue nuevo en dev/issues/ con confirmación del usuario
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # create-issue
 Crea un issue nuevo con estructura completa. Si es grande, lo desglosa en sub-issues con feature flags.
 ## Sintaxis
 ```bash
 /create-issue
 ```
 ## Precondiciones
 - [ ] Directorio `dev/issues/` existe
 - [ ] Template `.claude/templates/issue.md` existe
 ## Flujo
 ### 1. Determinar número del issue
 ```bash
 ls dev/issues/ dev/issues/completed/ | grep -oP '^\d{4}' | sort -rn | head -1
 ```
 Próximo issue = número_más_alto + 1 (formato 4 dígitos)
 ### 2. Solicitar inputs
 - `titulo`: título corto y descriptivo
 - `descripcion`: objetivo de lo que se quiere lograr
 - `dependencias` (opcional): issues de los que depende
 ### 3. Generar slug
 Título → lowercase → palabras separadas por guiones → 2-4 palabras
 ### 4. Evaluar tamaño
 **Criterios para sub-issues:**
 - Toca más de 2 capas (core/ + shell/ + app/)
 - Requiere más de 3 fases
 - El usuario lo indica
 **Issue simple:** crear un archivo `dev/issues/<NNNN>-<slug>.md`
 **Issue grande:** crear SOLO sub-issues `<NNNN>a-`, `<NNNN>b-`, etc.
 ### 5. Crear desde template
 Usar template en `${CLAUDE_SKILL_DIR}/issue.md` y rellenar todas las secciones:
 - Metadata, Objetivo, Contexto
 - Arquitectura, Patrón pure/impure
 - Tareas, Ejemplo de uso
 - Criterios de aceptación
 ### 6. Feature flag (solo multi-issue)
 Actualizar `dev/feature_flags.json`:
 ```json
 {
  "<nombre-flag>": {
    "enabled": false,
    "issue": "<NNNN>",
    "description": "..."
  }
 }
 ```
 ### 7. Actualizar índice
 En `dev/issues/README.md` agregar fila(s).
 ### 8. Mostrar y confirmar
 ```
 Issue creado: <NNNN>-<slug>
 ¿Te parece bien?
 - Si es correcto: commit y push automáticamente
 - Si necesitas ajustes: edita manualmente
 ```
 ### 9. Ejecutar /git-push automáticamente
 Si confirma, crear rama `quick/create-issue-<NNNN>` y ejecutar flujo git.
 ## Convenciones
 - Numeración continua sin saltos
 - Estado inicial: pendiente
 - Issues cortos (horas por rama)
 - Sub-issues autocontenidos
@@ -1,128 +0,0 @@
 # NNNN — [Título de la Issue]
 ## Metadata
 | Campo | Valor |
 |-------|-------|
 | **ID** | NNNN |
 | **Estado** | 🟡 pendiente / 🔵 en progreso / ✅ completado / 🔴 bloqueado |
 | **Prioridad** | alta / media / baja |
 | **Tipo** | feature / bugfix / refactor / docs / infrastructure |
 ## Dependencias
 <!-- Issues que DEBEN estar completadas antes de empezar esta -->
 | ID | Título | Estado | Requerido |
 |----|--------|--------|-----------|
 | 0001 | Actualizar nombre del módulo | ✅ | Sí |
 | 0002 | Implementar core/ | ✅ | Sí |
 **Bloqueada por:** `#0001, #0002`
 **Desbloquea:** `#0006, #0007`
 > **⚠️ VALIDACIÓN AUTOMÁTICA**: Esta issue no puede iniciarse hasta que todas las dependencias estén en estado `✅ completado`.
 ---
 ## Objetivo
 [Descripción concisa de qué se quiere lograr en 1-3 oraciones]
 ## Contexto
 - [Punto de contexto 1]
 - [Punto de contexto 2]
 - [Referencias a otras issues o decisiones previas]
 ## Arquitectura
 ```
 [Estructura de archivos afectados]
 dir/
 ├── file1.go    — Descripción
 ├── file2.go    — NEW: Nuevo archivo
 └── file3.go    — MODIFY: Modificación
 ```
 ### Patrón pure core / impure shell
 - `core/` — [Qué funciones puras se agregan]
 - `shell/` — [Qué operaciones I/O se implementan]
 - `app/` — [Cómo se orquesta]
 ## Tareas
 ### Fase 1: [Nombre de fase]
 - [ ] **1.1** [Descripción detallada de tarea]
 - [ ] **1.2** [Otra tarea]
 ### Fase 2: [Otra fase]
 - [ ] **2.1** [Tarea]
 - [ ] **2.2** [Tarea]
 ### Fase N: Cleanup y docs
 - [ ] Actualizar `README.md` con cambios relevantes
 - [ ] Actualizar `CLAUDE.md` si hay cambios arquitectónicos
 - [ ] Ejecutar `go mod tidy`
 - [ ] Ejecutar `go test ./...`
 - [ ] Actualizar issue en `dev/issues/README.md`
 ---
 ## Ejemplo de uso
 ```bash
 # Comandos de ejemplo
 comando ejemplo arg1 arg2
 # Output esperado:
 # ✓ Success message
 ```
 ```go
 // Código de ejemplo si aplica
 package example
 func Example() {}
 ```
 ## Decisiones de diseño
 - **Decisión 1**: Razón y trade-offs
 - **Decisión 2**: Alternativas consideradas y por qué se eligió esta
 ## Prerequisitos
 - Issue #NNNN completado
 - Herramienta X instalada
 - Configuración Y realizada
 ## Riesgos
 - **Riesgo 1**: Descripción del riesgo. **Mitigación**: Cómo se mitigará
 - **Riesgo 2**: Otro riesgo. **Mitigación**: Plan de mitigación
 ## Criterios de aceptación
 - [ ] Todos los tests pasan
 - [ ] Feature flag agregado en `feature_flags.json`
 - [ ] Documentación actualizada
 - [ ] Code review aprobado
 - [ ] Deployable a main
 ---
 ## Notas de implementación
 [Notas que surjan durante la implementación, decisiones tomadas, problemas encontrados]
 ## Referencias
 - [Link a documentación relevante]
 - [Link a PRs relacionados]
 - [Link a discusiones]
@@ -1,73 +0,0 @@
 ---
 name: create-repo
 description: Crea un nuevo subrepo en workspaces/ con estructura core/shell/app
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write
 ---
 # create-repo
 Crea un nuevo workspace (subrepo) con estructura estándar, repo en Gitea, y registro en BD.
 ## Prerequisitos
 - Variables: `GITEA_URL` y `GITEA_TOKEN`
 - Feature flag `workspace_commands` habilitado
 ## Flujo interactivo
 ### 1. Solicitar inputs
 1. **Nombre**: URL-safe (lowercase, alfanumérico, guiones)
 2. **Descripción**: texto libre
 3. **Tipo**: go, data, etl, api
 4. **¿Privado?**: s/n (default: n)
 ### 2. Mostrar resumen y confirmar
 ```
 Resumen:
  Nombre:     my-etl-pipeline
  Path local: ./workspaces/my-etl-pipeline
  Gitea:      https://gitea.../my-etl-pipeline
  Tipo:       etl
  Privado:    no
 ¿Crear repositorio? (s/n):
 ```
 ### 3. Ejecutar creación
 Usa `app.CreateWorkspaceCommand(config, params)`:
 1. Validar nombre
 2. Verificar que no existe
 3. Crear estructura core/shell/app/
 4. Escribir templates (go.mod, main.go, etc.)
 5. git init + configurar usuario
 6. Crear repo en Gitea
 7. Push inicial
 8. Registrar en SQLite
 **Rollback automático** si falla cualquier paso.
 ### 4. Mostrar resultado
 ```
 Workspace creado: ./workspaces/my-etl-pipeline
 Para trabajar:
  cd workspaces/my-etl-pipeline
 ```
 ## Validación de nombre
 - Solo letras, números y guiones
 - No empezar/terminar con guión
 - 2-100 caracteres
 ## Troubleshooting
 - "nombre inválido": usar solo lowercase, alfanumérico, guiones
 - "ya existe": verificar `ls workspaces/` o usar otro nombre
 - "error Gitea": verificar GITEA_TOKEN
@@ -1,112 +0,0 @@
 ---
 name: fix-issue
 description: Implementa un issue completo de punta a punta con confirmación
 argument-hint: <NNNN>
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit, TodoWrite
 ---
 # fix-issue
 Ejecuta el flujo completo de implementación/cierre de un issue: crear rama, implementar, testear, cerrar, confirmar, integrar.
 ## Sintaxis
 ```bash
 /fix-issue <NNNN>
 /fix-issue <NNNN>-<slug>
 ```
 ## Precondiciones
 - [ ] Directorio `dev/issues/` existe
 - [ ] Directorio `dev/issues/completed/` existe
 - [ ] Tests configurados
 - [ ] Working tree limpio
 ## Flujo
 ### 1. Resolver issue objetivo
 ```bash
 ls dev/issues/<NNNN>-*.md
 ```
 - Si no existe: STOP "Issue no encontrado"
 - Si ya completado: STOP "Issue ya completado"
 ### 2. Leer issue completo
 Extraer: objetivo, tareas, arquitectura, patrón pure/impure, tests.
 ### 3. Crear rama de trabajo
 ```bash
 git checkout master
 git pull --rebase
 git checkout -b issue/<NNNN>-<slug>
 ```
 ### 4. Planificar con TodoWrite
 Crear plan basado en tareas del issue.
 ### 5. Implementar completo
 Para cada tarea:
 1. Implementar siguiendo patrón pure core / impure shell
 2. Compilar frecuentemente: `go build -tags goolm ./...`
 3. Crear commits atómicos durante implementación
 ### 6. Tests obligatorios
 ```bash
 go test -tags goolm ./...
 ```
 - Pasan: continuar
 - Fallan: STOP y corregir
 ### 7. Feature flags (si aplica)
 Actualizar `dev/feature_flags.json` si es multi-issue.
 ### 8. Cerrar issue
 ```bash
 mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
 ```
 Actualizar índice en README.md.
 ### 9. Mostrar resumen y confirmar
 ```
 Issue <NNNN> completado
 Resumen:
 - N archivos modificados
 - N commits realizados
 - Tests: pasando
 ¿Integrar a master?
 ```
 ### 10. Ejecutar /git-push
 Si confirma, ejecutar flujo de integración.
 ## Convenciones
 - Implementar TODAS las tareas
 - Commits atómicos durante implementación
 - Tests obligatorios
 - Pure core / impure shell
 ## Reglas
 - NO saltear tareas
 - NO commits WIP
 - SIEMPRE tests antes de cerrar
 - Confirmación obligatoria antes de integrar
@@ -1,97 +0,0 @@
 ---
 name: git-branch
 description: Crea una rama de trabajo (issue/* o quick/*). Nunca trabajar directamente en master.
 argument-hint: <tipo> <args>
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read
 ---
 # git-branch
 Crea una rama de trabajo siguiendo trunk-based development. **Nunca trabajar directamente en master.**
 ## Sintaxis
 ```bash
 /git-branch issue <NNNN> <slug>
 /git-branch quick <slug>
 ```
 ## Ejemplos
 ```bash
 /git-branch issue 0013 hot-reload   # Crea issue/0013-hot-reload
 /git-branch quick fix-typo-readme   # Crea quick/fix-typo-readme
 ```
 ## Precondiciones
 - [ ] Repositorio git válido
 - [ ] Branch master existe
 - [ ] Working tree limpio (sin cambios pendientes)
 ## Flujo
 ### 1. Verificar estado del repositorio
 ```bash
 git branch --show-current
 git status --short
 ```
 **Si no estamos en master:** `git checkout master`
 **Si hay cambios sin commitear:** STOP y avisar al usuario:
 ```
 Hay cambios sin commitear. Opciones:
 1. Commitear: git add . && git commit -m "mensaje"
 2. Stash: git stash
 3. Descartar: git reset --hard (peligroso)
 ```
 ### 2. Actualizar master desde remoto
 ```bash
 git pull --rebase
 ```
 ### 3. Crear rama según tipo
 **Para issues:**
 ```bash
 git checkout -b issue/<NNNN>-<slug>
 ```
 **Para cambios rápidos:**
 ```bash
 git checkout -b quick/<slug>
 ```
 ### 4. Confirmar creación
 ```bash
 git branch --show-current
 ```
 Informar:
 ```
 Rama `<nombre-rama>` creada desde master actualizado
 Cuando termines:
  /git-push
 ```
 ## Convenciones
 - **Formato issue**: `issue/<NNNN>-<slug>` (4 dígitos)
 - **Formato quick**: `quick/<slug>`
 - **Ramas cortas**: horas, no días
 - **No pushear ramas**: integrar via merge a master
 - **No underscores**: solo guiones
 ## Reglas
 - NUNCA trabajar directamente en master
 - SIEMPRE verificar working tree limpio
 - SIEMPRE actualizar master antes de crear rama
@@ -1,116 +0,0 @@
 ---
 name: git-push
 description: Integra cambios a master y publica. Soporta ramas issue/* y quick/*.
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # git-push
 Integra cambios a master y publica al remoto. Detecta automáticamente la rama actual.
 ## Sintaxis
 ```bash
 /git-push
 ```
 ## Flujo
 ### 1. Verificar rama actual y estado
 ```bash
 git branch --show-current
 git status --short
 ```
 **Caso A: En rama issue/* o quick/*** - Continuar al paso 2
 **Caso B: En master con cambios** - Crear rama quick automáticamente:
 - Analizar archivos modificados para generar slug
 - `git checkout -b quick/<slug-generado>`
 **Caso C: En master sin cambios** - STOP: "No hay nada que publicar"
 ### 2. Crear commits por bloque lógico
 ```bash
 git status --short
 git diff --stat
 ```
 Agrupar cambios por tipo y crear commits atómicos:
 ```bash
 git add <archivos_bloque_1>
 git commit -m "<tipo>: <resumen>" -m "<descripción en español>"
 ```
 **Tipos:** feat, fix, refactor, docs, chore, test
 **Reglas de commits:**
 - No WIP
 - No mezclar tipos
 - Descripción larga obligatoria en español
 ### 3. Ejecutar tests
 ```bash
 go test -tags goolm ./...
 ```
 - Tests pasan: continuar
 - Tests fallan: STOP y corregir
 - No hay tests: informar y continuar
 ### 4. Merge a master
 ```bash
 git checkout master
 git pull --rebase
 git merge --no-ff <rama> -m "merge: <rama> — <título>"
 ```
 ### 5. Push a remoto
 ```bash
 git push
 ```
 ### 6. Limpiar rama local
 ```bash
 git branch -d <rama>
 ```
 ### 7. Verificación final
 ```bash
 git log --oneline -3
 ```
 ```
 Rama `<rama>` integrada a master y publicada
 Commits creados:
 - <commit 1>
 - merge: <rama>
 Rama local eliminada.
 ```
 ## Convenciones
 - Commits atómicos
 - Tests obligatorios antes de merge
 - Merge --no-ff siempre
 - Push inmediato
 ## Reglas
 - NO commits WIP
 - NO mezclar tipos en un commit
 - NO saltear tests
 - NO push --force a master
 - SIEMPRE usar --no-ff
@@ -1,105 +0,0 @@
 ---
 name: git-recovery
 description: Recupera el repositorio de estados inconsistentes (worktrees huérfanos, branches bloqueados)
 argument-hint: [--aggressive]
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read
 ---
 # git-recovery
 Recupera el repositorio de estados inconsistentes causados por worktrees huérfanos, branches bloqueados o conflictos git.
 ## Sintaxis
 ```bash
 /git-recovery              # Recuperación estándar
 /git-recovery --aggressive  # Limpieza agresiva
 ```
 ## Cuándo usar
 - Errores "exit status 128" al crear worktrees
 - Git reporta "worktree already exists"
 - Branches que no se pueden eliminar
 - Worktrees huérfanos en `git worktree list`
 ## Flujo
 ### 1. Diagnóstico inicial
 ```bash
 git branch --show-current
 git status --porcelain
 ```
 ### 2. Análisis de problemas
 ```bash
 git worktree list
 git branch --list
 git remote -v
 ```
 ### 3. Limpieza de worktrees huérfanos
 ```bash
 git worktree prune -v
 ```
 Si existe directorio `worktrees/`:
 - Verificar cada worktree contra `git worktree list`
 - Eliminar directorios huérfanos
 ### 4. Verificar branches bloqueados
 Para cada branch issue/* o quick/*:
 - Si está mergeada: `git branch -d <branch>`
 - Si NO está mergeada: advertir
 ### 5. Sincronizar con remoto
 ```bash
 git checkout master
 git fetch origin
 git pull --rebase origin master
 ```
 ### 6. Modo agresivo (solo con --aggressive)
 ```bash
 git remote prune origin -v
 git fsck --full
 git gc --prune=now
 rm -f .git/index.lock  # si existe
 ```
 ### 7. Verificación final
 ```bash
 git status
 git worktree list
 git branch --list
 ```
 ## Patrones de error que activan recovery
 - `exit status 128`
 - `worktree .* already exists`
 - `reference is not a tree`
 - `cannot lock ref`
 - `index.lock`
 ## Convenciones
 - No destructivo por defecto
 - Modo agresivo solo con flag explícito
 - Siempre sincroniza con remoto
 - Preserva cambios locales
 ## Reglas
 - NUNCA git reset --hard sin --aggressive
 - NUNCA eliminar branches no mergeadas automáticamente
 - SIEMPRE sincronizar con remoto después de limpieza
@@ -1,91 +0,0 @@
 ---
 name: import-repo
 description: Importa repositorios existentes al sistema Dataforge desde URL remota o local
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write
 ---
 # import-repo
 Importa repositorios existentes: desde GitHub/GitLab/Gitea, o adoptando un repo local.
 ## Prerequisitos
 - Variables: `GITEA_URL` y `GITEA_TOKEN`
 - Feature flag `workspace_commands` habilitado
 ## Modos
 ### Desde URL remota
 1. Crear repo vacío en Gitea
 2. Clonar origen con `git clone --mirror`
 3. Push a Gitea con `git push --mirror`
 4. Clonar en `workspaces/`
 5. Registrar en BD
 ### Adoptar repo local
 1. Verificar que existe `.git`
 2. Crear repo vacío en Gitea
 3. Añadir remote `gitea`
 4. Push de branches y tags
 5. Registrar en BD
 ## Flujo interactivo
 ### 1. Solicitar fuente
 ```
 Fuente del repositorio:
  - URL remota (ej: https://github.com/user/repo)
  - Nombre local en workspaces/ (ej: legacy-tool)
 ```
 ### 2. Detectar modo y analizar
 Usa `core.DetectImportMode(source)`
 ### 3. Solicitar nombre de destino
 ```
 Nombre en Gitea (Enter para usar 'nombre-sugerido'):
 ```
 ### 4. Verificar que no existe en Gitea
 ### 5. Opciones adicionales
 ```
 ¿Repositorio privado? (s/N):
 Descripción (opcional):
 ```
 ### 6. Resumen y confirmación
 ```
 Resumen:
  Fuente: https://...
  Destino: gitea.example.com/...
  Tipo: importar desde URL remota
 ¿Importar? (s/N):
 ```
 ### 7. Ejecutar importación
 ### 8. Mostrar resultado
 ```
 Repositorio importado exitosamente.
 Workspace: workspaces/nombre
 Gitea URL: https://...
 ```
 ## Convenciones
 - Confirmación obligatoria
 - Rollback automático si falla
 - Historia Git siempre preservada
@@ -1,62 +0,0 @@
 ---
 name: init-frontend
 description: Inicializa proyecto frontend (React/Vite) o desktop (Wails) con Frontend_Library
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # init-frontend
 Inicializa un proyecto frontend (webapp React/Vite) o desktop (Wails + Go + React). Coherente con Frontend_Library y el stack del frontend-lib/build-wails agents.
 ## Sintaxis
 ```bash
 /init-frontend [nombre] [--wails] [--path /ruta/destino]
 ```
 - `nombre`: nombre del proyecto (kebab-case). Si no se da, se pregunta.
 - `--wails`: modo desktop con Wails (Go backend + React frontend). Sin flag = webapp pura.
 - `--path`: directorio destino. Default: directorio actual.
 ## Flujo
 ### 1. Ejecutar script de setup
 ```bash
 bash "${CLAUDE_SKILL_DIR}/setup-frontend.sh" [nombre] [--wails] [path]
 ```
 ### 2. Si el script reporta STATUS: CONFIGURED
 Informar al usuario que el proyecto ya existe.
 ### 3. Si el script reporta STATUS: READY
 Mostrar resumen según modo:
 **Webapp:**
 - `pnpm dev` para desarrollo
 - `pnpm build` para producción
 - Frontend_Library linkeada via pnpm
 **Wails:**
 - `make dev` para desarrollo con hot reload
 - `make build` para compilar
 - Frontend_Library + DevFactory integrados
 - Bindings Go→TS auto-generados
 ### 4. Si el script reporta STATUS: ERROR
 Mostrar el error y sugerir corrección.
 ## Convenciones
 - pnpm exclusivamente (no npm ni yarn)
 - React 19 + TypeScript + Vite + Tailwind CSS 4
 - @anthropic/frontend-lib via pnpm link
 - Temas OKLCH con semantic tokens
 - Phosphor Icons
 - Vite dedupe obligatorio para react/react-dom
 - En modo Wails: go.work con DevFactory, patrón pure core / impure shell
@@ -1,438 +0,0 @@
 #!/usr/bin/env bash
 set -euo pipefail
 # =============================================================================
 # setup-frontend.sh — Inicializa proyecto React/Vite o Wails desktop
 # Coherente con Frontend_Library + DevFactory + build-wails agent
 # =============================================================================
 # --- Colores ---
 RED='\033[0;31m'
 GREEN='\033[0;32m'
 YELLOW='\033[1;33m'
 BLUE='\033[0;34m'
 CYAN='\033[0;36m'
 NC='\033[0m'
 log_info()  { echo -e "${BLUE}[INFO]${NC} $1"; }
 log_ok()    { echo -e "${GREEN}[OK]${NC} $1"; }
 log_warn()  { echo -e "${YELLOW}[WARN]${NC} $1"; }
 log_error() { echo -e "${RED}[ERROR]${NC} $1"; }
 log_step()  { echo -e "${CYAN}[STEP]${NC} $1"; }
 # --- Parámetros ---
 PROJECT_NAME=""
 WAILS_MODE=false
 TARGET_PATH="."
 while [[ $# -gt 0 ]]; do
    case "$1" in
        --wails) WAILS_MODE=true; shift ;;
        --path)  TARGET_PATH="$2"; shift 2 ;;
        -*)      log_error "Flag desconocido: $1"; echo "STATUS: ERROR"; exit 1 ;;
        *)       PROJECT_NAME="$1"; shift ;;
    esac
 done
 # --- Rutas de librerías ---
 FRONTEND_LIB="$HOME/.local_agentes/frontend/frontend"
 DEVFACTORY_PATH="$HOME/.local_agentes/backend"
 TEMPLATES_DIR="$HOME/.local_agentes/frontend/templates/base"
 WAILS_TEMPLATES="$HOME/.claude/agents/build-wails/templates"
 # --- Validar nombre ---
 if [[ -z "$PROJECT_NAME" ]]; then
    log_error "Uso: setup-frontend.sh <nombre> [--wails] [--path /ruta]"
    echo "STATUS: ERROR"
    exit 1
 fi
 # Normalizar
 PROJECT_NAME=$(echo "$PROJECT_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9-]/-/g' | sed 's/--*/-/g' | sed 's/^-\|-$//g')
 PROJECT_DIR="$TARGET_PATH/$PROJECT_NAME"
 # --- Check estado existente ---
 if [[ -f "$PROJECT_DIR/package.json" ]] || [[ -f "$PROJECT_DIR/wails.json" ]]; then
    log_warn "El proyecto $PROJECT_NAME ya existe en $PROJECT_DIR"
    echo "STATUS: CONFIGURED"
    exit 0
 fi
 # --- Verificar dependencias ---
 log_step "Verificando dependencias..."
 if ! command -v pnpm &>/dev/null; then
    log_error "pnpm no está instalado. Instala con: npm install -g pnpm"
    echo "STATUS: ERROR"
    exit 1
 fi
 log_ok "pnpm $(pnpm --version) encontrado"
 if ! command -v node &>/dev/null; then
    log_error "Node.js no encontrado"
    echo "STATUS: ERROR"
    exit 1
 fi
 log_ok "Node $(node --version) encontrado"
 if [[ "$WAILS_MODE" == true ]]; then
    if ! command -v wails &>/dev/null; then
        log_error "Wails no está instalado. Instala con: go install github.com/wailsapp/wails/v2/cmd/wails@latest"
        echo "STATUS: ERROR"
        exit 1
    fi
    log_ok "Wails $(wails version 2>/dev/null | head -1 || echo 'v2.x') encontrado"
    if ! command -v go &>/dev/null; then
        log_error "Go no encontrado (requerido para Wails)"
        echo "STATUS: ERROR"
        exit 1
    fi
    log_ok "Go $(go version | grep -oP '\d+\.\d+' | head -1) encontrado"
 fi
 if [[ ! -d "$FRONTEND_LIB" ]]; then
    log_warn "Frontend_Library no encontrada en $FRONTEND_LIB — se creará sin link"
    HAS_FRONTEND_LIB=false
 else
    log_ok "Frontend_Library encontrada"
    HAS_FRONTEND_LIB=true
 fi
 # ============================================================================
 # MODO WAILS — Desktop app (Go + React)
 # ============================================================================
 if [[ "$WAILS_MODE" == true ]]; then
    log_step "Creando proyecto Wails '$PROJECT_NAME'..."
    # Usar wails init con template react-ts
    wails init -n "$PROJECT_NAME" -t react-ts -d "$TARGET_PATH" 2>/dev/null
    cd "$PROJECT_DIR"
    # --- go.work con DevFactory ---
    if [[ -d "$DEVFACTORY_PATH" ]]; then
        log_step "Configurando go.work con DevFactory..."
        cat > go.work << EOF
 go 1.22
 use (
    .
    $DEVFACTORY_PATH
 )
 EOF
        log_ok "DevFactory enlazado via go.work"
    fi
    # --- Configurar frontend con pnpm ---
    log_step "Configurando frontend con pnpm..."
    cd frontend
    # Reemplazar npm por pnpm en wails.json
    cd ..
    if [[ -f "wails.json" ]]; then
        sed -i 's/"npm install"/"pnpm install"/g' wails.json
        sed -i 's/"npm run dev"/"pnpm dev"/g' wails.json
        sed -i 's/"npm run build"/"pnpm build"/g' wails.json
    fi
    cd frontend
    # Instalar con pnpm
    rm -f package-lock.json 2>/dev/null || true
    pnpm install
    # --- Linkear Frontend_Library ---
    if [[ "$HAS_FRONTEND_LIB" == true ]]; then
        log_step "Linkeando Frontend_Library..."
        pnpm add "@anthropic/frontend-lib@link:$FRONTEND_LIB"
        log_ok "@anthropic/frontend-lib linkeada"
    fi
    # --- Instalar Tailwind CSS 4 ---
    log_step "Instalando Tailwind CSS 4..."
    pnpm add -D tailwindcss @tailwindcss/vite
    # --- Configurar vite.config.ts con dedupe y tailwind ---
    log_step "Configurando Vite (dedupe + tailwind)..."
    cat > vite.config.ts << 'VEOF'
 import { defineConfig } from 'vite'
 import react from '@vitejs/plugin-react'
 import tailwindcss from '@tailwindcss/vite'
 import { resolve } from 'path'
 export default defineConfig({
  plugins: [react(), tailwindcss()],
  resolve: {
    alias: {
      '@': resolve(__dirname, './src'),
      '@wails': resolve(__dirname, './wailsjs'),
    },
    dedupe: ['react', 'react-dom'],
  },
 })
 VEOF
    # --- CSS base con Tailwind ---
    cat > src/style.css << 'CSSEOF'
@import "tailwindcss";
 CSSEOF
    # --- Instalar Phosphor Icons ---
    pnpm add @phosphor-icons/react
    cd ..
    # --- Makefile (basado en build-wails agent) ---
    log_step "Generando Makefile..."
    cat > Makefile << 'MKEOF'
 .PHONY: dev dev-debug build build-prod build-linux build-windows build-all clean generate doctor
 APP_NAME := $(shell basename $(CURDIR))
 ## dev: Desarrollo con hot reload
 dev:
 	wails dev
 ## dev-debug: Desarrollo con DevTools
 dev-debug:
 	wails dev -devtools
 ## build: Build para plataforma actual
 build:
 	wails build
 ## build-prod: Build optimizado para producción
 build-prod:
 	wails build -clean -trimpath -ldflags="-s -w"
 ## build-linux: Build para Linux AMD64
 build-linux:
 	wails build -platform linux/amd64
 ## build-windows: Cross-compile para Windows
 build-windows:
 	wails build -platform windows/amd64
 ## build-all: Linux + Windows
 build-all: build-linux build-windows
 ## generate: Regenerar bindings TypeScript
 generate:
 	wails generate module
 ## clean: Limpiar artefactos
 clean:
 	rm -rf build/bin frontend/dist
 ## doctor: Verificar instalación
 doctor:
 	wails doctor
 ## help: Muestra esta ayuda
 help:
 	@grep -E '^## ' Makefile | sed 's/## //' | column -t -s ':'
 MKEOF
    # --- .gitignore ---
    cat >> .gitignore << 'EOF'
 node_modules/
 frontend/dist/
 build/bin/
 *.exe
 EOF
    # --- Resumen Wails ---
    echo ""
    log_ok "Proyecto Wails '$PROJECT_NAME' creado en $PROJECT_DIR"
    echo ""
    echo -e "${CYAN}Estructura:${NC}"
    echo "  $PROJECT_NAME/"
    echo "  ├── main.go, app.go     — Backend Go"
    echo "  ├── go.work              — Enlace a DevFactory"
    echo "  ├── frontend/            — React + TypeScript + Vite"
    echo "  │   ├── src/             — Componentes React"
    echo "  │   └── wailsjs/         — Bindings auto-generados"
    echo "  ├── Makefile             — dev, build, build-all"
    echo "  └── wails.json           — Configuración Wails"
    echo ""
    echo -e "${CYAN}Comandos:${NC}"
    echo "  make dev          — Desarrollo con hot reload"
    echo "  make build        — Compilar app desktop"
    echo "  make build-all    — Linux + Windows"
    echo "  make generate     — Regenerar bindings TS"
    echo ""
    if [[ "$HAS_FRONTEND_LIB" == true ]]; then
        echo -e "${CYAN}Frontend_Library:${NC}"
        echo "  import { Button, Card } from '@anthropic/frontend-lib'"
        echo "  import { useTheme } from '@anthropic/frontend-lib/hooks'"
        echo ""
    fi
    echo "STATUS: READY"
    exit 0
 fi
 # ============================================================================
 # MODO WEBAPP — React + Vite (sin Wails)
 # ============================================================================
 log_step "Creando proyecto webapp '$PROJECT_NAME'..."
 mkdir -p "$PROJECT_DIR"
 cd "$PROJECT_DIR"
 # --- Usar template de Frontend_Library si existe ---
 if [[ -d "$TEMPLATES_DIR" ]]; then
    log_step "Usando template de Frontend_Library..."
    cp -r "$TEMPLATES_DIR"/* .
    cp -r "$TEMPLATES_DIR"/.[!.]* . 2>/dev/null || true
 else
    log_step "Creando desde cero con Vite..."
    # package.json
    cat > package.json << PKGEOF
 {
  "name": "$PROJECT_NAME",
  "private": true,
  "version": "0.1.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "preview": "vite preview"
  }
 }
 PKGEOF
    # Instalar dependencias base
    pnpm add react react-dom
    pnpm add -D typescript @types/react @types/react-dom
    pnpm add -D vite @vitejs/plugin-react
    pnpm add -D tailwindcss @tailwindcss/vite
    # tsconfig.json
    cat > tsconfig.json << 'TSEOF'
 {
  "compilerOptions": {
    "target": "ES2023",
    "lib": ["ES2023", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "paths": { "@/*": ["./src/*"] },
    "skipLibCheck": true
  },
  "include": ["src"]
 }
 TSEOF
    # vite.config.ts
    cat > vite.config.ts << 'VEOF'
 import { defineConfig } from 'vite'
 import react from '@vitejs/plugin-react'
 import tailwindcss from '@tailwindcss/vite'
 import { resolve } from 'path'
 export default defineConfig({
  plugins: [react(), tailwindcss()],
  resolve: {
    alias: { '@': resolve(__dirname, './src') },
    dedupe: ['react', 'react-dom'],
  },
 })
 VEOF
    # index.html
    cat > index.html << HTMLEOF
 <!doctype html>
 <html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>$PROJECT_NAME</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>
 </html>
 HTMLEOF
    # src/
    mkdir -p src
    cat > src/main.tsx << 'TSXEOF'
 import { StrictMode } from 'react'
 import { createRoot } from 'react-dom/client'
 import App from './App'
 import './app.css'
 createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <App />
  </StrictMode>,
 )
 TSXEOF
    cat > src/App.tsx << 'TSXEOF'
 function App() {
  return (
    <div className="min-h-screen bg-surface text-foreground flex items-center justify-center">
      <h1 className="text-3xl font-bold">Ready</h1>
    </div>
  )
 }
 export default App
 TSXEOF
    cat > src/app.css << 'CSSEOF'
@import "tailwindcss";
 CSSEOF
 fi
 # --- Linkear Frontend_Library ---
 if [[ "$HAS_FRONTEND_LIB" == true ]]; then
    log_step "Linkeando Frontend_Library..."
    pnpm add "@anthropic/frontend-lib@link:$FRONTEND_LIB"
    log_ok "@anthropic/frontend-lib linkeada"
 fi
 # --- Phosphor Icons ---
 pnpm add @phosphor-icons/react
 # --- .gitignore ---
 cat > .gitignore << 'EOF'
 node_modules/
 dist/
 .vite/
 *.local
 EOF
 # --- Resumen Webapp ---
 echo ""
 log_ok "Proyecto webapp '$PROJECT_NAME' creado en $PROJECT_DIR"
 echo ""
 echo -e "${CYAN}Estructura:${NC}"
 echo "  $PROJECT_NAME/"
 echo "  ├── src/"
 echo "  │   ├── App.tsx       — Componente principal"
 echo "  │   ├── main.tsx      — Entry point"
 echo "  │   └── app.css       — Tailwind CSS"
 echo "  ├── vite.config.ts    — Vite + Tailwind + dedupe"
 echo "  ├── tsconfig.json     — TypeScript strict"
 echo "  └── package.json      — pnpm"
 echo ""
 echo -e "${CYAN}Comandos:${NC}"
 echo "  pnpm dev      — Servidor de desarrollo"
 echo "  pnpm build    — Build de producción"
 echo "  pnpm preview  — Preview del build"
 echo ""
 if [[ "$HAS_FRONTEND_LIB" == true ]]; then
    echo -e "${CYAN}Frontend_Library:${NC}"
    echo "  import { Button, Card } from '@anthropic/frontend-lib'"
    echo "  import { useTheme } from '@anthropic/frontend-lib/hooks'"
    echo ""
 fi
 echo "STATUS: READY"
@@ -1,53 +0,0 @@
 ---
 name: init-go-module
 description: Inicializa un módulo Go funcional con bindings Python (CGO c-shared + ctypes)
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # init-go-module
 Inicializa un módulo Go con arquitectura funcional (pure core / impure shell) y bindings Python automáticos via CGO c-shared + ctypes. Coherente con DevFactory y el stack del backend-lib agent.
 ## Sintaxis
 ```bash
 /init-go-module [nombre] [--path /ruta/destino]
 ```
 - `nombre`: nombre del módulo (kebab-case). Si no se da, se pregunta.
 - `--path`: directorio destino. Default: directorio actual.
 ## Flujo
 ### 1. Ejecutar script de setup
 ```bash
 bash "${CLAUDE_SKILL_DIR}/setup-go-module.sh" [nombre] [path]
 ```
 ### 2. Si el script reporta STATUS: CONFIGURED
 Informar al usuario que el módulo ya está configurado.
 ### 3. Si el script reporta STATUS: READY
 Mostrar resumen:
 - Estructura creada
 - Cómo compilar: `make build`
 - Cómo generar bindings Python: `make python`
 - Cómo testear: `make test`
 - Cómo usar desde Python: `from bindings.modulo import *`
 ### 4. Si el script reporta STATUS: ERROR
 Mostrar el error y sugerir corrección.
 ## Convenciones
 - Usa DevFactory como dependencia via `go.work` (igual que build-wails)
 - Patrón pure core / impure shell de DevFactory
 - `Result[T]` y `Option[T]` del core de DevFactory
 - Funciones exportadas a Python son thin wrappers en `export/`
 - El wrapper Python se auto-genera desde los `//export` comments
@@ -1,466 +0,0 @@
 #!/usr/bin/env bash
 set -euo pipefail
 # =============================================================================
 # setup-go-module.sh — Inicializa módulo Go funcional con bindings Python
 # Coherente con DevFactory (pure core / impure shell) + CGO c-shared + ctypes
 # =============================================================================
 # --- Colores ---
 RED='\033[0;31m'
 GREEN='\033[0;32m'
 YELLOW='\033[1;33m'
 BLUE='\033[0;34m'
 CYAN='\033[0;36m'
 NC='\033[0m'
 log_info()  { echo -e "${BLUE}[INFO]${NC} $1"; }
 log_ok()    { echo -e "${GREEN}[OK]${NC} $1"; }
 log_warn()  { echo -e "${YELLOW}[WARN]${NC} $1"; }
 log_error() { echo -e "${RED}[ERROR]${NC} $1"; }
 log_step()  { echo -e "${CYAN}[STEP]${NC} $1"; }
 # --- Parámetros ---
 MODULE_NAME="${1:-}"
 TARGET_PATH="${2:-.}"
 DEVFACTORY_PATH="$HOME/.local_agentes/backend"
 DEVFACTORY_MODULE="github.com/lucasdataproyects/devfactory"
 # --- Validar nombre ---
 if [[ -z "$MODULE_NAME" ]]; then
    log_error "Uso: setup-go-module.sh <nombre> [path]"
    echo "STATUS: ERROR"
    exit 1
 fi
 # Normalizar nombre a kebab-case
 MODULE_NAME=$(echo "$MODULE_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9-]/-/g' | sed 's/--*/-/g' | sed 's/^-\|-$//g')
 PROJECT_DIR="$TARGET_PATH/$MODULE_NAME"
 # --- Check estado existente ---
 if [[ -f "$PROJECT_DIR/go.mod" ]]; then
    log_warn "El módulo $MODULE_NAME ya existe en $PROJECT_DIR"
    if [[ -f "$PROJECT_DIR/export/exports.go" ]]; then
        log_ok "Bindings Python ya configurados"
    else
        log_warn "Falta directorio export/ — ejecuta de nuevo para completar"
    fi
    echo "STATUS: CONFIGURED"
    exit 0
 fi
 # --- Verificar dependencias ---
 log_step "Verificando dependencias..."
 if ! command -v go &>/dev/null; then
    log_error "Go no está instalado. Instala Go 1.22+"
    echo "STATUS: ERROR"
    exit 1
 fi
 GO_VERSION=$(go version | grep -oP '\d+\.\d+' | head -1)
 log_ok "Go $GO_VERSION encontrado"
 if ! command -v python3 &>/dev/null; then
    log_warn "Python3 no encontrado — los bindings se generarán pero no se podrán testear"
 fi
 if [[ ! -d "$DEVFACTORY_PATH" ]]; then
    log_warn "DevFactory no encontrado en $DEVFACTORY_PATH — se creará go.mod sin go.work"
 fi
 # --- Crear estructura ---
 log_step "Creando estructura del módulo '$MODULE_NAME'..."
 mkdir -p "$PROJECT_DIR"/{core,shell,export,python/bindings,cmd,internal}
 # --- go.mod ---
 log_step "Generando go.mod..."
 cat > "$PROJECT_DIR/go.mod" << EOF
 module github.com/lucasdataproyects/$MODULE_NAME
 go 1.22
 require $DEVFACTORY_MODULE v0.0.0
 EOF
 # --- go.work (si DevFactory existe localmente) ---
 if [[ -d "$DEVFACTORY_PATH" ]]; then
    log_step "Generando go.work con DevFactory local..."
    cat > "$PROJECT_DIR/go.work" << EOF
 go 1.22
 use (
    .
    $DEVFACTORY_PATH
 )
 EOF
    log_ok "go.work enlazado a DevFactory"
 fi
 # --- core/transform.go — Funciones puras de ejemplo ---
 log_step "Generando core/ (funciones puras)..."
 cat > "$PROJECT_DIR/core/transform.go" << 'GOEOF'
 // Package core contiene funciones puras sin side effects.
 // Todas las funciones son deterministas y composables.
 package core
 import (
 	"strings"
 	"errors"
 	df "github.com/lucasdataproyects/devfactory/core"
 )
 // ToUpper transforma texto a mayúsculas (función pura).
 func ToUpper(s string) string {
 	return strings.ToUpper(s)
 }
 // ProcessItems aplica una transformación a cada elemento usando MapSlice de DevFactory.
 func ProcessItems(items []string, transform func(string) string) []string {
 	return df.MapSlice(items, transform)
 }
 // FilterNonEmpty filtra elementos vacíos usando FilterSlice de DevFactory.
 func FilterNonEmpty(items []string) []string {
 	return df.FilterSlice(items, func(s string) bool {
 		return len(strings.TrimSpace(s)) > 0
 	})
 }
 // SafeDivide retorna Result[float64] para evitar panic en división por cero.
 func SafeDivide(a, b float64) df.Result[float64] {
 	if b == 0 {
 		return df.Err[float64](errors.New("division by zero"))
 	}
 	return df.Ok(a / b)
 }
 GOEOF
 # --- core/types.go — Tipos exportables a Python ---
 cat > "$PROJECT_DIR/core/types.go" << 'GOEOF'
 package core
 // DataPoint representa un punto de datos exportable a Python.
 // Los campos usan tipos C-compatible para facilitar el binding.
 type DataPoint struct {
 	Label string
 	Value float64
 }
 // Summary es el resultado de un procesamiento, exportable a Python.
 type Summary struct {
 	Count int
 	Total float64
 	Items []string
 }
 GOEOF
 # --- shell/io.go — Operaciones I/O con Result[T] ---
 log_step "Generando shell/ (operaciones I/O)..."
 cat > "$PROJECT_DIR/shell/io.go" << 'GOEOF'
 // Package shell contiene operaciones con side effects, wrapeadas en Result[T].
 package shell
 import (
 	df "github.com/lucasdataproyects/devfactory/core"
 	"github.com/lucasdataproyects/devfactory/shell"
 )
 // ReadDataFile lee un archivo y retorna su contenido como Result.
 func ReadDataFile(path string) df.Result[string] {
 	return shell.ReadString(path)
 }
 // WriteResult escribe un resultado a archivo.
 func WriteResult(path string, content string) df.Result[struct{}] {
 	return shell.WriteString(path, content)
 }
 GOEOF
 # --- export/exports.go — Funciones exportadas via CGO ---
 log_step "Generando export/ (bindings CGO)..."
 cat > "$PROJECT_DIR/export/exports.go" << GOEOF
 // Package main exporta funciones Go como C shared library.
 // Cada función con //export se expone como símbolo C callable desde Python.
 package main
 import "C"
 import (
 	"encoding/json"
 	"unsafe"
 	"github.com/lucasdataproyects/$MODULE_NAME/core"
 )
 //export GoToUpper
 func GoToUpper(input *C.char) *C.char {
 	result := core.ToUpper(C.GoString(input))
 	return C.CString(result)
 }
 //export GoProcessItems
 func GoProcessItems(jsonInput *C.char) *C.char {
 	var items []string
 	if err := json.Unmarshal([]byte(C.GoString(jsonInput)), &items); err != nil {
 		return C.CString("[]")
 	}
 	result := core.ProcessItems(items, core.ToUpper)
 	out, _ := json.Marshal(result)
 	return C.CString(string(out))
 }
 //export GoFilterNonEmpty
 func GoFilterNonEmpty(jsonInput *C.char) *C.char {
 	var items []string
 	if err := json.Unmarshal([]byte(C.GoString(jsonInput)), &items); err != nil {
 		return C.CString("[]")
 	}
 	result := core.FilterNonEmpty(items)
 	out, _ := json.Marshal(result)
 	return C.CString(string(out))
 }
 //export GoSafeDivide
 func GoSafeDivide(a, b C.double) *C.char {
 	result := core.SafeDivide(float64(a), float64(b))
 	if result.IsErr() {
 		return C.CString(`{"error":"` + result.Error().Error() + `"}`)
 	}
 	out, _ := json.Marshal(map[string]float64{"value": result.Unwrap()})
 	return C.CString(string(out))
 }
 //export GoFree
 func GoFree(ptr *C.char) {
 	C.free(unsafe.Pointer(ptr))
 }
 func main() {}
 GOEOF
 # --- python/bindings/__init__.py — Wrapper ctypes auto-generado ---
 log_step "Generando python/bindings/ (ctypes wrapper)..."
 # Nombre de la shared library según OS
 SO_NAME="lib${MODULE_NAME}.so"
 cat > "$PROJECT_DIR/python/bindings/__init__.py" << PYEOF
 """
 Auto-generated Python bindings for $MODULE_NAME.
 Uses ctypes to call Go functions compiled as C shared library.
 Usage:
    from bindings import to_upper, process_items, filter_non_empty, safe_divide
 """
 import ctypes
 import json
 import os
 from pathlib import Path
 # Localizar la shared library
 _LIB_DIR = Path(__file__).parent.parent.parent / "build"
 _LIB_NAME = "$SO_NAME"
 _LIB_PATH = _LIB_DIR / _LIB_NAME
 if not _LIB_PATH.exists():
    raise FileNotFoundError(
        f"Shared library not found at {_LIB_PATH}. "
        f"Run 'make build' in the project root first."
    )
 _lib = ctypes.CDLL(str(_LIB_PATH))
 # --- Configurar tipos de retorno ---
 _lib.GoToUpper.argtypes = [ctypes.c_char_p]
 _lib.GoToUpper.restype = ctypes.c_char_p
 _lib.GoProcessItems.argtypes = [ctypes.c_char_p]
 _lib.GoProcessItems.restype = ctypes.c_char_p
 _lib.GoFilterNonEmpty.argtypes = [ctypes.c_char_p]
 _lib.GoFilterNonEmpty.restype = ctypes.c_char_p
 _lib.GoSafeDivide.argtypes = [ctypes.c_double, ctypes.c_double]
 _lib.GoSafeDivide.restype = ctypes.c_char_p
 _lib.GoFree.argtypes = [ctypes.c_char_p]
 _lib.GoFree.restype = None
 def to_upper(text: str) -> str:
    """Convert text to uppercase using Go core."""
    result = _lib.GoToUpper(text.encode("utf-8"))
    return result.decode("utf-8")
 def process_items(items: list[str]) -> list[str]:
    """Process items through Go pipeline (ToUpper transformation)."""
    input_json = json.dumps(items).encode("utf-8")
    result = _lib.GoProcessItems(input_json)
    return json.loads(result.decode("utf-8"))
 def filter_non_empty(items: list[str]) -> list[str]:
    """Filter empty strings using Go core."""
    input_json = json.dumps(items).encode("utf-8")
    result = _lib.GoFilterNonEmpty(input_json)
    return json.loads(result.decode("utf-8"))
 def safe_divide(a: float, b: float) -> float:
    """Safe division using Go Result type. Raises ValueError on division by zero."""
    result = _lib.GoSafeDivide(ctypes.c_double(a), ctypes.c_double(b))
    data = json.loads(result.decode("utf-8"))
    if "error" in data:
        raise ValueError(data["error"])
    return data["value"]
 PYEOF
 # --- python/example.py ---
 cat > "$PROJECT_DIR/python/example.py" << PYEOF
 """Example usage of $MODULE_NAME Go bindings from Python."""
 from bindings import to_upper, process_items, filter_non_empty, safe_divide
 # String transformation
 print(to_upper("hello from go"))  # HELLO FROM GO
 # Batch processing via Go's MapSlice
 items = ["hello", "world", "from", "go"]
 print(process_items(items))  # ["HELLO", "WORLD", "FROM", "GO"]
 # Filtering via Go's FilterSlice
 mixed = ["hello", "", "world", "  ", "go"]
 print(filter_non_empty(mixed))  # ["hello", "world", "go"]
 # Safe division with Result[T] error handling
 print(safe_divide(10.0, 3.0))  # 3.333...
 try:
    safe_divide(10.0, 0.0)
 except ValueError as e:
    print(f"Caught: {e}")  # Caught: division by zero
 PYEOF
 # --- core/transform_test.go ---
 log_step "Generando tests..."
 cat > "$PROJECT_DIR/core/transform_test.go" << 'GOEOF'
 package core
 import (
 	"testing"
 )
 func TestToUpper(t *testing.T) {
 	if got := ToUpper("hello"); got != "HELLO" {
 		t.Errorf("ToUpper(\"hello\") = %q, want %q", got, "HELLO")
 	}
 }
 func TestFilterNonEmpty(t *testing.T) {
 	items := []string{"hello", "", "world", "  ", "go"}
 	result := FilterNonEmpty(items)
 	if len(result) != 3 {
 		t.Errorf("FilterNonEmpty got %d items, want 3", len(result))
 	}
 }
 func TestSafeDivide(t *testing.T) {
 	ok := SafeDivide(10, 2)
 	if ok.IsErr() {
 		t.Error("SafeDivide(10, 2) should not error")
 	}
 	if ok.Unwrap() != 5.0 {
 		t.Errorf("SafeDivide(10, 2) = %f, want 5.0", ok.Unwrap())
 	}
 	err := SafeDivide(10, 0)
 	if !err.IsErr() {
 		t.Error("SafeDivide(10, 0) should error")
 	}
 }
 GOEOF
 # --- Makefile ---
 log_step "Generando Makefile..."
 cat > "$PROJECT_DIR/Makefile" << MKEOF
 .PHONY: build test clean python dev
 MODULE_NAME := $MODULE_NAME
 BUILD_DIR := build
 SO_NAME := $SO_NAME
 ## build: Compila la shared library (.so) para Python
 build:
 	@mkdir -p \$(BUILD_DIR)
 	cd export && CGO_ENABLED=1 go build -buildmode=c-shared -o ../\$(BUILD_DIR)/\$(SO_NAME) .
 	@echo "✓ Built \$(BUILD_DIR)/\$(SO_NAME)"
 ## test: Ejecuta tests de Go
 test:
 	go test ./core/... ./shell/... -v
 ## python: Compila y ejecuta ejemplo Python
 python: build
 	cd python && python3 example.py
 ## clean: Limpia artefactos
 clean:
 	rm -rf \$(BUILD_DIR)
 	find . -name "__pycache__" -type d -exec rm -rf {} + 2>/dev/null || true
 ## dev: Tests + build en un paso
 dev: test build
 	@echo "✓ Ready — run 'make python' to test bindings"
 ## tidy: go mod tidy
 tidy:
 	go mod tidy
 ## help: Muestra esta ayuda
 help:
 	@grep -E '^## ' Makefile | sed 's/## //' | column -t -s ':'
 MKEOF
 # --- .gitignore ---
 cat > "$PROJECT_DIR/.gitignore" << 'EOF'
 build/
 *.so
 *.h
 *.dylib
 *.dll
 __pycache__/
 *.pyc
 .pytest_cache/
 EOF
 # --- go mod tidy ---
 log_step "Ejecutando go mod tidy..."
 cd "$PROJECT_DIR"
 if [[ -f "go.work" ]]; then
    go mod tidy 2>/dev/null || log_warn "go mod tidy falló — revisa el go.work"
 else
    go mod tidy 2>/dev/null || log_warn "go mod tidy falló — DevFactory no está disponible"
 fi
 # --- Resumen ---
 echo ""
 log_ok "Módulo '$MODULE_NAME' creado en $PROJECT_DIR"
 echo ""
 echo -e "${CYAN}Estructura:${NC}"
 echo "  $MODULE_NAME/"
 echo "  ├── core/           — Funciones puras (sin side effects)"
 echo "  ├── shell/          — Operaciones I/O con Result[T]"
 echo "  ├── export/         — Funciones exportadas via CGO"
 echo "  ├── python/bindings — Wrapper ctypes auto-generado"
 echo "  ├── Makefile        — build, test, python, clean"
 echo "  └── go.work         — Enlace a DevFactory"
 echo ""
 echo -e "${CYAN}Comandos:${NC}"
 echo "  make test    — Ejecutar tests Go"
 echo "  make build   — Compilar shared library"
 echo "  make python  — Testear bindings Python"
 echo "  make dev     — Test + build en un paso"
 echo ""
 echo "STATUS: READY"
@@ -1,57 +0,0 @@
 ---
 name: issues-status
 description: Dashboard global de issues en todos los workspaces con métricas y filtros
 argument-hint: [workspace] [--status pending] [--tag tag] [--export json|csv]
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read
 ---
 # issues-status
 Muestra dashboard global de todas las issues con métricas, filtros y sugerencias.
 ## Sintaxis
 ```bash
 /issues-status                          # Dashboard global
 /issues-status <workspace>              # Detalle de workspace
 /issues-status --status pending         # Filtrar por estado
 /issues-status --tag backend            # Filtrar por tag
 /issues-status --export json            # Exportar
 ```
 ## Flujo
 ### 1. Parsear argumentos
 - Primer arg (sin --): `filterWorkspace`
 - `--status <value>`: pending | in_progress | completed
 - `--tag <value>`: filtrar por tag
 - `--export <format>`: json | csv
 ### 2. Ejecutar dashboard
 Llama `app.IssuesDashboardCommand(config, filterWorkspace, filterStatus, filterTag, exportFormat)`
 ### 3. Modo interactivo (dashboard global)
 Si no hay filtros:
 1. Mostrar dashboard con sugerencias
 2. Preguntar: "¿Ver detalle de un workspace? (nombre o 'n')"
 3. Si responde nombre: mostrar detalle
 4. Si responde 'n': terminar
 ### Comandos sugeridos
 ```
 Commands:
  /issues-status <workspace>
  /issues-status --status pending
  /fix-issue <issue>
 ```
 ## Manejo de errores
 - Si no hay workspaces: sugerir crear o sincronizar
 - Si no hay issues: mostrar dashboard vacío con sugerencias
@@ -0,0 +1,268 @@
 ---
 name: parallel-fix-issues
 description: >
  Implementar múltiples issues en paralelo. Analiza dependencias entre issues pendientes,
  crea git worktrees aislados, lanza agentes concurrentes para cada issue, verifica
  resultados (build + tests) e integra todo a master en orden.
 allowed-tools: Bash Read Write Edit Grep Glob Agent
 argument-hint: "[issue-numbers... | all]"
 ---
 # Parallel Fix Issues
 Skill para implementar múltiples issues simultáneamente usando git worktrees y agentes paralelos.
 ## Inputs
 - `$ARGUMENTS`: lista de issue numbers (ej: `0026 0027 0031`) o `all` para todos los pendientes.
 - Si no hay argumentos, preguntar al usuario qué issues quiere procesar.
 ## Proceso completo
 ### Fase 1: Análisis de dependencias
 Lanzar un **Agent** (subagent_type: `Explore`) para analizar los issues y producir un plan de ejecución.
 El agente debe:
 1. Leer `dev/issues/README.md` y filtrar los issues pendientes
 2. Si `$ARGUMENTS` no es `all`, filtrar solo los issues solicitados
 3. Para cada issue pendiente, leer el archivo completo y extraer:
   - **Objetivo** (resumen)
   - **Prerequisitos** y dependencias explícitas (ej: "requiere issue 0026")
   - **Archivos afectados** (para detectar conflictos potenciales entre issues)
 4. Construir un **grafo de dependencias** y agrupar en **waves** (oleadas):
   - Wave 1: issues sin dependencias entre sí y sin dependencias pendientes
   - Wave 2: issues que dependen de wave 1
   - Wave N: etc.
 5. Dentro de cada wave, identificar **conflictos potenciales** (dos issues que tocan los mismos archivos)
 6. Devolver el resultado en este formato exacto:
 ```
 WAVE 1 (paralelo):
 - <NNNN>-<slug> — <objetivo resumido> — archivos: <lista>
 - <NNNN>-<slug> — <objetivo resumido> — archivos: <lista>
 WAVE 2 (paralelo, después de wave 1):
 - <NNNN>-<slug> — <objetivo resumido> — depende de: <NNNN>
 CONFLICTOS POTENCIALES:
 - <NNNN> y <NNNN> tocan <archivo> — riesgo de merge conflict
 ISSUES EXCLUIDOS:
 - <NNNN>-<slug> — razón (dependencia externa no resuelta, etc.)
 ```
 **Mostrar el resultado al usuario y pedir confirmación** antes de continuar. El usuario puede:
 - Aprobar el plan tal cual
 - Excluir issues específicos
 - Reordenar waves
 ### Fase 2: Setup de worktrees
 Una vez aprobado el plan, crear los worktrees.
 ```bash
 .claude/skills/parallel-fix-issues/scripts/setup-worktrees.sh <slug-1> <slug-2> ...
 ```
 El script crea un worktree por issue en `worktrees/<slug>/`, cada uno en su propia branch `issue/<slug>`.
 **Verificar** que todos los worktrees se crearon correctamente:
 ```bash
 git worktree list
 ```
 ### Fase 3: Ejecución paralela por waves
 Para cada wave, lanzar **Agents en paralelo** (un Agent por issue, todos en el mismo mensaje para ejecución concurrente).
 **CRÍTICO**: Lanzar todos los agentes de una wave en una sola respuesta con múltiples tool calls. NO lanzar de uno en uno.
 **PERMISOS**: Todas las llamadas Bash de los agentes deben usar `dangerouslyDisableSandbox: true` para evitar prompts de permisos que bloqueen la ejecución paralela. Indicar esto explícitamente en el prompt de cada agente.
 El prompt de cada agente debe incluir:
 1. **Ruta absoluta del worktree**: `/home/ubuntu/CodeProyects/agents_and_robots/worktrees/<slug>`
 2. **Contenido completo del issue** (copiar el markdown entero)
 3. **Instrucciones de ejecución** (ver template abajo)
 #### Template de prompt para cada agente
 ```
 Eres un agente de desarrollo implementando el issue <NNNN>-<slug>.
 ## Directorio de trabajo
 Worktree: /home/ubuntu/CodeProyects/agents_and_robots/worktrees/<slug>
 Usa SIEMPRE esta ruta como prefijo en paths absolutos.
 Variable de conveniencia para comandos:
  W=/home/ubuntu/CodeProyects/agents_and_robots/worktrees/<slug>
 ## Permisos
 IMPORTANTE: En TODAS tus llamadas al tool Bash, usa el parámetro `dangerouslyDisableSandbox: true`.
 Esto es necesario porque estás ejecutando en paralelo con otros agentes y no hay usuario interactivo
 para aprobar permisos. Ejemplo:
  Bash({ command: "cd $W && go build -tags goolm ./...", dangerouslyDisableSandbox: true })
 ## Issue a implementar
 <PEGAR CONTENIDO COMPLETO DEL ISSUE AQUÍ>
 ## Instrucciones
 Sigue este flujo estrictamente:
 1. **Leer el issue** — ya lo tienes arriba, entiende objetivo, tareas y arquitectura.
 2. **Implementar todas las tareas** en orden:
   - Respetar pure core / impure shell (pkg/ puro, shell/ impuro)
   - Hacer commits atómicos por bloque lógico
   - Prefijos: feat:, fix:, test:, docs:, refactor:, chore:
   - NO hacer commits WIP ni código a medias
   - Compilar frecuentemente:
     Bash({ command: "cd $W && go build -tags goolm ./...", dangerouslyDisableSandbox: true })
 3. **Tests obligatorios**:
   - Escribir tests para todo código nuevo
   - Ejecutar:
     Bash({ command: "cd $W && go test -tags goolm ./...", dangerouslyDisableSandbox: true })
   - NO continuar si los tests fallan
 4. **Cerrar el issue** — solo mover el archivo, NO tocar README:
   - Bash({ command: "cd $W && git mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/", dangerouslyDisableSandbox: true })
   - Commit: docs: cerrar issue <NNNN>
   IMPORTANTE: usar `git mv` (no `mv` + `git add`) para que git registre el movimiento.
   IMPORTANTE: NO modificar dev/issues/README.md — lo hace el orquestador después del merge
   para evitar conflictos entre agentes paralelos.
 5. **NO hacer merge a master, NO hacer push.** La integración la maneja el orquestador.
 6. **Reportar resultado** al final:
   - ÉXITO: qué se implementó, cuántos commits, tests pasando
   - FALLO: qué falló, en qué paso, qué queda pendiente
 ```
 **Esperar** a que todos los agentes de la wave terminen antes de pasar a la siguiente wave.
 ### Fase 4: Verificación
 Después de cada wave, verificar TODOS los worktrees completados:
 ```bash
 .claude/skills/parallel-fix-issues/scripts/verify-worktree.sh worktrees/<slug>
 ```
 El script verifica:
 - `go build -tags goolm ./...` — compila sin errores
 - `go test -tags goolm ./...` — tests pasan
 - Issue movido a `dev/issues/completed/`
 - Al menos 1 commit en la branch
 **Si un worktree falla verificación**:
 1. Reportar al usuario qué falló
 2. Preguntar si quiere: (a) intentar arreglar, (b) excluir ese issue, (c) abortar todo
 3. Si se excluye, marcar para no integrar
 ### Fase 5: Integración a master
 Una vez todas las waves verificadas, integrar a master **en orden de waves** (wave 1 primero, luego wave 2, etc.).
 ```bash
 .claude/skills/parallel-fix-issues/scripts/integrate-worktrees.sh <slug-1> <slug-2> ...
 ```
 El script hace para cada branch:
 1. `git checkout master`
 2. `git merge --no-ff issue/<slug>` con mensaje descriptivo
 3. Si hay **merge conflict**: PARAR e informar al usuario
 **Después de cada merge**, re-verificar que master compila:
 ```bash
 go build -tags goolm ./... && go test -tags goolm ./...
 ```
 Si falla después de un merge, PARAR e informar — no continuar con más merges.
 ### Fase 6: Actualizar README de issues
 Después de integrar TODOS los issues exitosos, actualizar `dev/issues/README.md` **una sola vez** desde master.
 Esto evita conflictos: los agentes paralelos solo mueven archivos, el orquestador actualiza el índice.
 Para cada issue integrado:
 1. Cambiar el link de `[<NNNN>-<slug>.md](<NNNN>-<slug>.md)` a `[<NNNN>-<slug>.md](completed/<NNNN>-<slug>.md)`
 2. Cambiar el estado de `pendiente` a `completado`
 Hacer un solo commit:
 ```bash
 git add dev/issues/README.md
 git commit -m "docs: actualizar README de issues — marcar <N> issues como completados"
 ```
 ### Fase 7: Limpieza
 Si todo fue exitoso:
 ```bash
 # Eliminar worktrees y branches
 for slug in <slugs...>; do
  git worktree remove "worktrees/${slug}" 2>/dev/null
  git branch -d "issue/${slug}" 2>/dev/null
 done
 ```
 ### Fase 8: Reporte final
 Mostrar al usuario un resumen:
 ```
 ## Resultado de parallel-fix-issues
 ### Issues completados
 - ✓ 0026-split-runtime — 5 commits
 - ✓ 0027-prune-config-schema — 3 commits
 - ✓ 0031-expand-file-tools — 7 commits
 ### Issues fallidos
 - ✗ 0029-core-tests — falló en fase de tests (excluido)
 ### Estado de master
 - Build: OK
 - Tests: OK (142 passed)
 - Commits nuevos: 18
 ### Siguiente paso
 Ejecutar: git push
 ```
 ## Notas importantes
 - **Siempre compilar con `-tags goolm`**
 - **Siempre usar `dangerouslyDisableSandbox: true`** en todas las llamadas Bash de los agentes paralelos
 - **Nunca hacer push automáticamente** — el usuario decide cuándo pushear
 - **Si hay merge conflicts**, parar y pedir intervención manual
 - **Un worktree = un issue = una branch** — nunca mezclar
 - Los worktrees se crean desde `master` actualizado
 - La carpeta `worktrees/` está en `.gitignore`
 - Issues con dependencias externas no resueltas se excluyen automáticamente
 - **README centralizado**: los agentes NO tocan `dev/issues/README.md` — solo el orquestador lo actualiza después del merge, en un solo commit. Esto evita merge conflicts entre agentes paralelos
 - **`git mv` para cerrar issues**: usar `git mv` (no `mv` + `git add`) para mover issues a `completed/`
 ## Casos de uso
 ```
 # Implementar todos los issues pendientes
 /parallel-fix-issues all
 # Implementar issues específicos
 /parallel-fix-issues 0026 0027 0031
 # Solo los issues de refactor
 /parallel-fix-issues 0026 0027 0028
 ```
@@ -0,0 +1,117 @@
 #!/bin/bash
 # integrate-worktrees.sh — Integra branches de worktrees a master con --no-ff
 #
 # Uso: ./integrate-worktrees.sh <slug-1> <slug-2> ...
 # Ejemplo: ./integrate-worktrees.sh 0026-split-runtime 0027-prune-config-schema
 #
 # Para cada slug:
 #   1. git merge --no-ff issue/<slug> a master
 #   2. Verificar que master compila después del merge
 #   3. Si hay conflict o fallo de build, PARAR inmediatamente
 #
 # Los slugs deben pasarse en el orden correcto (waves ya resueltas).
 # NO hace push — eso lo decide el usuario.
 set -euo pipefail
 REPO_ROOT="$(git rev-parse --show-toplevel)"
 if [ $# -eq 0 ]; then
  echo "ERROR: se necesita al menos un slug"
  echo "Uso: $0 <slug-1> <slug-2> ..."
  exit 1
 fi
 # Asegurar que estamos en master
 echo "=== Cambiando a master ==="
 cd "$REPO_ROOT"
 git checkout master
 MERGED=0
 FAILED_AT=""
 for slug in "$@"; do
  branch="issue/${slug}"
  echo ""
  echo "=== Integrando: ${branch} ==="
  # Verificar que la branch existe
  if ! git show-ref --verify --quiet "refs/heads/${branch}"; then
    echo "FAIL: branch ${branch} no existe"
    FAILED_AT="$slug"
    break
  fi
  # Merge --no-ff
  if ! git merge --no-ff "$branch" -m "merge: ${branch} — implementación paralela"; then
    echo ""
    echo "CONFLICT: merge de ${branch} tiene conflictos"
    echo "Resolver manualmente y luego continuar con los slugs restantes"
    echo ""
    echo "Para resolver:"
    echo "  1. git status  (ver archivos en conflicto)"
    echo "  2. Resolver conflictos en cada archivo"
    echo "  3. git add <archivos>"
    echo "  4. git commit"
    echo ""
    echo "Slugs pendientes después de ${slug}:"
    FOUND=0
    for remaining in "$@"; do
      if [ "$FOUND" -eq 1 ]; then
        echo "  - ${remaining}"
      fi
      if [ "$remaining" = "$slug" ]; then
        FOUND=1
      fi
    done
    exit 1
  fi
  echo "MERGED: ${branch}"
  # Verificar que master sigue compilando
  echo "--- Verificando build post-merge ---"
  if ! (cd "$REPO_ROOT" && go build -tags goolm ./... 2>&1); then
    echo ""
    echo "FAIL: master no compila después de mergear ${branch}"
    echo "Revertir con: git reset --hard HEAD~1"
    echo "Investigar el problema antes de continuar."
    FAILED_AT="$slug"
    break
  fi
  echo "OK: build post-merge exitoso"
  MERGED=$((MERGED + 1))
 done
 echo ""
 echo "=== Resumen de integración ==="
 echo "Mergeados: ${MERGED} de $#"
 if [ -n "$FAILED_AT" ]; then
  echo "Falló en: ${FAILED_AT}"
  echo ""
  echo "Worktrees NO limpiados (resolver primero el fallo)"
  exit 1
 fi
 # Limpieza de worktrees y branches
 echo ""
 echo "=== Limpieza ==="
 for slug in "$@"; do
  path="${REPO_ROOT}/worktrees/${slug}"
  branch="issue/${slug}"
  if [ -d "$path" ]; then
    git worktree remove "$path" 2>/dev/null && echo "REMOVED: worktree ${path}" || echo "WARN: no se pudo eliminar worktree ${path}"
  fi
  git branch -d "$branch" 2>/dev/null && echo "DELETED: branch ${branch}" || echo "WARN: no se pudo eliminar branch ${branch}"
 done
 echo ""
 echo "=== Integración completa ==="
 echo "Master tiene ${MERGED} merges nuevos."
 echo ""
 echo "Para publicar: git push"
@@ -0,0 +1,76 @@
 #!/bin/bash
 # setup-worktrees.sh — Crea git worktrees para ejecución paralela de issues
 #
 # Uso: ./setup-worktrees.sh <slug-1> <slug-2> ...
 # Ejemplo: ./setup-worktrees.sh 0026-split-runtime 0027-prune-config-schema
 #
 # Cada slug genera:
 #   worktrees/<slug>/  (worktree completo)
 #   branch: issue/<slug>
 set -euo pipefail
 REPO_ROOT="$(git rev-parse --show-toplevel)"
 WORKTREE_DIR="${REPO_ROOT}/worktrees"
 if [ $# -eq 0 ]; then
  echo "ERROR: se necesita al menos un slug de issue"
  echo "Uso: $0 <slug-1> <slug-2> ..."
  exit 1
 fi
 # Asegurar que master está actualizado
 echo "=== Actualizando master ==="
 CURRENT_BRANCH="$(git branch --show-current)"
 git checkout master 2>/dev/null
 git pull --rebase 2>/dev/null || echo "WARN: no se pudo pull (sin remote o sin conexión)"
 # Volver a la rama original si no era master
 if [ "$CURRENT_BRANCH" != "master" ] && [ -n "$CURRENT_BRANCH" ]; then
  git checkout "$CURRENT_BRANCH" 2>/dev/null
 fi
 mkdir -p "$WORKTREE_DIR"
 CREATED=0
 SKIPPED=0
 FAILED=0
 for slug in "$@"; do
  branch="issue/${slug}"
  path="${WORKTREE_DIR}/${slug}"
  if [ -d "$path" ]; then
    echo "SKIP: worktree ya existe: ${path}"
    SKIPPED=$((SKIPPED + 1))
    continue
  fi
  # Verificar que la branch no existe ya
  if git show-ref --verify --quiet "refs/heads/${branch}" 2>/dev/null; then
    echo "WARN: branch ${branch} ya existe, creando worktree desde ella"
    git worktree add "$path" "$branch" 2>/dev/null || {
      echo "FAIL: no se pudo crear worktree para ${slug}"
      FAILED=$((FAILED + 1))
      continue
    }
  else
    echo "CREATE: worktree ${path} (branch ${branch})"
    git worktree add -b "$branch" "$path" master 2>/dev/null || {
      echo "FAIL: no se pudo crear worktree para ${slug}"
      FAILED=$((FAILED + 1))
      continue
    }
  fi
  CREATED=$((CREATED + 1))
 done
 echo ""
 echo "=== Resumen ==="
 echo "Creados: ${CREATED}"
 echo "Existentes: ${SKIPPED}"
 echo "Fallidos: ${FAILED}"
 echo ""
 echo "=== Worktrees activos ==="
 git worktree list
@@ -0,0 +1,88 @@
 #!/bin/bash
 # verify-worktree.sh — Verifica build, tests y cierre de issue en un worktree
 #
 # Uso: ./verify-worktree.sh <worktree-path>
 # Ejemplo: ./verify-worktree.sh worktrees/0026-split-runtime
 #
 # Checks:
 #   1. El worktree existe y tiene commits propios
 #   2. go build -tags goolm ./... compila
 #   3. go test -tags goolm ./... pasa
 #   4. El issue fue movido a completed/
 #
 # Exit codes:
 #   0 = todo OK
 #   1 = error de argumento
 #   2 = build falló
 #   3 = tests fallaron
 #   4 = issue no cerrado
 #   5 = sin commits propios
 set -euo pipefail
 if [ $# -lt 1 ]; then
  echo "ERROR: se necesita el path del worktree"
  echo "Uso: $0 <worktree-path>"
  exit 1
 fi
 WORKTREE="$1"
 # Resolver path absoluto
 if [[ "$WORKTREE" != /* ]]; then
  REPO_ROOT="$(git rev-parse --show-toplevel)"
  WORKTREE="${REPO_ROOT}/${WORKTREE}"
 fi
 if [ ! -d "$WORKTREE" ]; then
  echo "ERROR: worktree no encontrado: ${WORKTREE}"
  exit 1
 fi
 SLUG="$(basename "$WORKTREE")"
 echo "=== Verificando: ${SLUG} ==="
 # 1. Verificar commits propios
 echo "--- Commits propios ---"
 COMMIT_COUNT=$(cd "$WORKTREE" && git log master..HEAD --oneline 2>/dev/null | wc -l)
 if [ "$COMMIT_COUNT" -eq 0 ]; then
  echo "FAIL: sin commits propios en la branch"
  exit 5
 fi
 echo "OK: ${COMMIT_COUNT} commits desde master"
 cd "$WORKTREE" && git log master..HEAD --oneline
 # 2. Build
 echo ""
 echo "--- Build ---"
 if (cd "$WORKTREE" && go build -tags goolm ./... 2>&1); then
  echo "OK: build exitoso"
 else
  echo "FAIL: build falló"
  exit 2
 fi
 # 3. Tests
 echo ""
 echo "--- Tests ---"
 if (cd "$WORKTREE" && go test -tags goolm ./... 2>&1); then
  echo "OK: tests pasaron"
 else
  echo "FAIL: tests fallaron"
  exit 3
 fi
 # 4. Issue cerrado (movido a completed/)
 echo ""
 echo "--- Cierre de issue ---"
 COMPLETED_FILES=$(cd "$WORKTREE" && git diff --name-only master -- dev/issues/completed/ 2>/dev/null | wc -l)
 if [ "$COMPLETED_FILES" -gt 0 ]; then
  echo "OK: issue movido a completed/"
  cd "$WORKTREE" && git diff --name-only master -- dev/issues/completed/
 else
  echo "WARN: no se detectó issue movido a completed/ (verificar manualmente)"
  # No es un error fatal — puede que el issue no siga la convención exacta
 fi
 echo ""
 echo "=== RESULTADO: ${SLUG} — OK ==="
@@ -1,104 +0,0 @@
 ---
 name: parallel-issues
 description: Analiza issues y genera plan de ejecución paralela en PARALLEL_EXECUTION_ORDER.md
 argument-hint: [--dry-run]
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write
 ---
 # parallel-issues
 Analiza issues pendientes y genera plan de ejecución paralela agrupando issues independientes.
 ## Sintaxis
 ```bash
 /parallel-issues              # Genera archivo
 /parallel-issues --dry-run    # Solo muestra análisis
 ```
 ## Cuándo usar
 - Identificar issues paralelizables sin conflictos
 - Planificar desarrollo con múltiples worktrees
 - Antes de sesiones intensivas de desarrollo
 ## Flujo
 ### 1. Detectar contexto
 ```bash
 # Proyecto padre o hijo?
 if [[ "$PWD" == *"/workspaces/"* ]]; then
  PROJECT_TYPE="child"
 else
  PROJECT_TYPE="parent"
 fi
 ```
 ### 2. Listar issues pendientes
 ```bash
 ls -1 dev/issues/*.md | grep -E '[0-9]{4}-.*\.md$' | sort
 ```
 Para cada issue extraer:
 - Número, título, estado
 - Archivos mencionados
 - Dependencias explícitas (#NNNN)
 ### 3. Analizar conflictos
 **Criterios de conflicto (NO paralelizables):**
 - Archivos compartidos
 - Dependencias explícitas
 - Dependencias transitivas
 ### 4. Agrupar por independencia
 Algoritmo de grafos:
 - Grupo 1: Issues sin dependencias
 - Grupo 2: Issues que dependen solo de Grupo 1
 - etc.
 ### 5. Estimar tiempos
 Factores:
 - Cantidad de archivos
 - Capa afectada (core/shell/app)
 - Palabras clave (refactor, fix, nuevo)
 ### 6. Generar PARALLEL_EXECUTION_ORDER.md
 ```markdown
 # Plan de Ejecución Paralela
 ## Grupo 1: Issues Independientes
 - Issue #0003 - ...
 - Issue #0006 - ...
 ## Grupo 2: Dependientes de Grupo 1
 - Issue #0004 - depende de #0003
 ## Resumen
 | Métrica | Valor |
 |---------|-------|
 | Ahorro tiempo | 60% |
 ```
 ### 7. Mostrar resultado
 ```
 Plan generado: PARALLEL_EXECUTION_ORDER.md
 Issues analizadas: N
 Grupos paralelos: M
 Ahorro estimado: X%
 ```
 ## Convenciones
 - Nombres de grupo: "Grupo N"
 - Worktrees: `worktrees/issue-NNNN`
 - Estimación en horas (redondeado a .5)
@@ -1,77 +0,0 @@
 ---
 name: quick-issue
 description: Crea un issue automáticamente desde TUI con detección automática de número
 argument-hint: --text "descripción"
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write, Edit
 ---
 # quick-issue
 Crea un issue rápido desde TUI. **No invocar manualmente** - es para uso automático.
 ## Sintaxis
 ```bash
 /quick-issue --text "descripción del issue"
 ```
 ## Precondiciones
 - [ ] Directorio `dev/issues/` existe
 - [ ] Parámetro `--text` proporcionado
 - [ ] Working tree limpio
 ## Flujo
 ### 1. Determinar número
 ```bash
 ls -1 dev/issues/*.md | grep -E '^dev/issues/[0-9]{4}[a-z]?-' | sort -V
 ```
 Siguiente = último número base + 1 (ignorar letras).
 ### 2. Generar título y slug
 - Título: usar `--text` directamente
 - Slug: convertir a kebab-case
 ### 3. Crear archivo de issue
 Template minimalista con:
 - Metadata básica
 - Objetivo = texto del parámetro
 - Tareas a completar con /fix-issue
 ### 4. Actualizar índice
 Agregar línea en `dev/issues/README.md`.
 ### 5. Crear commits y mergear (sin confirmación)
 ```bash
 git checkout -b quick/quick-issue-NNNN
 git add dev/issues/NNNN-slug.md dev/issues/README.md
 git commit -m "docs: crear issue NNNN-slug"
 git checkout master
 git merge --no-ff quick/quick-issue-NNNN
 git push
 git branch -d quick/quick-issue-NNNN
 ```
 ### 6. Reportar resultado
 ```
 Issue NNNN-slug creado e integrado
 Para implementar:
  /fix-issue NNNN
 ```
 ## Convenciones
 - Auto-detección de número
 - Sin confirmación (flujo automático)
 - Template minimalista
@@ -1,88 +0,0 @@
 ---
 name: sort-issues
 description: Analiza dependencias y genera orden de ejecución óptimo de issues
 disable-model-invocation: true
 user-invocable: true
 allowed-tools: Bash, Read, Write
 ---
 # sort-issues
 Analiza issues, construye grafo de dependencias y muestra/genera orden de ejecución recomendado.
 ## Sintaxis
 ```bash
 /sort-issues
 ```
 ## Flujo
 ### 1. Listar issues pendientes
 ```bash
 ls dev/issues/*.md | grep -E '^dev/issues/[0-9]{4}[a-z]?-.*\.md$' | sort
 ```
 ### 2. Extraer dependencias de cada issue
 Buscar:
 - Tabla "## Dependencias"
 - Línea "Bloqueada por"
 - Referencias #NNNN
 ### 3. Construir grafo y detectar ciclos
 Si hay ciclos:
 ```
 Dependencias circulares detectadas:
  0010 → 0011 → 0012 → 0010
 Revisar:
 - dev/issues/0010-*.md
 - dev/issues/0011-*.md
 ```
 ### 4. Calcular orden topológico
 Algoritmo Kahn o DFS post-order.
 Desempate:
 1. Número menor primero
 2. Issues sin deps primero
 ### 5. Generar EXECUTION_ORDER.md
 ```markdown
 # Execution Order
 ## Recommended Order
 1. #0001 - titulo — razón
 2. #0002 - titulo — razón
 ## Critical Path
 - #0001 → #0002, #0003
 ## Parallelizable Groups
 ### Group 1 (after #0001)
 - #0002
 - #0003
 ```
 ### 6. Mostrar resultado
 ```
 Orden generado: dev/EXECUTION_ORDER.md
 Issues: N
 Camino crítico: #X → #Y → #Z
 Grupos paralelos: M
 Próxima issue: #0001 - titulo
 ```
 ## Convenciones
 - Solo leer issues (no modificar)
 - Detectar ambos formatos de dependencias
 - Reportar ciclos claramente
@@ -9,7 +9,7 @@ REPO_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 CLAUDE_DIR="$HOME/.claude"
 # Carpetas a enlazar (configuración compartible)
-FOLDERS=("skills" "agents")
+FOLDERS=("skills" "agents" "commands")
 echo "=== Instalando configuración de Claude ==="
 echo "Repositorio: $REPO_DIR/.claude"
@@ -188,7 +188,7 @@ echo "=== Instalación completada ==="
 echo "Tus comandos y configuración ahora están sincronizados con el repositorio."
 echo ""
 echo "Configuración instalada:"
-echo "  • Skills y Agents enlazados simbólicamente"
+echo "  • Skills, Agents y Commands enlazados simbólicamente"
 echo "  • Status Line configurada con vibecoding setup"
 echo "  • Settings.json enlazado (compartido entre repos)"
 echo "  • Backups viejos limpiados (>7 días)"