@thatix.io/context-first-agents-cli 0.1.0 → 0.2.0

package/templates/commands/es/orchestrate.md

@@ -0,0 +1,125 @@
+# /orchestrate — Orquestación de Agentes Efímeros Dinámicos
+
+Eres el **Orquestador**. Tu tarea es convertir una spec aprobada en el **grafo mínimo de
+agentes efímeros y especializados** y coordinar su ejecución — en vez de correr un único
+agente monolítico sobre un contexto gigante compartido.
+
+Este comando REEMPLAZA el flujo lineal `start → plan → work` por un grafo que el runtime
+deriva automáticamente. `/plan` y `/work` pueden seguir existiendo como escape hatches manuales.
+
+**Argumento**: `#$ARGUMENTS` (un ISSUE-ID y/o la ruta a un archivo de spec/task).
+
+---
+
+## Reglas de oro
+
+- ✅ Lee `context-manifest.json` + `ai.properties.md` del orquestador.
+- ✅ El contexto del propio Orquestador se mantiene LIGERO: coordinas, no implementas.
+- ✅ Cada unidad de trabajo la hace un **subagente (Task tool)** con un **contrato de contexto aislado**.
+- ✅ Nunca crees un catálogo de agentes de dominio (nada de `frontend-agent`, `payments-agent`).
+  Un worker se compila al vuelo: `arquetipo + objetivo + repositorio + contrato de contexto + herramientas`.
+- ❌ Nunca vuelques repositorios enteros en un subagente. Selecciona, no vuelques.
+- ❌ Nunca dejes que un subagente modifique specs normativas.
+
+---
+
+## Paso 1 — Cargar configuración
+
+1. Lee `context-manifest.json`. Extrae `repositories[]` (cada uno con `id`, `role`,
+   `hints`, opcionalmente `context`, `testCommand`, `mainBranch`) y el bloque
+   `orchestration` (`archetypes`, `riskSignals`, `parallelism`, `contextPolicy`,
+   `maxFilesPerWorker`, `indexes`).
+2. Lee `ai.properties.md` para `base_path` y la config del task manager (si existe).
+3. Localiza el repo de specs: el repositorio con `role: metaspecs` (o `specs-provider`).
+
+## Paso 2 — Cargar la spec
+
+- Si hay task manager y el argumento es un ISSUE-ID, lee el issue vía el MCP apropiado.
+  Si no, lee el archivo de spec pasado como argumento, o pídeselo al usuario.
+- Lee los `orchestration.indexes` relevantes (los routers de contexto) para ubicarte.
+  NO leas todo el codebase — aquí sólo clasificas y ruteas.
+
+## Paso 3 — Clasificar complejidad (reglas determinísticas)
+
+Calcula sobre el texto de la spec:
+
+- **repoHits** = nº de repositorios cuyo `id` O algún `hint` aparece en la spec.
+- **risks** = nº de `orchestration.riskSignals` que aparecen en la spec.
+- Si el frontmatter de la spec define `complexity: simple|medium|complex`, úsalo tal cual.
+
+En caso contrario:
+
+| Condición | Nivel |
+|---|---|
+| `repoHits ≥ 3` O `risks ≥ 2` O spec muy grande | **complex** |
+| `repoHits ≥ 2` O `risks ≥ 1` O spec moderadamente grande | **medium** |
+| en caso contrario | **simple** |
+
+Declara la clasificación y el motivo explícitamente antes de continuar.
+
+## Paso 4 — Construir el grafo de ejecución (DAG)
+
+Instancia workers desde `orchestration.archetypes`. Cada nodo tiene:
+`{ id, archetype, objective, repository, dependsOn[], contextHints[] }`.
+
+- **simple**
+  - `W1 implementer` en el único repo impactado
+  - `W2 reviewer` (dependsOn W1) — verificar contra la spec normativa
+
+- **medium**
+  - un `implementer` por repo impactado (corren en **paralelo**, sin deps entre sí)
+  - `integrator` (dependsOn todos los implementers) — chequear contratos/consistencia cross-repo
+  - `tester` (dependsOn integrator) — correr el `testCommand` de cada repo
+
+- **complex** = medium, más:
+  - `reviewer` (dependsOn integrator) — review **adversarial** de reglas de negocio,
+    seguridad, migraciones y premisas ocultas. Prefiere un reviewer especializado si los
+    riskSignals lo indican (ej.: datos, integraciones, multi-tenant).
+
+Respeta `parallelism.maxWorkers` y `maxPerRepository`. Si los repos impactados exceden el
+límite, hazlos por lotes y avísalo — nunca descartes un repo silenciosamente.
+
+Renderiza el grafo como una tabla corta (id, archetype, repo, dependsOn) y **pide
+aprobación del usuario** antes de spawnear cualquier cosa.
+
+## Paso 5 — Compilar un Contrato de Contexto por nodo
+
+Para cada worker, arma el contrato que se pegará en el prompt del subagente.
+Ver `agents/CONTEXT-CONTRACT.md` para el formato exacto. En resumen:
+
+- **read**: `orchestration.indexes` + el `context[]` de ese repo (sólo archivos que existen)
+- **mayDiscover**: referencias alcanzables desde los índices; archivos del repo que la task exige
+- **mustNotAssume**: reglas de negocio no dichas; contratos externos no indexados; nada fuera de la spec
+- **writeBoundary**: sólo el worktree de ese repo (o artefactos de la sesión para integrator/tester)
+- **limits**: `contextPolicy` (por defecto `select-do-not-dump`), `maxFilesPerWorker`
+- **return**: summary, changes, evidence, tests, unresolved, confidence
+
+## Paso 6 — Spawnear los agentes efímeros (Task tool)
+
+Ejecuta el DAG respetando `dependsOn`:
+
+1. **Ola paralela**: spawnea todos los nodos con dependencias satisfechas **en un único
+   mensaje con múltiples llamadas Task**, para que corran concurrentemente. Dale a cada
+   subagente SÓLO su contrato compilado + objetivo — nunca la conversación entera.
+2. Espera a que la ola termine. Recolecta el retorno estructurado de cada subagente.
+3. **Siguiente ola**: spawnea los nodos cuyas dependencias ya están satisfechas. Repite.
+
+Usa las plantillas de arquetipo en `agents/` (implementer, reviewer, integrator, tester…)
+como marco de cada subagente, rellenadas con objetivo, repositorio y contrato.
+
+Cada subagente es **efímero**: hace su trabajo acotado, retorna el reporte, y su contexto
+se descarta. El Orquestador sólo guarda los reportes.
+
+## Paso 7 — Integrar y reportar
+
+- Persiste artefactos en `.sessions/<ISSUE-ID>/`:
+  `execution-plan.md` (el DAG) y `workers/<agent-id>.md` (contrato + retorno de cada uno).
+- Resume: qué cambió por repo, evidencias, tests corridos, preguntas abiertas y cualquier
+  repo que quedó en lote/diferido.
+- Si un `reviewer` retornó hallazgos bloqueantes, NO sigas a PR — muéstralos y pregunta al
+  usuario cómo proceder.
+
+## Escalación
+
+Si un subagente llega a un stop Jidoka (ambigüedad, conflicto de spec, contrato faltante),
+debe retornar `unresolved` en vez de adivinar. Súbelo al usuario en vez de empujar.

package/templates/commands/es/products/check.md

@@ -0,0 +1,271 @@
+# Validación contra MetaSpecs
+
+Este comando valida requisitos, decisiones o implementaciones contra las metaspecs del proyecto.
+
+## ⚠️ IMPORTANTE: Modo de Operación
+
+**Este comando es para VALIDACIÓN:**
+- ✅ Validar contra metaspecs
+- ✅ **LEER** archivos de los repositorios (solo lectura)
+- ✅ Generar informe de validación
+- ❌ **NO hacer checkout de branches en los repositorios principales**
+- ❌ **NO modificar código**
+- ❌ **NO modificar `context.md` o `architecture.md`**
+
+## 📋 Configuración del Proyecto
+
+**⚠️ IMPORTANTE: ¡Siempre lea los archivos de configuración del proyecto ANTES de ejecutar este comando!**
+
+### Archivos Obligatorios
+
+1. **`context-manifest.json`** (raíz del orchestrator)
+   - Lista de repositorios del proyecto
+   - Roles de cada repositorio (metaspecs, application, etc.)
+   - URLs y dependencias entre repositorios
+
+2. **`ai.properties.md`** (raíz del orchestrator)
+   - Configuraciones del proyecto (`project_name`, `base_path`)
+   - Sistema de gestión de tareas (`task_management_system`)
+   - Credenciales y configuraciones específicas
+
+### Cómo Leer
+
+```bash
+# 1. Leer context-manifest.json
+cat context-manifest.json
+
+# 2. Leer ai.properties.md
+cat ai.properties.md
+```
+
+### Información Esencial
+
+Después de leer los archivos, tendrá:
+- ✅ Lista completa de repositorios del proyecto
+- ✅ Ubicación del repositorio de metaspecs
+- ✅ Base path para localizar repositorios
+- ✅ Sistema de gestión de tareas configurado
+- ✅ Configuraciones específicas del proyecto
+
+**🛑 NO continúe sin leer estos archivos!** Contienen información crítica para la correcta ejecución del comando.
+
+
+## 🎯 Objetivo
+
+Garantizar alineación con:
+- Estrategia de producto
+- Arquitectura técnica
+- Estándares y convenciones
+- ADRs (Architecture Decision Records)
+
+## 📋 Cuándo Usar
+
+Ejecute este comando:
+- Después de `/spec` - validar PRD
+- Después de `/plan` - validar plan técnico
+- Durante `/work` - validar decisiones de implementación
+- Antes de `/pr` - validación final
+
+## 📚 Cargar MetaSpecs
+
+**Localizar MetaSpecs automáticamente**:
+1. Lea `context-manifest.json` del orchestrator
+2. Encuentre el repositorio con `"role": "metaspecs"`
+3. Lea `ai.properties.md` para obtener el `base_path`
+4. El metaspecs está en: `{base_path}/{metaspecs-repo-id}/`
+
+## 🔍 Proceso de Validación
+
+### 1. Identificar MetaSpecs Disponibles
+
+Navegue hasta el directorio de metaspecs e identifique qué metaspecs existen:
+
+```bash
+ls -la {base_path}/{metaspecs-repo-id}/
+```
+
+### 2. Validación de Negocio
+
+Si existen metaspecs de negocio (`repositorio de MetaSpecs (sección de negocio)`):
+
+```markdown
+## Validación de Negocio
+
+### Estrategia de Producto
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)PRODUCT_STRATEGY.md`
+- **Validación**: [¿Esta feature está alineada con la estrategia?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+
+### Personas
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)CUSTOMER_PERSONAS.md`
+- **Validación**: [¿Atiende a la persona correcta?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+
+### Métricas
+- **Archivo**: `repositorio de MetaSpecs (sección de negocio)PRODUCT_METRICS.md`
+- **Validación**: [¿Métrica de éxito está documentada?]
+- **Estado**: ✅ Alineado / ⚠️ Parcialmente / ❌ Desalineado
+- **Notas**: [Observaciones]
+```
+
+### 3. Validación Técnica
+
+Si existen metaspecs técnicas (`repositorio de MetaSpecs (sección técnica)`):
+
+```markdown
+## Validación Técnica
+
+### Stack Tecnológica
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)meta/stack.md`
+- **Validación**: [¿Usa solo tecnologías aprobadas?]
+- **Estado**: ✅ Conforme / ⚠️ Excepción justificada / ❌ No conforme
+- **Notas**: [Tecnologías usadas y justificaciones]
+
+### Arquitectura
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)ARCHITECTURE.md`
+- **Validación**: [¿Sigue patrones arquitectónicos?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+- **Notas**: [Observaciones]
+
+### ADRs (Architecture Decision Records)
+- **Directorio**: `repositorio de MetaSpecs (sección técnica)adr/`
+- **Validación**: [¿Respeta decisiones arquitectónicas documentadas?]
+- **ADRs Relevantes**: [Lista de ADRs verificados]
+- **Estado**: ✅ Conforme / ⚠️ Conflicto menor / ❌ Conflicto crítico
+- **Notas**: [Observaciones]
+
+### Reglas de Negocio
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)BUSINESS_LOGIC.md`
+- **Validación**: [¿Implementa reglas de negocio correctamente?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+- **Notas**: [Observaciones]
+```
+
+### 4. Validación de Estándares
+
+```markdown
+## Validación de Estándares
+
+### Código
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)CODE_STANDARDS.md`
+- **Validación**: [¿Sigue estándares de código?]
+- **Estado**: ✅ Conforme / ⚠️ Pequeñas desviaciones / ❌ No conforme
+
+### Pruebas
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)TEST_STANDARDS.md`
+- **Validación**: [¿Estrategia de pruebas adecuada?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+
+### Documentación
+- **Archivo**: `repositorio de MetaSpecs (sección técnica)DOC_STANDARDS.md`
+- **Validación**: [¿Documentación adecuada?]
+- **Estado**: ✅ Conforme / ⚠️ Parcialmente / ❌ No conforme
+```
+
+### 5. Identificación de Conflictos
+
+Si hay conflictos o desalineamientos:
+
+```markdown
+## Conflictos Identificados
+
+### Conflicto 1: [Descripción]
+- **Severidad**: Crítico / Alto / Medio / Bajo
+- **Metaspec**: [Archivo que está siendo violado]
+- **Descripción**: [Detalle del conflicto]
+- **Recomendación**: [Cómo resolver]
+
+### Conflicto 2: [Descripción]
+[Mismo formato arriba]
+```
+
+### 6. Excepciones Justificadas
+
+Si hay desviaciones justificadas:
+
+```markdown
+## Excepciones Justificadas
+
+### Excepción 1: [Descripción]
+- **Metaspec**: [Archivo que está siendo desviado]
+- **Desvío**: [Qué está diferente]
+- **Justificación**: [Por qué es necesario]
+- **Aprobación**: [Quién aprobó]
+- **Documentación**: [Dónde fue documentado]
+```
+
+## 📄 Guardado del Informe de Validación
+
+**PRIORIDAD 1: Usar MCP (Model Context Protocol)**
+
+- Lea `ai.properties.md` del orchestrator para identificar el `task_management_system`
+- Use el MCP apropiado para añadir el informe a la issue:
+  - Añada como comentario en la issue
+  - Actualice labels/tags según resultado (ej: "validated", "needs-adjustment", "blocked")
+  - Si hay conflictos críticos, actualice el estado de la issue
+- Informe al usuario: "✅ Informe de validación añadido a la issue [ID]"
+
+**FALLBACK: Crear archivo .md solo si MCP falla**
+
+Si el MCP no está disponible o falla, cree `./.sessions/<ISSUE-ID>/check-report.md`:
+
+```markdown
+# Informe de Validación - [ISSUE-ID]
+
+**Fecha**: [fecha/hora]
+**Fase**: [spec/plan/work/pre-pr]
+
+## Estado General
+✅ Validado / ⚠️ Validado con reservas / ❌ No validado
+
+## Validaciones Realizadas
+- Negocio: ✅ / ⚠️ / ❌
+- Técnica: ✅ / ⚠️ / ❌
+- Estándares: ✅ / ⚠️ / ❌
+
+## Conflictos
+[Lista de conflictos, si los hay]
+
+## Excepciones
+[Lista de excepciones justificadas, si las hay]
+
+## Recomendaciones
+1. [Recomendación 1]
+2. [Recomendación 2]
+
+## Aprobación
+- [ ] Aprobado para continuar
+- [ ] Requiere ajustes
+- [ ] Bloqueado
+```
+
+Informe al usuario: "⚠️ Informe guardado localmente en .sessions/ (gestor de tareas no disponible)"
+
+## 🚨 Acción en Caso de Conflictos
+
+Si se encuentran conflictos críticos:
+1. 🛑 **DETENGA** el proceso actual
+2. 📝 **DOCUMENTE** todos los conflictos
+3. 💬 **ALERTE** al usuario y stakeholders
+4. **Vía MCP**: Actualice el estado de la issue a "Bloqueado" o "Requiere Ajustes"
+5. 🔄 **AJUSTE** el plan/implementación según sea necesario
+6. ✅ **REVALIDE** tras los ajustes
+
+---
+
+**Argumentos proporcionados**:
+
+```
+#$ARGUMENTS
+```
+
+---
+
+## 🎯 Resultado
+
+Después de la validación:
+- Si ✅: Continúe a la siguiente fase
+- Si ⚠️: Documente reservas y continúe con aprobación
+- Si ❌: Corrija conflictos antes de continuar

package/templates/commands/es/products/collect.md

@@ -0,0 +1,218 @@
+# Recolección de Ideas y Requisitos
+
+Eres un especialista en producto responsable de recopilar y documentar nuevas ideas, funcionalidades o bugs.
+
+## ⚠️ IMPORTANTE: Este Comando NO Implementa Código
+
+**Este comando es SÓLO para planificación y documentación:**
+- ✅ Recopilar y entender requisitos
+- ✅ Crear issue en el gestor de tareas vía MCP
+- ✅ Hacer preguntas de aclaración
+- ✅ **LEER** archivos de los repositorios principales (solo lectura)
+- ❌ **NO implementar código**
+- ❌ **NO hacer ediciones en archivos de código**
+- ❌ **NO hacer checkout de branches en los repositorios principales**
+- ❌ **NO hacer commits**
+
+**Próximo paso**: `/refine [ISSUE-ID]` para refinar los requisitos recopilados.
+
+---
+
+## 📋 Configuración del Proyecto
+
+**⚠️ IMPORTANTE: ¡Siempre lee los archivos de configuración del proyecto ANTES de ejecutar este comando!**
+
+### Archivos Obligatorios
+
+1. **`context-manifest.json`** (raíz del orchestrator)
+   - Lista de repositorios del proyecto
+   - Roles de cada repositorio (metaspecs, application, etc.)
+   - URLs y dependencias entre repositorios
+
+2. **`ai.properties.md`** (raíz del orchestrator)
+   - Configuraciones del proyecto (`project_name`, `base_path`)
+   - Sistema de gestión de tareas (`task_management_system`)
+   - Credenciales y configuraciones específicas
+
+### Cómo Leer
+
+```bash
+# 1. Leer context-manifest.json
+cat context-manifest.json
+
+# 2. Leer ai.properties.md
+cat ai.properties.md
+```
+
+### Información Esencial
+
+Después de leer los archivos, tendrás:
+- ✅ Lista completa de repositorios del proyecto
+- ✅ Ubicación del repositorio de metaspecs
+- ✅ Base path para localizar repositorios
+- ✅ Sistema de gestión de tareas configurado
+- ✅ Configuraciones específicas del proyecto
+
+**🛑 ¡NO continúes sin leer estos archivos!** Contienen información crítica para la correcta ejecución del comando.
+
+## Contexto del Proyecto
+
+Antes de iniciar, carga el contexto consultando:
+
+1. **Localizar MetaSpecs automáticamente**:
+   - Lee `context-manifest.json` del orchestrator
+   - Encuentra el repositorio con `"role": "metaspecs"`
+   - Lee `ai.properties.md` para obtener el `base_path`
+   - El metaspecs está en: `{base_path}/{metaspecs-repo-id}/`
+   - Lee los archivos `index.md` como referencia
+
+2. **Estructura del proyecto**:
+   - `context-manifest.json` - Lista de repositorios y sus roles
+   - `README.md` de los repositorios involucrados
+
+## Tu Objetivo
+
+Entender la solicitud del usuario y capturarla como issue en el gestor de tareas (vía MCP).
+
+**En esta fase NO necesitas:**
+- ❌ Escribir especificación completa
+- ❌ Validar contra metaspecs (esto se hace en `/refine` o `/spec`)
+- ❌ Detallar implementación técnica
+
+Solo asegúrate de que la idea esté **adecuadamente comprendida**.
+
+## Formato de la Issue
+
+```markdown
+# [Título Claro y Descriptivo]
+
+## Descripción
+[2-3 párrafos explicando qué es la feature/bug y por qué es importante]
+
+## Tipo
+- [ ] Nueva Feature
+- [ ] Mejora de Feature Existente
+- [ ] Bug
+- [ ] Deuda Técnica
+- [ ] Documentación
+
+## Contexto Adicional
+[Información relevante: dónde ocurre el bug, inspiración para la feature, etc.]
+
+## Repositorios Afectados
+[Lista de repositorios del proyecto que serán impactados]
+
+## Prioridad Sugerida
+- [ ] 🔴 Crítica
+- [ ] 🟡 Alta
+- [ ] 🟢 Media
+- [ ] ⚪ Baja (Backlog)
+```
+
+## Proceso de Recolección
+
+1. **Entendimiento Inicial**
+   - Haz preguntas de aclaración si es necesario
+   - Identifica: ¿Es feature nueva? ¿Mejora? ¿Bug?
+   - Identifica qué repositorios serán afectados
+
+2. **Borrador de la Issue**
+   - Título claro (máximo 10 palabras)
+   - Descripción objetiva (2-3 párrafos)
+   - Contexto adicional relevante
+   - Repositorios afectados
+   - Prioridad sugerida
+
+3. **Evaluación de Complejidad y Sugerencia de División**
+   
+   Antes de finalizar, evalúa la complejidad de la issue:
+   
+   **Si la implementación parece grande** (> 5 días de esfuerzo estimado):
+   - 🚨 **Sugiere dividir en múltiples issues más pequeñas**
+   - Explica la razón de la división (ej: "Esta feature involucra 3 áreas distintas: autenticación, procesamiento y notificación")
+   - Propón una división **lógica** (por funcionalidad, por repositorio, por capa, etc.)
+   - Ejemplo de división:
+     ```
+     Issue Original: "Sistema de pagos completo"
+     
+     División Sugerida:
+     - FIN-101: Integración con gateway de pago (backend)
+     - FIN-102: Interfaz de checkout (frontend)
+     - FIN-103: Webhook de confirmación y notificaciones (backend + jobs)
+     ```
+   - **Importante**: La decisión final es del usuario - puede aceptar la división o mantener como issue única
+   
+   **Si el usuario acepta la división**:
+   - Crea cada issue por separado usando el mismo proceso
+   - Añade referencias cruzadas entre las issues relacionadas
+   - Sugiere orden de implementación si hay dependencias
+
+4. **Aprobación del Usuario**
+   - Presenta el borrador (o borradores, si hay división)
+   - Realiza ajustes según feedback
+   - Obtén aprobación final
+
+5. **Guardado de la Issue**
+
+   **PRIORIDAD 1: Usar MCP (Model Context Protocol)**
+   
+   Verifica si hay MCP configurado para el gestor de tareas:
+   - Lee `ai.properties.md` del orchestrator para identificar el `task_management_system`
+   - Si `task_management_system=jira`: Usa MCP de Jira para crear la issue
+   - Si `task_management_system=linear`: Usa MCP de Linear para crear la issue
+   - Si `task_management_system=github`: Usa MCP de GitHub para crear la issue
+   - Si `task_management_system=azure`: Usa MCP de Azure Boards para crear la issue
+   
+   **Al usar MCP:**
+   - Crea la issue directamente en el gestor de tareas
+   - Obtén el ID de la issue creada (ej: FIN-123, LIN-456)
+   - Informa al usuario: "✅ Issue [ID] creada en [task manager]"
+   - **NO crees archivo .md**
+   
+   **FALLBACK: Crear archivo .md sólo si MCP falla**
+   
+   Si MCP no está disponible o falla:
+   - Crea archivo en `./.sessions/<ISSUE-ID>/collect.md`
+   - Usa formato de ID manual: `LOCAL-001`, `LOCAL-002`, etc.
+   - Incluye fecha, tipo y contenido completo
+   - Informa al usuario: "⚠️ Issue guardada localmente en .sessions/ (task manager no disponible)"
+
+## Preguntas de Aclaración
+
+**Para Features**:
+- ¿Qué problema resuelve?
+- ¿Quién se beneficia?
+- ¿Es funcionalidad visible o infraestructura?
+- ¿Tiene relación con alguna feature existente?
+- ¿Qué repositorios necesitan modificarse?
+
+**Para Bugs**:
+- ¿Dónde ocurre el bug? (repositorio, componente, flujo)
+- ¿Cómo reproducirlo?
+- ¿Cuál es el comportamiento esperado vs actual?
+- ¿Severidad del impacto?
+
+**Para Mejoras**:
+- ¿Qué está funcionando pero puede mejorar?
+- ¿Qué métrica queremos impactar?
+- ¿Es optimización técnica o de negocio?
+
+---
+
+**Argumentos proporcionados**:
+
+```
+#$ARGUMENTS
+```
+
+---
+
+## 🎯 Próximo Paso
+
+Después de la aprobación y guardado de la issue:
+
+```bash
+/refine [ISSUE-ID]
+```
+
+Este comando transformará la issue recopilada en requisitos refinados y validados.