context-first-cli 2.0.4 → 2.0.6

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

@@ -1,16 +1,16 @@
 # Recolección de Ideas y Requisitos
 
-Usted es un experto en producto responsable de recopilar y documentar nuevas ideas, features o bugs.
+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 SOLO para planificación y documentación:**
+**Este comando es SÓLO para planificación y documentación:**
 - ✅ Recopilar y entender requisitos
-- ✅ Crear issue en el task manager vía MCP
+- ✅ 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 editar archivos de código**
+- ❌ **NO hacer ediciones en archivos de código**
 - ❌ **NO hacer checkout de branches en los repositorios principales**
 - ❌ **NO hacer commits**
 
@@ -20,29 +20,29 @@ Usted es un experto en producto responsable de recopilar y documentar nuevas ide
 
 ## Contexto del Proyecto
 
-Antes de iniciar, cargue el contexto consultando:
+Antes de comenzar, carga el contexto consultando:
 
 1. **Localizar MetaSpecs automáticamente**:
-   - Lea `context-manifest.json` del orchestrator
-   - Encuentre el repositorio con `"role": "metaspecs"`
-   - Lea `ai.properties.md` para obtener el `base_path`
+   - Lee `context-manifest.json` del orquestador
+   - Encuentra el repositorio con `"role": "metaspecs"`
+   - Lee `ai.properties.md` para obtener el `base_path`
    - El metaspecs está en: `{base_path}/{metaspecs-repo-id}/`
-   - Lea los archivos `index.md` como referencia
+   - Lee los archivos `index.md` como referencia
 
 2. **Estructura del proyecto**:
    - `context-manifest.json` - Lista de repositorios y sus funciones
    - `README.md` de los repositorios involucrados
 
-## Su Objetivo
+## Tu Objetivo
 
-Entender la solicitud del usuario y capturarla como issue en el task manager (vía MCP).
+Entender la solicitud del usuario y capturarla como issue en el gestor de tareas (vía MCP).
 
-**En esta fase, usted NO necesita:**
+**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úrese de que la idea esté **adecuadamente comprendida**.
+Solo asegúrate de que la idea esté **adecuadamente comprendida**.
 
 ## Formato de la Issue
 
@@ -50,20 +50,20 @@ Solo asegúrese de que la idea esté **adecuadamente comprendida**.
 # [Título Claro y Descriptivo]
 
 ## Descripción
-[2-3 párrafos explicando qué es la feature/bug y por qué es importante]
+[2-3 párrafos explicando qué es la funcionalidad/bug y por qué es importante]
 
 ## Tipo
-- [ ] Nueva Feature
-- [ ] Mejora de Feature Existente
+- [ ] Nueva Funcionalidad
+- [ ] Mejora de Funcionalidad Existente
 - [ ] Bug
-- [ ] Tech Debt
+- [ ] Deuda Técnica
 - [ ] Documentación
 
 ## Contexto Adicional
-[Información relevante: dónde ocurre el bug, inspiración para la feature, etc.]
+[Información relevante: dónde ocurre el bug, inspiración para la funcionalidad, etc.]
 
 ## Repositorios Afectados
-[Liste qué repositorios del proyecto serán impactados]
+[Lista de los repositorios del proyecto que serán impactados]
 
 ## Prioridad Sugerida
 - [ ] 🔴 Crítica
@@ -75,9 +75,9 @@ Solo asegúrese de que la idea esté **adecuadamente comprendida**.
 ## Proceso de Recolección
 
 1. **Entendimiento Inicial**
-   - Haga preguntas de aclaración si es necesario
-   - Identifique: ¿Es feature nueva? ¿Mejora? ¿Bug?
-   - Identifique qué repositorios serán afectados
+   - Haz preguntas de aclaración si es necesario
+   - Identifica: ¿Es funcionalidad nueva? ¿Mejora? ¿Bug?
+   - Identifica qué repositorios serán afectados
 
 2. **Borrador de la Issue**
    - Título claro (máximo 10 palabras)
@@ -86,47 +86,71 @@ Solo asegúrese de que la idea esté **adecuadamente comprendida**.
    - Repositorios afectados
    - Prioridad sugerida
 
-3. **Aprobación del Usuario**
-   - Presente el borrador
-   - Haga ajustes según feedback
-   - Obtenga aprobación final
+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 funcionalidad 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 completo de pagos"
+     
+     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
 
-4. **Guardado de la Issue**
+5. **Guardado de la Issue**
 
    **PRIORIDAD 1: Usar MCP (Model Context Protocol)**
    
-   Verifique si hay MCP configurado para task manager:
-   - Lea `ai.properties.md` del orchestrator para identificar el `task_management_system`
-   - Si `task_management_system=jira`: Use MCP de Jira para crear la issue
-   - Si `task_management_system=linear`: Use MCP de Linear para crear la issue
-   - Si `task_management_system=github`: Use MCP de GitHub para crear la issue
+   Verifica si hay MCP configurado para el gestor de tareas:
+   - Lee `ai.properties.md` del orquestador 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
    
    **Al usar MCP:**
-   - Cree la issue directamente en el task manager
-   - Obtenga el ID de la issue creada (ej: FIN-123, LIN-456)
-   - Informe al usuario: "✅ Issue [ID] creada en [task manager]"
-   - **NO cree archivo .md**
+   - 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 solo si MCP falla**
+   **FALLBACK: Crear archivo .md sólo si MCP falla**
    
-   Si el MCP no está disponible o falla:
-   - Cree archivo en `./.sessions/<ISSUE-ID>/collect.md`
-   - Use formato de ID manual: `LOCAL-001`, `LOCAL-002`, etc.
-   - Incluya fecha, tipo y contenido completo
-   - Informe al usuario: "⚠️ Issue guardada localmente en .sessions/ (task manager no disponible)"
+   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/ (gestor de tareas no disponible)"
 
 ## Preguntas de Aclaración
 
-**Para Features**:
+**Para Funcionalidades**:
 - ¿Qué problema resuelve?
 - ¿Quién se beneficia?
 - ¿Es funcionalidad visible o infraestructura?
-- ¿Tiene relación con alguna feature existente?
+- ¿Tiene relación con alguna funcionalidad existente?
 - ¿Qué repositorios necesitan ser modificados?
 
 **Para Bugs**:
 - ¿Dónde ocurre el bug? (repositorio, componente, flujo)
-- ¿Cómo reproducir?
+- ¿Cómo reproducirlo?
 - ¿Cuál es el comportamiento esperado vs actual?
 - ¿Severidad del impacto?
 
@@ -147,10 +171,10 @@ Solo asegúrese de que la idea esté **adecuadamente comprendida**.
 
 ## 🎯 Próximo Paso
 
-Después de aprobación y guardado de la issue:
+Tras la aprobación y guardado de la issue:
 
 ```bash
 /refine [ISSUE-ID]
 ```
 
-Este comando transformará la issue recopilada en requisitos refinados y validados.
+Este comando transformará la issue recopilada en requisitos refinados y validados.

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

@@ -11,7 +11,7 @@ Eres un especialista en producto encargado de ayudar a refinar requisitos para e
 - ✅ Actualizar issue en el task manager
 - ❌ **NO implementar código**
 - ❌ **NO hacer ediciones en archivos de código**
-- ❌ **NO ejecutar pruebas ni deploy**
+- ❌ **NO ejecutar pruebas o deploy**
 
 **Próximo paso**: `/spec [ISSUE-ID]` para crear PRD completo basado en los requisitos refinados.
 
@@ -56,7 +56,7 @@ Continúa haciendo preguntas hasta tener entendimiento completo.
 4. **Valida el requisito** contra las metaspecs leídas:
    - ✅ Alineación con estrategia y visión de producto
    - ✅ Atiende necesidades de las personas correctas
-   - ✅ Compatible con stack tecnológica aprobada
+   - ✅ Compatible con stack tecnológico aprobado
    - ✅ Respeta decisiones arquitecturales (ADRs)
    - ✅ Sigue reglas de negocio existentes
    - ⚠️ Identifica conflictos o violaciones
@@ -72,10 +72,39 @@ Una vez que hayas recopilado información suficiente y validado contra metaspecs
 - **Alcance**: Qué INCLUYE y qué NO INCLUYE
 - **Componentes Afectados**: Lista basada en la arquitectura actual (consulta metaspecs técnicas)
 - **Validación contra Metaspecs**: ✅ Aprobado / ⚠️ Atención necesaria
+- **Estimación de Esfuerzo**: Pequeño (< 1 día) / Medio (1-3 días) / Grande (3-5 días) / Muy Grande (> 5 días)
+
+**Evaluación de Complejidad y Sugerencia de División**:
+
+**Si la implementación parece grande** (> 5 días de esfuerzo estimado):
+- 🚨 **Sugiere dividir en múltiples issues menores**
+- Explica el racional de la división (ej: "Esta feature involucra 3 áreas distintas que pueden implementarse independientemente")
+- Propón una división **lógica** basada en:
+  - Funcionalidades independientes
+  - Repositorios diferentes
+  - Capas de la aplicación (backend, frontend, infra)
+  - Fases de implementación (MVP, mejoras, optimizaciones)
+- Ejemplo de división:
+  ```
+  Issue Original: "Sistema de notificaciones multi-canal"
+  
+  División Sugerida:
+  - FIN-201: Infraestructura de colas y workers (backend)
+  - FIN-202: Notificaciones por email (backend + templates)
+  - FIN-203: Notificaciones push (backend + mobile)
+  - FIN-204: Preferencias de notificación (frontend + backend)
+  ```
+- **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**:
+- Documenta cada issue por separado
+- Añade referencias cruzadas entre las issues relacionadas
+- Sugiere orden de implementación si hay dependencias
+- Cada issue dividida debe pasar por el mismo proceso de refinamiento
 
 Pide aprobación del usuario e incorpora feedback si es necesario.
 
-**Consejo**: Puedes investigar en el código base o internet antes de finalizar, si es necesario.
+**Consejo**: Puedes buscar en el código base o internet antes de finalizar, si es necesario.
 
 ### 4. Guardado de los Requisitos Refinados
 
@@ -92,34 +121,34 @@ Una vez que el usuario apruebe, guarda los requisitos:
 
 2. **Si el task manager está configurado** (lee `ai.properties.md` para identificar `task_management_system`):
    - Identifica la herramienta MCP del task manager
-   - **Actualiza el BODY (descripción) de la issue** con versión CONCISA de los requisitos refinados
+   - **Actualiza el BODY (description) de la issue** con versión CONCISA de los requisitos refinados
      - Para Jira: Usa MCP de Jira con campo `description`
      - Para Linear: Usa MCP de Linear con campo `description`
      - Para GitHub: Usa MCP de GitHub con campo `body`
-     - **IMPORTANTE**: Crea versión RESUMIDA (máx 3000 palabras) para evitar problemas con límites de API
-     - Incluye enlace al archivo local al final: "Documento completo: `.sessions/<ISSUE-ID>/refined.md`"
-   - **SIEMPRE sobrescribe** el body existente (no agregues al final)
+     - Incluye todo el contenido refinado en el campo description/body de la issue
+     - Si el contenido es muy extenso y hay error de API, considera crear versión resumida
+   - **SIEMPRE sobrescribe** el body existente (no agregar al final)
 
 **Observación**:
 - El backup local SIEMPRE está guardado y completo
 - Si hay error de API, verifica manualmente si la issue fue actualizada en el task manager
 
-**Plantilla de Salida**:
+**Template de Salida**:
 
-**IMPORTANTE**: La plantilla estándar para requisitos refinados puede estar documentada en el repositorio de metaspecs. Consulta `{base_path}/{metaspecs-id}/specs/refined/` o similar.
+**IMPORTANTE**: El template estándar para requisitos refinados puede estar documentado en el repositorio de metaspecs. Consulta `{base_path}/{metaspecs-id}/specs/refined/` o similar.
 
-**Plantilla COMPLETA** (para backup local `.sessions/<ISSUE-ID>/refined.md`):
+**Template COMPLETO** (para backup local `.sessions/<ISSUE-ID>/refined.md`):
 - **Metadatos**: Issue, ID, Task Manager, Proyecto, Fecha, Sprint, Prioridad
 - **🎯 POR QUÉ**: Razones, valor de negocio, métrica, persona, alineamiento estratégico
 - **📦 QUÉ**: Funcionalidades detalladas, componentes afectados, integraciones, alcance negativo completo
-- **🔧 CÓMO**: Stack, patrones de código, estructura de archivos, dependencias, orden de implementación, modos de fallo, consideraciones de performance/costo/UX
+- **🔧 CÓMO**: Stack, patrones de código, estructura de archivos, dependencias, orden de implementación, failure modes, consideraciones de performance/costo/UX
 - **✅ Validación contra Metaspecs**: Documentos consultados (business y technical), ADRs verificados, resultado de la validación
 - **📊 Métricas de Éxito**: Técnicas, producto/UX, criterios de aceptación
 - **🔄 Impacto en el Producto**: Alineamiento con objetivos, habilitadores, riesgos mitigados
 - **⚠️ Limitaciones Conocidas**: Limitaciones del MVP
-- **📝 Checklist de Implementación**: Tareas por área (backend, frontend, pruebas, seguridad, etc.)
+- **📝 Checklist de Implementación**: Tareas por área (backend, frontend, tests, seguridad, etc.)
 
-**Plantilla RESUMIDA** (para task manager - máx 3000 palabras):
+**Template para Task Manager**:
 ```markdown
 # [Nombre Feature] - Requisitos Refinados
 
@@ -140,25 +169,25 @@ Una vez que el usuario apruebe, guarda los requisitos:
 - Componente 2: [tipo de cambio]
 
 ### Seguridad
-✅ [item 1] ✅ [item 2] ✅ [item 3]
+✅ [ítem 1] ✅ [ítem 2] ✅ [ítem 3]
 
 ## Alcance Negativo
-❌ [item 1] ❌ [item 2] ❌ [item 3]
+❌ [ítem 1] ❌ [ítem 2] ❌ [ítem 3]
 
 ## Stack
 [Tech stack resumida por área]
 
 ## Estructura
-[Árbol de archivos RESUMIDO - principales módulos solamente]
+[Árbol de archivos RESUMIDO - módulos principales solamente]
 
-## Modos de Fallo (Evitar)
+## Failure Modes (Evitar)
 🔴 [crítico 1] 🔴 [crítico 2]
 🟡 [medio 1] 🟡 [medio 2]
 
 ## Criterios de Aceptación
-- [ ] [item 1]
-- [ ] [item 2]
-- [ ] [item 3]
+- [ ] [ítem 1]
+- [ ] [ítem 2]
+- [ ] [ítem 3]
 
 ## Validación
 **ADRs**: [lista]
@@ -186,7 +215,7 @@ Una vez que el usuario apruebe, guarda los requisitos:
 
 ## 🎯 Próximo Paso
 
-**Tras aprobación del usuario y guardado de los requisitos refinados**, el flujo natural es:
+**Tras la aprobación del usuario y guardado de los requisitos refinados**, el flujo natural es:
 
 ```bash
 /spec [ISSUE-ID]

package/templates/commands/pt-BR/products/collect.md

@@ -86,12 +86,36 @@ Apenas certifique-se de que a ideia esteja **adequadamente compreendida**.
    - Repositórios afetados
    - Prioridade sugerida
 
-3. **Aprovação do Usuário**
-   - Apresente o rascunho
+3. **Avaliação de Complexidade e Sugestão de Quebra**
+   
+   Antes de finalizar, avalie a complexidade da issue:
+   
+   **Se a implementação parecer grande** (> 5 dias de esforço estimado):
+   - 🚨 **Sugira quebrar em múltiplas issues menores**
+   - Explique o racional da quebra (ex: "Esta feature envolve 3 áreas distintas: autenticação, processamento e notificação")
+   - Proponha uma quebra **lógica** (por funcionalidade, por repositório, por camada, etc.)
+   - Exemplo de quebra:
+     ```
+     Issue Original: "Sistema de pagamentos completo"
+     
+     Quebra Sugerida:
+     - FIN-101: Integração com gateway de pagamento (backend)
+     - FIN-102: Interface de checkout (frontend)
+     - FIN-103: Webhook de confirmação e notificações (backend + jobs)
+     ```
+   - **Importante**: A decisão final é do usuário - ele pode aceitar a quebra ou manter como issue única
+   
+   **Se o usuário aceitar a quebra**:
+   - Crie cada issue separadamente usando o mesmo processo
+   - Adicione referências cruzadas entre as issues relacionadas
+   - Sugira ordem de implementação se houver dependências
+
+4. **Aprovação do Usuário**
+   - Apresente o rascunho (ou rascunhos, se houver quebra)
    - Faça ajustes conforme feedback
    - Obtenha aprovação final
 
-4. **Salvamento da Issue**
+5. **Salvamento da Issue**
 
    **PRIORIDADE 1: Usar MCP (Model Context Protocol)**
    

package/templates/commands/pt-BR/products/refine.md

@@ -72,6 +72,35 @@ Uma vez que tenha coletado informações suficientes e validado contra metaspecs
 - **Escopo**: O que INCLUI e o que NÃO INCLUI
 - **Componentes Afetados**: Lista baseada na arquitetura atual (consulte metaspecs técnicas)
 - **Validação contra Metaspecs**: ✅ Aprovado / ⚠️ Atenção necessária
+- **Estimativa de Esforço**: Pequeno (< 1 dia) / Médio (1-3 dias) / Grande (3-5 dias) / Muito Grande (> 5 dias)
+
+**Avaliação de Complexidade e Sugestão de Quebra**:
+
+**Se a implementação parecer grande** (> 5 dias de esforço estimado):
+- 🚨 **Sugira quebrar em múltiplas issues menores**
+- Explique o racional da quebra (ex: "Esta feature envolve 3 áreas distintas que podem ser implementadas independentemente")
+- Proponha uma quebra **lógica** baseada em:
+  - Funcionalidades independentes
+  - Repositórios diferentes
+  - Camadas da aplicação (backend, frontend, infra)
+  - Fases de implementação (MVP, melhorias, otimizações)
+- Exemplo de quebra:
+  ```
+  Issue Original: "Sistema de notificações multi-canal"
+  
+  Quebra Sugerida:
+  - FIN-201: Infraestrutura de filas e workers (backend)
+  - FIN-202: Notificações por email (backend + templates)
+  - FIN-203: Notificações push (backend + mobile)
+  - FIN-204: Preferências de notificação (frontend + backend)
+  ```
+- **Importante**: A decisão final é do usuário - ele pode aceitar a quebra ou manter como issue única
+
+**Se o usuário aceitar a quebra**:
+- Documente cada issue separadamente
+- Adicione referências cruzadas entre as issues relacionadas
+- Sugira ordem de implementação se houver dependências
+- Cada issue quebrada deve passar pelo mesmo processo de refinamento
 
 Peça aprovação do usuário e incorpore feedback se necessário.
 
@@ -96,8 +125,8 @@ Uma vez que o usuário aprove, salve os requisitos:
      - Para Jira: Use MCP do Jira com campo `description`
      - Para Linear: Use MCP do Linear com campo `description`
      - Para GitHub: Use MCP do GitHub com campo `body`
-     - **IMPORTANTE**: Crie versão RESUMIDA (máx 3000 palavras) para evitar problemas com limites de API
-     - Inclua link para arquivo local no final: "Documento completo: `.sessions/<ISSUE-ID>/refined.md`"
+     - Inclua todo o conteúdo refinado no campo description/body da issue
+     - Se o conteúdo for muito extenso e houver erro de API, considere criar versão resumida
    - **SEMPRE sobrescrever** o body existente (não adicionar ao final)
 
 **Observação**:
@@ -119,7 +148,7 @@ Uma vez que o usuário aprove, salve os requisitos:
 - **⚠️ Limitações Conhecidas**: Limitações do MVP
 - **📝 Checklist de Implementação**: Tarefas por área (backend, frontend, testes, segurança, etc.)
 
-**Template RESUMIDO** (para task manager - máx 3000 palavras):
+**Template para Task Manager**:
 ```markdown
 # [Nome Feature] - Requisitos Refinados