# 0010 — Consolidar Skills de Issues en una Skill Unificada ## Metadata | Campo | Valor | |-------|-------| | **ID** | 0010 | | **Estado** | 🟡 pendiente | | **Prioridad** | media | | **Tipo** | refactor | ## Dependencias Ninguna. **Desbloquea:** mejor mantenibilidad del sistema de skills --- ## Objetivo Consolidar las 6 skills de gestión de issues (`create-issue`, `auto-create`, `quick-issue`, `fix-issue`, `auto-fix`, `issues-status`) en 2 skills unificadas con flags, reduciendo duplicación y simplificando el mantenimiento. ## Contexto - Actualmente hay 3 variantes de creación (`create-issue`, `auto-create`, `quick-issue`) que difieren solo en el nivel de confirmación - Hay 2 variantes de implementación (`fix-issue`, `auto-fix`) que difieren solo en confirmación - Las 3 skills de análisis/ejecución paralela (`sort-issues`, `parallel-issues`, `execute-parallel`) son un pipeline secuencial que podría ser un solo flujo - Mantener 6+ skills con lógica casi idéntica genera drift y bugs silenciosos ## Arquitectura ``` skills/ ├── issue/SKILL.md — NUEVA: unifica create + auto-create + quick-issue ├── fix/SKILL.md — NUEVA: unifica fix-issue + auto-fix ├── issues-status/SKILL.md — SE MANTIENE (es diferente) ├── parallel-pipeline/SKILL.md — NUEVA: unifica sort + parallel + execute │ ├── create-issue/ — DEPRECAR ├── auto-create/ — DEPRECAR ├── quick-issue/ — DEPRECAR ├── fix-issue/ — DEPRECAR ├── auto-fix/ — DEPRECAR ├── sort-issues/ — DEPRECAR ├── parallel-issues/ — DEPRECAR └── execute-parallel/ — DEPRECAR ``` ## Tareas ### Fase 1: Skill `/issue` unificada - [ ] **1.1** Crear `skills/issue/SKILL.md` que acepte flags: - `/issue` → modo interactivo con confirmación (actual `create-issue`) - `/issue --auto` → sin confirmación (actual `auto-create`) - `/issue --quick --text "descripción"` → minimal desde TUI (actual `quick-issue`) - [ ] **1.2** Extraer lógica común: detección de número, slug, template, git integration - [ ] **1.3** Tests: verificar los 3 modos producen el mismo resultado ### Fase 2: Skill `/fix` unificada - [ ] **2.1** Crear `skills/fix/SKILL.md` que acepte flags: - `/fix ` → modo interactivo con confirmación (actual `fix-issue`) - `/fix --auto` → sin confirmación (actual `auto-fix`) - [ ] **2.2** Extraer lógica común: lectura de issue, branch, implementación, tests, cierre ### Fase 3: Skill `/parallel` unificada - [ ] **3.1** Crear `skills/parallel-pipeline/SKILL.md` que combine: - Análisis de dependencias (actual `sort-issues`) - Generación de plan paralelo (actual `parallel-issues`) - Ejecución con worktrees (actual `execute-parallel`) - [ ] **3.2** Flags: `--dry-run`, `--group N`, `--sequential`, `--plan-only` ### Fase 4: Migración y limpieza - [ ] **4.1** Mantener skills antiguas como aliases temporales (1 semana) - [ ] **4.2** Eliminar skills deprecadas - [ ] **4.3** Actualizar `skills/README.md` - [ ] **4.4** Actualizar documentación en issues que referencien las skills antiguas ## Ejemplo de uso ```bash # Antes (3 skills distintas): /create-issue /auto-create /quick-issue --text "bug en parser" # Después (1 skill con flags): /issue /issue --auto /issue --quick --text "bug en parser" # Antes (2 skills distintas): /fix-issue 0010 /auto-fix 0010 # Después: /fix 0010 /fix 0010 --auto ``` ## Decisiones de diseño - **Flags sobre skills separadas**: Reduce de 8 skills a 3, misma funcionalidad. El flag `--auto` es más intuitivo que recordar `auto-fix` vs `fix-issue` - **`issues-status` se mantiene separada**: Es un dashboard de consulta, no comparte lógica con creación/implementación - **Pipeline paralelo como skill única**: sort → plan → execute es siempre secuencial, no tiene sentido invocarlos por separado ## Criterios de aceptación - [ ] Las 3 nuevas skills cubren 100% de la funcionalidad de las 8 antiguas - [ ] Los flags son consistentes entre skills (`--auto`, `--dry-run`) - [ ] Skills antiguas eliminadas sin romper nada - [ ] README.md de skills actualizado