@onion-architect-ai/cli 4.1.0-beta.3 → 4.1.0-beta.5

package/templates/.cursor/commands/engineer/validate-phase-sync.md

@@ -0,0 +1,118 @@
+---
+name: validate-phase-sync
+description: Validar sincronização entre fases do plan.md e subtasks ClickUp.
+model: sonnet
+category: engineer
+tags: [validation, sync, clickup]
+version: "4.0.0"
+updated: "2025-12-20"
+level: advanced
+context: technical
+---
+
+# 🔄 Validate Phase-Subtask Sync
+
+Validar e corrigir sincronização automática entre fases do plan.md e status das subtasks no ClickUp. Este comando identifica discrepâncias e corrige status desatualizados.
+
+## 🎯 Funcionalidades
+
+### Validação Automática de Status
+- Lê todas as fases do plan.md e identifica status atual (Completada ✅, Em Progresso ⏰, Não Iniciada ⏳)
+- Verifica status das subtasks correspondentes no ClickUp via Phase-Subtask Mapping
+- Identifica discrepâncias entre plan.md e ClickUp
+- Gera relatório de inconsistências encontradas
+
+### Correção Automática de Status
+- Atualiza automaticamente status das subtasks para refletir estado real das fases
+- Adiciona comentários retroativos nas subtasks com timestamp de correção
+- Documenta ações de correção realizadas
+- Valida integridade do mapeamento Phase→Subtask
+
+### Sistema de Alertas Proativo
+- Alerta quando mapeamento Phase-Subtask está ausente ou incompleto
+- Sugere criação de mapeamento quando detecta subtasks sem correlação
+- Identifica fases órfãs (sem subtask correspondente)
+- Reporta subtasks órfãs (sem fase correspondente)
+
+## 🚀 Como Usar
+
+```bash
+/engineer/validate-phase-sync
+```
+
+### Exemplos de Casos de Uso
+```bash
+/engineer/validate-phase-sync                    # Validação geral da sessão ativa
+/engineer/validate-phase-sync --fix-all         # Corrige todas inconsistências encontradas
+/engineer/validate-phase-sync --report-only     # Apenas relatório, não aplica correções
+```
+
+## 🤝 Integração ClickUp MCP
+
+### Operações Automáticas
+- **Leitura de Task**: Usa `get_task` com `subtasks=true` para estrutura completa
+- **Update de Status**: Aplica `update_task` nos subtasks com status correto
+- **Comentários de Correção**: Usa `create_task_comment` para documentar ajustes
+- **Validação de Integridade**: Verifica se mapeamento está correto e completo
+
+### Mapeamento Phase-Subtask
+Lê o mapeamento do arquivo `.cursor/sessions/[slug]/context.md`:
+```markdown
+## 📋 Phase-Subtask Mapping
+- **Phase 1**: "Template Consolidation" → Subtask ID: [id-1]
+- **Phase 2**: "Feature Commands" → Subtask ID: [id-2]
+- **Phase 3**: "Release Commands" → Subtask ID: [id-3]
+```
+
+### Correções Aplicadas
+- Fases "Completada ✅" → Subtask status "done"  
+- Fases "Em Progresso ⏰" → Subtask status "in progress"
+- Fases "Não Iniciada ⏳" → Subtask status "to do"
+
+## ⚙️ Processo de Validação
+
+1. **Detecta Sessão Ativa**: Identifica sessão em `.cursor/sessions/`
+2. **Lê Context.md**: Carrega mapeamento Phase-Subtask e task ID principal
+3. **Analisa Plan.md**: Extrai status atual de todas as fases
+4. **Consulta ClickUp**: Obtém status atual das subtasks via ClickUp MCP
+5. **Identifica Discrepâncias**: Compara status plan.md vs ClickUp
+6. **Aplica Correções**: Atualiza status das subtasks conforme necessário
+7. **Documenta Ações**: Registra todas correções aplicadas
+
+## ⚠️ Resolução de Problemas
+
+### Problema: "Mapeamento Phase-Subtask não encontrado"
+**Solução**: Verificar se context.md contém seção "Phase-Subtask Mapping"
+```bash
+# Execute se necessário:
+/engineer/create-phase-mapping
+```
+
+### Problema: "Subtask não encontrada no ClickUp"
+**Solução**: IDs do mapeamento podem estar incorretos
+- Verificar IDs das subtasks no ClickUp
+- Atualizar mapeamento no context.md
+- Executar validação novamente
+
+### Problema: "Múltiplas fases para mesma subtask"
+**Solução**: Revisar estrutura do projeto
+- Uma subtask deve corresponder a uma fase específica
+- Considerar quebrar fase complexa em múltiplas fases
+
+## 💡 Integração com Workflow
+
+### Uso Recomendado
+- **Durante desenvolvimento**: Executar ao final de cada sessão de trabalho
+- **Antes de PRs**: Validar sincronização completa antes de `/engineer/pr`
+- **Após interrupções**: Garantir consistência após retomar trabalho
+- **Debugging**: Identificar problemas de tracking de progresso
+
+### Prevenção Automática
+Este comando corrige o problema identificado onde `/engineer/work` não atualizava automaticamente os status das subtasks. Para projetos futuros:
+1. `/engineer/start` deve criar o mapeamento automaticamente
+2. `/engineer/work` deve usar este mapeamento para updates automáticos
+3. Este comando serve como backup/validação do processo automático
+
+---
+
+**🎯 CRITICAL FIX: Este comando resolve a falha arquitetural onde fases completadas não atualizavam automaticamente o status das subtasks correspondentes, garantindo sincronização perfeita entre plan.md e ClickUp.**

package/templates/.cursor/commands/engineer/warm-up.md

@@ -0,0 +1,173 @@
+---
+name: warm-up
+description: |
+  Preparação de contexto técnico e de engenharia.
+  Foca em arquitetura, padrões de código, estrutura do projeto, comandos de desenvolvimento e frameworks técnicos.
+model: sonnet
+category: engineer
+tags: [warmup, context, engineering, technical]
+version: "4.0.0"
+updated: "2025-12-20"
+level: starter
+context: technical
+---
+
+# 🔥 Warm-up de Engenharia
+
+Preparação específica para trabalho técnico e de desenvolvimento.
+
+## 🎯 Objetivo
+
+Estabelecer contexto focado em:
+- Arquitetura técnica do projeto
+- Padrões de código e convenções
+- Estrutura de código e organização
+- Comandos e workflows de desenvolvimento
+- Frameworks técnicos e ferramentas
+- Sistema de testes e validação
+
+## 📋 Checklist de Preparação
+
+### 1. Contexto Geral (Base)
+- ✅ Revisar `README.md` para visão geral do Sistema Onion
+- ✅ Entender estrutura de documentação em `docs/`
+
+### 2. Meta Especificações Técnicas
+- ✅ Revisar `docs/meta-specs/index.md`
+- ✅ Focar em:
+  - `architecture.md` (quando disponível) - Padrões arquiteturais
+  - `code-standards.md` (quando disponível) - Padrões de código
+  - `agents.md` (quando disponível) - Padrões para agentes
+  - `commands.md` (quando disponível) - Padrões para comandos
+- ✅ Entender hierarquia de especificações para decisões técnicas
+
+### 3. Documentação Técnica
+- ✅ Revisar `docs/onion/commands-guide.md` - Seção "Comandos de Engenharia"
+- ✅ Revisar `docs/onion/engineering-flows.md` - Fluxos de desenvolvimento
+- ✅ Revisar `docs/onion/testing-validation-system.md` - Sistema de testes
+- ✅ Mapear comandos de engenharia:
+  - `/engineer/start` - Iniciar desenvolvimento (valida story points)
+  - `/engineer/work` - Trabalhar em feature
+  - `/engineer/plan` - Planejar implementação
+  - `/engineer/pre-pr` - Preparar Pull Request
+  - `/engineer/pr` - Criar Pull Request
+  - `/engineer/docs` - Documentar código
+  - `/engineer/warm-up` - Este comando
+
+### 4. Estrutura do Projeto
+- ✅ Mapear estrutura de diretórios do código
+- ✅ Entender organização de módulos/pacotes
+- ✅ Identificar tecnologias principais (linguagens, frameworks)
+- ✅ Localizar arquivos de configuração importantes
+
+### 5. Padrões de Código
+- ✅ Revisar convenções de nomenclatura
+- ✅ Entender estilo de código esperado
+- ✅ Conhecer ferramentas de linting/formatting
+- ✅ Verificar arquivos de configuração (.eslintrc, .prettierrc, etc)
+
+### 6. Knowledge Bases Técnicas
+- ✅ Revisar `docs/knowbase/concepts/spec-as-code-strategy.md`
+- ✅ Revisar `docs/knowbase/concepts/ai-agent-design-patterns.md`
+- ✅ Revisar `docs/knowbase/concepts/abstraction-patterns-catalog.md`
+- ✅ Revisar `docs/knowbase/frameworks/framework_testes.md`
+- ✅ Revisar `docs/knowbase/concepts/context-window-optimization.md`
+
+### 7. Agentes de Desenvolvimento
+- ✅ Conhecer agentes especializados:
+  - `@react-developer` - Desenvolvimento React
+  - `@python-developer` - Desenvolvimento Python
+  - `@nodejs-specialist` - Backend Node.js
+  - `@nx-monorepo-specialist` - Monorepos NX
+  - `@c4-architecture-specialist` - Arquitetura C4
+  - `@test-engineer` - Testes e QA
+  - `@code-reviewer` - Code review
+
+### 8. Sistema de Testes
+- ✅ Revisar `docs/onion/testing-validation-system.md`
+- ✅ Entender comandos de teste:
+  - `/test/unit` - Testes unitários (White-box)
+  - `/test/integration` - Testes de integração (Grey-box)
+  - `/test/e2e` - Testes end-to-end (Black-box)
+- ✅ Conhecer frameworks de teste utilizados
+
+### 9. Git e Versionamento
+- ✅ Revisar comandos Git disponíveis:
+  - `/git/feature/start` - Criar branch de feature
+  - `/git/sync` - Sincronizar após merge
+- ✅ Entender workflow Git do projeto
+- ✅ Conhecer convenções de branching
+
+### 10. Validação de Story Points
+- ✅ Entender que `/engineer/start` valida estimativas
+- ✅ Conhecer processo de validação antes de iniciar desenvolvimento
+- ✅ Saber como lidar com tasks sem estimativas
+
+## 🔍 Contexto Específico de Engenharia
+
+### Documentação Essencial
+- `docs/onion/engineering-flows.md` - Fluxos de desenvolvimento
+- `docs/onion/testing-validation-system.md` - Sistema de testes
+- `docs/onion/commands-guide.md` - Comandos de engenharia
+- `docs/knowbase/frameworks/framework_testes.md` - Framework de testes
+
+### Workflows de Desenvolvimento
+1. **Iniciar**: `/engineer/start` → Valida story points, cria branch, sessão
+2. **Trabalhar**: `/engineer/work` → Loop de desenvolvimento
+3. **Planejar**: `/engineer/plan` → Planejar implementação detalhada
+4. **Pre-PR**: `/engineer/pre-pr` → Preparar Pull Request
+5. **PR**: `/engineer/pr` → Criar Pull Request (testes, build, PR)
+6. **Sync**: `/git/sync` → Sincronizar após merge
+
+### Estrutura de Sessões
+- ✅ Entender `.cursor/sessions/<feature>/` para contexto de trabalho
+- ✅ Conhecer formato de arquivos de sessão
+
+## 💡 Quando Usar Este Warm-up
+
+- ✅ Início de desenvolvimento de feature
+- ✅ Retorno a trabalho técnico após período ausente
+- ✅ Mudança de contexto técnico (nova tecnologia/framework)
+- ✅ Necessidade de entender arquitetura do projeto
+- ✅ Preparação para code review ou refatoração
+
+## 🔗 Integração com Produto
+
+- Tasks vêm de `/product/task` com story points
+- Especificações vêm de `/product/spec`
+- Validação de estimativas antes de iniciar
+- Sincronização com Task Manager durante desenvolvimento
+
+## ⚠️ Notas
+
+- Foco em contexto técnico e de código
+- Mantenha conhecimento de padrões e convenções no contexto
+- Use agentes especializados para tecnologias específicas
+- Sempre valide story points antes de iniciar (`/engineer/start`)
+- Mantenha código sincronizado com Task Manager durante desenvolvimento
+
+---
+
+## 🚀 Próximos Passos
+
+Agora que você preparou o contexto técnico:
+
+1. **Planejar nova feature**:
+   ```bash
+   /technical/plan "feature-name"
+   ```
+   Cria plano de desenvolvimento estruturado.
+
+2. **Ou retomar trabalho existente**:
+   ```bash
+   /technical/work "task-id"
+   ```
+   Continua desenvolvimento de feature em progresso.
+
+3. **Resolver conflitos se necessário**:
+   ```bash
+   /technical/sync
+   ```
+   Sincroniza com remote antes de começar novo trabalho.
+
+💡 **Dica**: Warm-up carrega contexto sobre stack, arquitetura e padrões do projeto - essencial após pausas longas.

package/templates/.cursor/commands/engineer/work.md

@@ -0,0 +1,169 @@
+---
+name: work
+description: |
+  Continuar trabalho em feature ativa. Lê sessão e identifica próxima fase.
+  Atualiza progresso via Task Manager abstraction.
+model: sonnet
+category: engineer
+tags: [development, workflow, session]
+version: "4.0.0"
+updated: "2025-12-20"
+level: starter
+context: technical
+---
+
+# Engineer Work
+
+Estamos atualmente trabalhando em uma funcionalidade que está especificada na seguinte pasta:
+
+<folder>
+#$ARGUMENTS
+</folder>
+
+Para trabalhar nisso, você deve:
+
+- Ler todos os arquivos markdown na pasta
+- Revisar o arquivo plan.md e identificar qual Fase está atualmente em progresso
+- Apresentar ao usuário um plano para abordar a próxima fase
+
+## 🔄 **Auto-Update Task Manager**
+
+Este comando **automaticamente atualiza** a task durante desenvolvimento usando a abstração:
+
+```typescript
+// Detectar provedor e obter adapter
+const config = detectProvider();
+const taskManager = getTaskManager();
+
+if (!taskManager.isConfigured) {
+  console.warn('⚠️ Modo offline - progresso não será sincronizado');
+}
+```
+
+### **✅ Updates Automáticos A CADA FASE:**
+- **Comentário de progresso** quando fase é completada
+- **SUBTASK STATUS UPDATE** - Atualiza status da subtask correspondente para "done"
+- **Atualização do plan.md** com status e decisões
+- **Progresso % estimado** baseado nas fases concluídas
+- **Timestamp de atividade** para tracking temporal
+
+### **🔗 CRITICAL: Phase→Subtask Mapping**
+**OBRIGATÓRIO**: Quando uma fase é completada, o sistema deve:
+1. **Identificar subtask correspondente** via mapeamento estabelecido no context.md
+2. **Atualizar status da subtask** para "done" automaticamente
+3. **Documentar conclusão** com timestamp e métricas da fase
+
+### **💬 Estratégia DUAL de Comentários:**
+
+Ao completar uma fase, o sistema automaticamente:
+
+1. **Cria comentário DETALHADO na SUBTASK**
+2. **Cria comentário RESUMIDO na TASK PRINCIPAL**
+
+### **📋 Identificação da Task:**
+1. **Context.md**: Lê task-id do arquivo de contexto da sessão
+2. **Sessão ativa**: Detecta automaticamente a sessão em `.cursor/sessions/`
+3. **🆕 PHASE-SUBTASK MAPPING**: Lê mapeamento de context.md para correlacionar fases→subtasks
+
+### **🗺️ SUBTASK MAPPING STRUCTURE (context.md):**
+```markdown
+## 📋 Phase-Subtask Mapping
+- **Phase 1**: "Nome da Fase" → Subtask ID: [subtask-id-1]
+- **Phase 2**: "Nome da Fase" → Subtask ID: [subtask-id-2]
+```
+
+### **⚡ AUTOMATIC EXECUTION (Via Abstração):**
+Quando uma fase é marcada como "Completada ✅" no plan.md, o sistema deve **EXECUTAR NESTA ORDEM**:
+
+```typescript
+// 1. Obter task manager
+const taskManager = getTaskManager();
+
+if (taskManager.isConfigured) {
+  // 2. Comentário DETALHADO na SUBTASK
+  await taskManager.addComment(subtaskId, `
+🔧 FASE COMPLETADA: ${phaseName}
+
+━━━━━━━━━━━━━━
+
+📁 ARQUIVOS MODIFICADOS:
+${filesModified.map(f => `   ∟ ${f}`).join('\n')}
+
+🔧 IMPLEMENTAÇÕES:
+${implementations.map(impl => `   ▶ ${impl}`).join('\n')}
+
+💡 DECISÕES TÉCNICAS:
+${decisions.map(d => `   ∟ ${d}`).join('\n')}
+
+🚀 PRÓXIMOS PASSOS:
+   ∟ ${nextPhase}
+
+━━━━━━━━━━━━━━
+
+⏰ Completado: ${timestamp} | 🎯 Status: Done
+  `);
+
+  // 3. Atualizar STATUS da SUBTASK
+  await taskManager.updateStatus(subtaskId, 'done');
+
+  // 4. Comentário RESUMIDO na TASK PRINCIPAL
+  await taskManager.addComment(mainTaskId, `
+📝 PROGRESSO: Fase ${phaseNum}/${totalPhases} Completada
+
+✅ ${phaseName} - Concluída
+   ∟ Subtask: #${subtaskId}
+   ∟ Detalhes: Ver comentário na subtask
+
+🎯 Próximo: Fase ${phaseNum + 1}/${totalPhases} - ${nextPhaseName}
+
+⏰ ${timestamp}
+  `);
+}
+```
+
+## Importante:
+
+Quando você desenvolver o código para a fase atual, use os sub-agentes de desenvolvimento, code-review e teste quando apropriado para preservar o máximo possível do seu contexto.
+
+Toda vez que completar uma fase do plano:
+- **AUTO-UPDATE**: Adicione comentário de progresso via abstração
+- **RASTREAMENTO**: Marque checkboxes na description correspondentes aos critérios completados
+- Pause e peça ao usuário para validar seu código.
+- Faça as mudanças necessárias até ser aprovado
+- Atualize a fase correspondente no arquivo plan.md marcando o que foi feito e adicionando comentários úteis para o desenvolvedor que abordará as próximas fases, especialmente sobre questões, decisões, etc.
+- Apenas inicie a próxima fase após o usuário concordar que você deve começar.
+
+## 🔗 Referências
+
+- Abstração: `.cursor/utils/task-manager/`
+- Detector: `.cursor/utils/task-manager/detector.md`
+- Factory: `.cursor/utils/task-manager/factory.md`
+- Padrões de comentários: `common/prompts/clickup-patterns.md`
+
+Agora, veja a fase atual de desenvolvimento e forneça um plano ao usuário sobre como abordá-la.
+
+
+---
+
+## 🚀 Próximos Passos
+
+Durante o desenvolvimento, você pode precisar de:
+
+1. **Validar antes de finalizar**:
+   ```bash
+   /technical/pre-pr
+   ```
+   Executa linting, testes e validações antes de criar PR.
+
+2. **Criar Pull Request**:
+   ```bash
+   /technical/pr
+   ```
+   Gera PR com descrição automática baseada na sessão de desenvolvimento.
+
+3. **Consultar agentes especializados**:
+   - `@react-developer` para dúvidas de frontend
+   - `@nodejs-specialist` para backend
+   - `@test-engineer` para testes
+
+💡 **Dica**: O comando `/work` rastreia automaticamente seu progresso e atualiza o task manager configurado.

package/templates/.cursor/commands/git/code-review.md

@@ -0,0 +1,215 @@
+---
+name: code-review
+description: |
+  Gerenciador de ChatGPT-CodeReview para setup, validação e otimização.
+  Use para configurar code review automático em projetos.
+model: sonnet
+
+parameters:
+  - name: mode
+    description: Modo de operação (auto/setup/validate/status)
+    required: false
+    default: auto
+
+category: git
+tags:
+  - code-review
+  - automation
+  - ci-cd
+
+version: "4.0.0"
+updated: "2025-12-20"
+
+related_commands:
+  - /engineer/pre-pr
+  - /git/feature/finish
+
+related_agents:
+  - code-reviewer
+  - branch-code-reviewer
+level: intermediate
+context: technical
+---
+
+# 🤖 ChatGPT Code Review Manager
+
+Gerenciador inteligente de ChatGPT-CodeReview para o Sistema Onion.
+
+## 🎯 Objetivo
+
+Automatizar setup, validação e otimização do code review automático.
+
+## ⚡ Modos de Operação
+
+```bash
+/git/code-review           # AUTO: detecta e executa ação apropriada
+/git/code-review setup     # Criar/reconfigurar arquivo
+/git/code-review validate  # Validar configuração existente  
+/git/code-review status    # Mostrar status atual
+```
+
+## 🔄 Fluxo de Execução
+
+### Passo 1: Detectar Modo
+
+```bash
+# Verificar se code-review.yml existe
+test -f .github/workflows/code-review.yml && MODE="validate" || MODE="setup"
+```
+
+SE `{{mode}}` fornecido → usar modo especificado
+SENÃO → usar detecção automática
+
+### Passo 2: Executar Modo
+
+#### 🆕 SETUP MODE
+
+1. **Detectar Stack**
+   ```bash
+   # Package manager
+   test -f pnpm-lock.yaml && PM="pnpm"
+   test -f package-lock.json && PM="npm"
+   
+   # Monorepo
+   test -f nx.json && MONO="nx"
+   
+   # Backend/Frontend
+   grep -q "fastify" package.json && BACKEND="fastify"
+   grep -q "react" package.json && FRONTEND="react"
+   ```
+
+2. **Gerar Template**
+   Criar `.github/workflows/code-review.yml`:
+```yaml
+   name: ChatGPT Code Review
+
+on:
+  pull_request:
+       types: [opened, synchronize]
+
+jobs:
+     review:
+    runs-on: ubuntu-latest
+    steps:
+         - uses: actions/checkout@v4
+         - uses: anc95/ChatGPT-CodeReview@main
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
+   ```
+
+3. **Aplicar Configurações por Stack**
+   - TypeScript → adicionar regras de tipos
+   - React → regras de hooks
+   - NX → regras de monorepo
+
+#### 🔍 VALIDATE MODE
+
+1. **Verificar Arquivo**
+   - Existe?
+   - YAML válido?
+   - Secrets configurados?
+
+2. **Analisar Configuração**
+   Usar checklist de `common/prompts/code-review-checklist.md`
+
+3. **Gerar Relatório**
+   ```
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   📊 CODE REVIEW VALIDATION
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   
+   ✅ Arquivo: .github/workflows/code-review.yml
+   ✅ YAML: Válido
+   ⚠️ Secrets: OPENAI_API_KEY não detectado
+   
+   💡 Recomendações:
+   ∟ Configurar OPENAI_API_KEY em Settings > Secrets
+   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+   ```
+
+#### 📊 STATUS MODE
+
+Mostrar dashboard:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📊 CODE REVIEW STATUS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🔧 Configuração:
+∟ Arquivo: ✅ Configurado
+∟ Stack: TypeScript + React + NX
+∟ Última atualização: 2025-11-24
+
+📈 Métricas (últimos 30 dias):
+∟ PRs revisados: 45
+∟ Issues detectados: 127
+∟ Auto-fixes aplicados: 23
+
+🎯 Saúde: 95% ████████████░░░░░
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Passo 3: Atualizar ClickUp
+
+SE há task associada:
+- Adicionar comentário com resultado
+- Atualizar status se necessário
+
+## 📤 Output Esperado
+
+### Setup Sucesso
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ CODE REVIEW CONFIGURADO
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📁 Criado: .github/workflows/code-review.yml
+
+🔧 Stack Detectado:
+∟ Package Manager: pnpm
+∟ Monorepo: NX
+∟ Backend: Fastify
+∟ Frontend: React
+
+⚠️ Próximos Passos:
+1. Configurar OPENAI_API_KEY em Settings > Secrets
+2. Testar com um PR de teste
+
+🚀 Comando: /git/code-review validate
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Validação com Issues
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⚠️ CODE REVIEW - ISSUES ENCONTRADOS
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+🔴 Críticos:
+∟ Secret OPENAI_API_KEY não configurado
+
+🟡 Importantes:
+∟ Versão do action desatualizada (usar @v1.2.0)
+
+💡 Sugestões:
+∟ Adicionar filtro de arquivos .ts/.tsx
+
+🔧 Auto-fix disponível? Sim
+Executar auto-fix? (s/n)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## 🔗 Referências
+
+- Checklist: `common/prompts/code-review-checklist.md`
+- Padrões Git: `common/prompts/git-workflow-patterns.md`
+- Agente: @code-reviewer para reviews manuais
+
+## ⚠️ Notas
+
+- Requer GitHub Actions habilitado
+- Secret `OPENAI_API_KEY` obrigatório
+- Funciona com qualquer stack JavaScript/TypeScript