adi_dev_workflow 1.0.0 → 1.1.0

package/frameworks/skills/sdd-tech-spec-expert/evals/evals.json

@@ -0,0 +1,199 @@
+{
+  "skill_name": "sdd-tech-spec-expert",
+  "evals": [
+    {
+      "id": 1,
+      "name": "prd-usuario-existente",
+      "prompt": "Preciso gerar o SPEC_TECH para a feature de usuario. O PRD aprovado esta em docs/feature-user/v1/prd.md",
+      "expected_output": "A skill deve: (1) ler o PRD aprovado em docs/feature-user/v1/prd.md, (2) pesquisar o codebase (CLAUDE.md, .claude/rules/, estrutura de diretorios, codigo existente), (3) verificar se existe tech_direction.md na pasta da feature, (4) iniciar o processo de coleta fazendo UMA pergunta por vez ao usuario, (5) NAO bombardear com multiplas perguntas de uma vez",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "leu-prd-aprovado",
+          "type": "tool_usage",
+          "description": "Deve ler o arquivo PRD aprovado antes de fazer qualquer pergunta",
+          "check": "A skill usou Read para ler docs/feature-user/v1/prd.md"
+        },
+        {
+          "name": "pesquisou-codebase",
+          "type": "tool_usage",
+          "description": "Deve pesquisar regras do projeto e estrutura do codebase",
+          "check": "A skill leu CLAUDE.md e/ou arquivos em .claude/rules/"
+        },
+        {
+          "name": "verificou-tech-direction",
+          "type": "tool_usage",
+          "description": "Deve verificar se existe tech_direction.md na pasta da feature",
+          "check": "A skill tentou ler ou verificar a existencia de docs/feature-user/v1/tech_direction.md"
+        },
+        {
+          "name": "uma-pergunta-por-vez",
+          "type": "output_quality",
+          "description": "Deve fazer apenas UMA pergunta tecnica por vez, nao bombardear o usuario",
+          "check": "A primeira interacao com o usuario contem no maximo 1 pergunta tecnica clara (pode ter sub-opcoes, mas e 1 topico)"
+        },
+        {
+          "name": "resumo-do-prd",
+          "type": "output_content",
+          "description": "Deve apresentar um resumo do que entendeu do PRD antes de iniciar perguntas",
+          "check": "A skill apresenta um resumo do objetivo da feature (modulo de usuario, cadastro, login, consulta, atualizacao)"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "spec-tech-completo-16-secoes",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. PRD em docs/feature-user/v1/prd.md. Para agilizar, aceite todas as sugestoes padrao sem perguntar — quero ver o documento final completo.",
+      "expected_output": "A skill deve gerar um SPEC_TECH completo com TODAS as 16 secoes do template, salvar o arquivo fisico em docs/feature-user/v1/spec_tech.md ANTES de apresentar ao usuario, e NAO iniciar o TASK PLAN automaticamente",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "todas-16-secoes",
+          "type": "output_content",
+          "description": "O SPEC_TECH gerado deve conter todas as 16 secoes do template",
+          "check": "O documento contem secoes 1 (Identificacao), 2 (Resumo Tecnico), 3 (Arquitetura), 4 (Estruturas de Dados), 5 (Regras Tecnicas), 6 (Fluxos Tecnicos), 7 (APIs/Endpoints), 8 (Frontend/Mobile), 9 (Banco Local/Cache), 10 (Dependencias), 11 (Requisitos Nao Funcionais), 12 (Criterios Tecnicos), 13 (Riscos), 14 (Estrategia de Testes), 15 (Arquivos Envolvidos), 16 (Checklist Final)"
+        },
+        {
+          "name": "arquivo-salvo-antes-de-apresentar",
+          "type": "tool_usage",
+          "description": "Deve salvar o arquivo fisico ANTES de apresentar ao usuario",
+          "check": "A skill usou Write para salvar em docs/feature-user/v1/spec_tech.md antes de mostrar o conteudo ao usuario"
+        },
+        {
+          "name": "nao-iniciou-task-plan",
+          "type": "output_content",
+          "description": "NAO deve sugerir ou iniciar a proxima etapa (TASK PLAN) automaticamente",
+          "check": "A skill NAO menciona executar /sdd:generate-task-plan nem inicia geracao de tasks. Apenas pergunta se o SPEC esta aprovado"
+        },
+        {
+          "name": "mapeamento-user-stories-secao-5-1",
+          "type": "output_content",
+          "description": "A secao 5.1 deve mapear TODAS as user stories do PRD para definicoes tecnicas",
+          "check": "A secao 5.1 contem mapeamento de US-01, US-02, US-03 e US-04 para definicoes tecnicas correspondentes"
+        },
+        {
+          "name": "secao-15-tres-subsecoes",
+          "type": "output_content",
+          "description": "A secao 15 deve ter 3 subsecoes: Criar, Modificar e Referencia",
+          "check": "A secao 15 contem 15.1 (Arquivos a Criar), 15.2 (Arquivos a Modificar) e 15.3 (Arquivos de Referencia)"
+        },
+        {
+          "name": "delegou-secao-14-qa",
+          "type": "tool_usage",
+          "description": "A secao 14 (Estrategia de Testes) deve ser delegada a um subagente QA",
+          "check": "A skill disparou um subagente (Task tool) para gerar a secao 14 com contexto de QA expert"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "respeita-arquitetura-existente",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. O PRD esta em docs/feature-user/v1/prd.md. Quero que a solucao use a arquitetura ja existente no projeto.",
+      "expected_output": "A skill deve pesquisar profundamente o codebase, identificar a arquitetura existente (gRPC, Clean Architecture, SQLite, Uber FX, SQLC) e propor solucoes que seguem os padroes ja estabelecidos — NAO propor REST quando o projeto usa gRPC, NAO propor PostgreSQL quando o projeto usa SQLite, etc.",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "identificou-grpc",
+          "type": "output_content",
+          "description": "Deve identificar que o projeto usa gRPC e propor endpoints gRPC (nao REST)",
+          "check": "O SPEC_TECH propoe endpoints/servicos gRPC, NAO endpoints REST (GET/POST/PUT/DELETE)"
+        },
+        {
+          "name": "identificou-sqlite",
+          "type": "output_content",
+          "description": "Deve identificar que o projeto usa SQLite e propor migracoes SQLite",
+          "check": "O SPEC_TECH referencia SQLite como banco de dados, com migracoes no padrao do projeto"
+        },
+        {
+          "name": "identificou-clean-architecture",
+          "type": "output_content",
+          "description": "Deve seguir a Clean Architecture do projeto (handler -> service -> repository)",
+          "check": "O SPEC_TECH propoe componentes nas camadas handler, service e repository conforme a arquitetura existente"
+        },
+        {
+          "name": "identificou-uber-fx",
+          "type": "output_content",
+          "description": "Deve mencionar Uber FX para injecao de dependencias",
+          "check": "O SPEC_TECH referencia Uber FX ou modulos fx.Module para DI dos novos componentes"
+        },
+        {
+          "name": "convencao-idioma-banco-portugues",
+          "type": "output_content",
+          "description": "Deve seguir a convencao do projeto: tabelas/colunas em portugues, codigo em ingles",
+          "check": "Tabelas e colunas propostas estao em portugues (ex: usuarios, nome, email, senha_hash) e nomes de structs/funcoes em ingles"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "com-tech-direction-existente",
+      "prompt": "Preciso do SPEC_TECH para a feature de pedidos (orders). O PRD esta em docs/feature-order/v1/prd.md. Ja criei um tech_direction.md na mesma pasta com decisoes tecnicas que quero que sejam respeitadas.",
+      "expected_output": "A skill deve detectar o tech_direction.md, apresentar os direcionamentos encontrados, respeitar as decisoes do usuario como ponto de partida, e levantar conflitos se houver incompatibilidade com o codebase existente",
+      "files": [
+        "docs/feature-order/v1/prd.md",
+        "docs/feature-order/v1/tech_direction.md"
+      ],
+      "assertions": [
+        {
+          "name": "detectou-tech-direction",
+          "type": "tool_usage",
+          "description": "Deve buscar e ler o tech_direction.md na pasta da feature",
+          "check": "A skill leu o arquivo docs/feature-order/v1/tech_direction.md"
+        },
+        {
+          "name": "apresentou-direcionamentos",
+          "type": "output_content",
+          "description": "Deve apresentar um resumo dos direcionamentos encontrados no tech_direction",
+          "check": "A skill lista ou resume as decisoes tecnicas encontradas no tech_direction.md antes de iniciar perguntas"
+        },
+        {
+          "name": "respeitou-decisoes-usuario",
+          "type": "output_content",
+          "description": "Deve usar as decisoes do tech_direction como ponto de partida, nao propor alternativas conflitantes",
+          "check": "As propostas tecnicas da skill sao consistentes com o tech_direction — nao propoe alternativas que contradizem decisoes firmes do usuario"
+        },
+        {
+          "name": "registrou-no-resumo-tecnico",
+          "type": "output_content",
+          "description": "Deve incluir as decisoes do tech_direction na secao 2 do SPEC_TECH",
+          "check": "A secao 2 (Resumo Tecnico) do SPEC_TECH referencia ou incorpora decisoes do tech_direction.md"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "nao-inventa-nao-deduz",
+      "prompt": "Gere o SPEC_TECH para a feature de usuario. PRD em docs/feature-user/v1/prd.md. Mas quero que inclua tambem um sistema de notificacoes por email quando o usuario se cadastrar.",
+      "expected_output": "A skill deve identificar que 'notificacoes por email' NAO esta no PRD aprovado e NAO deve adicionar ao escopo. Deve informar ao usuario que isso esta fora do escopo do PRD e perguntar se deseja prosseguir apenas com o escopo aprovado ou se quer primeiro atualizar o PRD.",
+      "files": [
+        "docs/feature-user/v1/prd.md"
+      ],
+      "assertions": [
+        {
+          "name": "identificou-escopo-fora-prd",
+          "type": "output_content",
+          "description": "Deve identificar que notificacoes por email nao esta no PRD aprovado",
+          "check": "A skill menciona que notificacoes por email nao faz parte do PRD aprovado ou esta fora do escopo definido"
+        },
+        {
+          "name": "nao-adicionou-ao-spec",
+          "type": "output_content",
+          "description": "NAO deve adicionar funcionalidade fora do PRD ao SPEC_TECH sem aprovacao",
+          "check": "A skill NAO inclui notificacoes por email no SPEC_TECH gerado, ou pergunta ao usuario antes de incluir"
+        },
+        {
+          "name": "sugeriu-atualizar-prd",
+          "type": "output_content",
+          "description": "Deve sugerir que o usuario atualize o PRD se quiser incluir a funcionalidade",
+          "check": "A skill sugere atualizar o PRD primeiro ou pergunta ao usuario como deseja proceder com o item fora do escopo"
+        }
+      ]
+    }
+  ]
+}

package/frameworks/skills/sdd-tech-spec-expert/templates/spec_tech_template.md

@@ -0,0 +1,290 @@
+# SPEC_TECH -- Especificação Técnica
+
+## 1. Identificação
+- **Feature/Projeto**:
+- **Autor**:
+- **Data**:
+- **Versão**:
+- **Status**: Draft | Refinando | Aprovado
+- **PRD Relacionado**:
+
+---
+
+## 2. Resumo Técnico da Solução
+
+(Visão geral do COMO será implementado. Descreva em 3-5 linhas a abordagem técnica escolhida, as principais decisões arquiteturais e o resultado técnico esperado.)
+
+---
+
+## 3. Arquitetura da Solução
+
+### 3.1 Visão Geral
+(Diagrama ou descrição da arquitetura geral da solução. Como os componentes se conectam.)
+
+### 3.2 Componentes/Módulos
+(Lista de componentes envolvidos com descrição da responsabilidade de cada um.)
+
+| Componente | Responsabilidade | Camada |
+|------------|-----------------|--------|
+|            |                 |        |
+
+### 3.3 Interações entre componentes
+(Descreva como os componentes se comunicam. Fluxo de dados entre camadas.)
+
+---
+
+## 4. Estruturas de Dados
+
+### 4.1 Models / DTOs
+(Structs, tipos e modelos de domínio que serão criados ou modificados.)
+
+### 4.2 Entidades de Banco de Dados
+(Tabelas, colunas, índices, constraints. Inclua SQL de migrações quando aplicável.)
+
+### 4.3 Schemas adicionais
+(Protocol Buffers, mensagens gRPC, schemas de validação ou outros formatos de dados.)
+
+---
+
+## 5. Regras Técnicas de Negócio
+
+(Implementação técnica das regras definidas no PRD. Cada regra do PRD deve ter uma definição técnica correspondente.)
+
+### 5.1 Mapeamento de User Stories para Definições Técnicas
+
+| User Story (PRD) | Definição Técnica | Componentes Envolvidos |
+|------------------|-------------------|----------------------|
+| US-01            |                   |                      |
+| US-02            |                   |                      |
+
+<!-- LLM-ONLY: Cada user story do PRD deve ter pelo menos uma definicao tecnica correspondente. Isso garante rastreabilidade completa entre o PRD e a especificacao tecnica. -->
+
+---
+
+## 6. Fluxos Técnicos
+
+### 6.1 Fluxo Principal (técnico)
+(Sequência de chamadas, processamento e respostas do fluxo principal. Descreva camada por camada.)
+
+### 6.2 Fluxos Alternativos
+(Variações do fluxo principal: dados opcionais, caminhos condicionais, etc.)
+
+### 6.3 Tratamento de Erros
+(Como erros serão tratados em cada camada. Mapeamento de erros de negócio para códigos de status.)
+
+| Erro de Negócio | Código de Status | Mensagem | Camada de Origem |
+|----------------|-----------------|----------|-----------------|
+|                |                 |          |                 |
+
+---
+
+## 7. APIs / Endpoints
+
+### 7.1 Endpoints Backend
+
+| Ação | Método | Rota | Payload | Resposta Esperada |
+|------|--------|------|---------|-------------------|
+|      |        |      |         |                   |
+
+### 7.2 Erros e Códigos de Status
+
+| Código | Situação | Mensagem |
+|--------|----------|----------|
+|        |          |          |
+
+---
+
+## 8. Frontend / Mobile
+
+### 8.1 Telas
+(Telas envolvidas, layouts e componentes visuais.)
+
+### 8.2 Estados e Gerência de Estado
+(Gerenciamento de estado: loading, success, error, empty. Solução de state management.)
+
+### 8.3 Navegação
+(Fluxo de navegação entre telas. Rotas e parâmetros.)
+
+### 8.4 Validações
+(Validações de formulário, campos obrigatórios, máscaras, limites.)
+
+### 8.5 Comportamentos específicos
+(Animações, transições, comportamentos offline, responsividade.)
+
+---
+
+## 9. Banco Local / Cache
+
+### 9.1 Estrutura de Tabelas
+(Tabelas locais, colunas, tipos. Diferentes do banco remoto se aplicável.)
+
+### 9.2 Estratégia de Sincronização
+(Como dados locais sincronizam com o backend. Conflitos, prioridade, frequência.)
+
+### 9.3 Estratégia de Versionamento
+(Como lidar com mudanças de schema local. Migrações locais, rollback.)
+
+---
+
+## 10. Dependências Técnicas
+
+| Tipo | Nome | Versão | Motivo |
+|------|------|--------|--------|
+| Pacote |    |        |        |
+| Biblioteca | | |    |
+| Ferramenta | | |    |
+| SDK |        |        |        |
+
+---
+
+## 11. Requisitos Não Funcionais (COMO serão atendidos)
+
+### Segurança
+(Autenticação, autorização, criptografia, validação de input, sanitização.)
+
+### Performance
+(Metas de tempo de resposta, paginação, índices, cache, otimizações.)
+
+### Escalabilidade
+(Limites conhecidos, estratégia de crescimento, gargalos potenciais.)
+
+### Observabilidade
+(Logs estruturados, métricas, alertas, tracing distribuído.)
+
+### Resiliência
+(Tratamento de falhas, retry, circuit breaker, graceful degradation.)
+
+---
+
+## 12. Critérios Técnicos de Aceite
+
+- [ ] Implementação cobre todas as regras do PRD
+- [ ] Estruturas de dados criadas e funcionais
+- [ ] Fluxos técnicos implementados e testados
+- [ ] API funcionando conforme especificado
+- [ ] Erros tratados em todas as camadas
+- [ ] Logs/monitoramento implementados
+- [ ] Validações aplicadas (input, negócio, dados)
+- [ ] Código segue padrões e convenções do projeto
+
+---
+
+## 13. Riscos Técnicos
+
+| Risco | Probabilidade | Impacto | Mitigação |
+|-------|--------------|---------|-----------|
+|       |              |         |           |
+
+---
+
+## 14. Estratégia de Testes
+
+> **Resumo**: X casos de teste | Unitários: Y | Integração: Z | E2E: W
+> **Padrão**: [framework de teste, padrão de mock, convenção de nomes]
+
+### Rastreabilidade: Critérios de Aceite → Testes
+
+| CA (PRD) | Descrição Resumida | Testes |
+|----------|-------------------|--------|
+| CA-01    | (descrição curta do CA no PRD) | CT-01, CT-10, CT-20, CT-30 |
+| CA-02    | (descrição curta do CA no PRD) | CT-02, CT-22 |
+
+<!-- LLM-ONLY: Cada CA-XX do PRD deve ter pelo menos um teste correspondente. Esta tabela deve ser preenchida PRIMEIRO — guia toda a estrategia. -->
+
+---
+
+### 14.1 Testes Unitários
+
+<!-- LLM-ONLY: Coluna "Objetivo": Descreva em 1 frase O QUE o teste valida e POR QUE importa. Use o padrao: Verbo + comportamento especifico + condicao. Exemplo: "Verificar que apenas categorias com ativo=1 sao retornadas, ordenadas pelo campo 'ordem'". NAO repita o nome do teste — o objetivo deve dar contexto que o nome sozinho nao da. -->
+
+#### Service: [NomeService] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-01 | TestMetodo_Sucesso | CA-01 | Verificar que [comportamento esperado] quando [condição do cenário] | dados válidos | resultado esperado | repo retorna dados |
+| CT-02 | TestMetodo_ErroValidacao | CA-03 | Verificar que [erro específico] é retornado quando [condição inválida] | dados inválidos | ErrEspecifico | — |
+
+#### Apresentação: [NomeHandler] (`arquivo_test.go`)
+
+Mock: [interfaces mockadas]
+
+| CT | Teste | CA | Objetivo | Input | Expected | Mock |
+|----|-------|----|----------|-------|----------|------|
+| CT-10 | TestHandler_Sucesso | CA-01 | Verificar que handler converte [modelo domínio] para [formato response] corretamente | request válido | response proto | service retorna sucesso |
+
+### 14.2 Testes de Integração
+
+#### [CamadaA + CamadaB] (`arquivo_test.go`)
+
+Setup: [banco in-memory, migrações, fixtures]
+
+| CT | Teste | CA | Objetivo | Fluxo | Validação |
+|----|-------|----|----------|-------|-----------|
+| CT-20 | TestIntegracao_CRUD | CA-01 | Verificar que dados persistidos são recuperados integralmente via [camada] | Create → Get | dados consistentes |
+| CT-22 | TestIntegracao_Unique | CA-02 | Verificar que constraint unique impede duplicação de [campo] | Insert duplicado | erro constraint |
+
+### 14.3 Testes End-to-End (E2E)
+
+#### Fluxo: [Nome do Fluxo Crítico] (CT-30)
+- **CA**: CA-01, CA-03, CA-06
+- **Objetivo**: (1 frase descrevendo o que este fluxo E2E valida de ponta a ponta)
+- **Pré-condições**: (estado inicial do sistema)
+- **Passos**:
+  1. Cliente envia request X
+  2. Sistema processa e retorna Y
+  3. Verificar estado do banco
+- **Validações**: (assertions sobre dados e estado final)
+
+### 14.4 Cenários de Erro
+
+| Cenário | CA | Objetivo | Trigger | Código/Status | Log Esperado |
+|---------|----|----------|---------|---------------|-------------|
+| Dados duplicados | CA-02 | Verificar que [constraint] impede [operação] e retorna erro adequado | Insert duplicado | [erro conflito] | "registro já existe..." |
+| Recurso inexistente | CA-05 | Verificar que acesso a [recurso] inexistente retorna [código] sem expor dados internos | ID não encontrado | [erro not found] | "não encontrado..." |
+
+---
+
+## 15. Arquivos Envolvidos e Ações
+
+### 15.1 Arquivos a Criar
+
+| Arquivo | Descrição | Camada |
+|---------|-----------|--------|
+|         |           |        |
+
+### 15.2 Arquivos a Modificar
+
+| Arquivo | Modificação | Motivo |
+|---------|------------|--------|
+|         |            |        |
+
+### 15.3 Arquivos de Referência (somente leitura)
+
+| Arquivo | Motivo da Consulta |
+|---------|-------------------|
+|         |                   |
+
+<!-- LLM-ONLY: Esta secao economiza tokens e scans durante a implementacao, pois lista exatamente quais arquivos serao impactados. -->
+
+---
+
+## 16. Checklist Final
+
+- [ ] SPEC_TECH cobre todo o PRD
+- [ ] Resumo técnico claro e objetivo (seção 2)
+- [ ] Arquitetura definida com componentes e interações (seção 3)
+- [ ] Estruturas de dados definidas (seção 4)
+- [ ] User Stories mapeadas para definições técnicas (seção 5.1)
+- [ ] Fluxos técnicos descritos com tratamento de erros (seção 6)
+- [ ] Endpoints mapeados com payloads e respostas (seção 7)
+- [ ] Telas e fluxos de frontend/mobile definidos (seção 8)
+- [ ] Banco local/cache especificado se aplicável (seção 9)
+- [ ] Dependências técnicas listadas (seção 10)
+- [ ] Requisitos não funcionais endereçados (seção 11)
+- [ ] Critérios técnicos de aceite definidos (seção 12)
+- [ ] Riscos técnicos identificados com mitigações (seção 13)
+- [ ] Estratégia de testes definida com rastreabilidade CA→testes no topo (seção 14)
+- [ ] Arquivos envolvidos listados — criar, modificar, referência (seção 15)
+- [ ] Pronto para geração das TASKS

package/frameworks/skills/sdd-tech-spec-expert/templates/tech_direction-template.md

@@ -0,0 +1,23 @@
+# TECH DIRECTION (Opcional)
+
+> Direcionamento técnico inicial para a feature. Serve como ponto de partida para o SPEC_TECH, não como decisão final.
+> O Arquiteto (tech-spec-expert) pode complementar, ajustar ou questionar qualquer item aqui.
+
+## Decisões técnicas já tomadas
+- (ex: Usar JWT com refresh token para autenticação)
+- (ex: Criar gateway separado para integração externa)
+
+## Tecnologias/Libs sugeridas
+- (ex: biblioteca X para integração com serviço Y)
+- (ex: framework Z para testes)
+
+## Padrões ou abordagens preferidas
+- (ex: Seguir o pattern Gateway já usado no projeto)
+- (ex: Implementar como CQRS)
+
+## Restrições técnicas
+- (ex: Precisa ser stateless para rodar em k8s)
+- (ex: Não temos message broker disponível)
+
+## Observações
+- (qualquer contexto técnico relevante que o arquiteto deve considerar)

package/frameworks/skills/taskcard-expert/SKILL.md

@@ -38,17 +38,17 @@ O template completo esta em: [template.md](templates/template.md)
 
 ---
 
+## Perfil do Projeto (pre-carregado)
+
+O `CLAUDE.md`, `.claude/rules/` e `project-profile.md` ja estao no contexto — NAO releia.
+Use essas informacoes para adaptar a TaskCard ao perfil do projeto.
+Se `project-profile.md` NAO existir, execute `/generate-project-profile` antes de prosseguir.
+
 ## PONTO CRITICO: Analise Obrigatoria do Projeto
 
 **ANTES de planejar ou escrever qualquer TaskCard**, voce DEVE:
 
-1. **Ler as rules do projeto** — entender padroes, convencoes e restricoes vigentes. Procure em todos os locais conhecidos:
-   - `.claude/rules/` (Claude Code)
-   - `.cursor/rules/` (Cursor)
-   - `.github/copilot-instructions.md` (GitHub Copilot)
-   - `.gemini/` (Google Gemini)
-   - `.antigravity/` (Antigravity)
-   - `CLAUDE.md`, `.cursorrules`, ou arquivos equivalentes na raiz
+1. **Consultar regras e perfil do projeto** (ja no contexto) — padroes, convencoes e restricoes vigentes
 2. **Explorar o codebase** — buscar implementacoes existentes, padroes ja estabelecidos e codigo reutilizavel
 3. **Identificar o que ja existe** — funcoes, tipos, classes, interfaces e componentes existentes em cada camada do projeto que podem ser reaproveitados
 4. **Mapear dependencias reais** — verificar o que ja esta implementado e o que realmente precisa ser criado do zero
@@ -60,74 +60,15 @@ O template completo esta em: [template.md](templates/template.md)
 
 ---
 
-## PASSO ZERO: Deteccao de Linguagem e Arquitetura
-
-**ANTES DE QUALQUER COISA**, voce DEVE identificar a stack tecnica do projeto:
-
-### 1. Ler CLAUDE.md e rules do projeto
-- `CLAUDE.md` na raiz do projeto
-- `.claude/rules/` (todas as regras do Claude Code)
-- Qualquer arquivo de regras/convencoes existente
-
-### 2. Detectar linguagem e framework
-A partir do CLAUDE.md, rules e exploracao do projeto, identifique:
-
-| O que detectar | Como descobrir | Exemplo |
-|---------------|----------------|---------|
-| **Linguagem** | `go.mod`, `package.json`, `pubspec.yaml`, `requirements.txt`, `Cargo.toml` | Go, TypeScript, Dart, Python, Rust |
-| **Framework** | Imports, estrutura de pastas, CLAUDE.md | gRPC, Express, FastAPI, Gin, Flutter, React |
-| **Banco de dados** | Migracoes, config, ORM | SQLite, PostgreSQL, MongoDB |
-| **ORM / Query builder** | Imports, arquivos gerados | SQLC, GORM, Prisma, TypeORM, Drift |
-| **Framework de teste** | Arquivos de teste, dependencias | testify, jest, pytest, flutter_test |
-| **Padrao de mock** | Imports, arquivos mock | gomock, mockito, jest.mock, mocktail |
-| **Arquitetura** | Estrutura de pastas, CLAUDE.md | Clean Arch, MVC, Hexagonal, BLoC, Layered |
-
-### 3. Construir o Perfil do Projeto
-
-Com base na deteccao, monte mentalmente (e aplique) o perfil:
-
-```
-Perfil do Projeto:
-- Linguagem: [detectada]
-- Framework: [detectado]
-- Arquitetura: [detectada] (camadas: [lista])
-- Framework de teste: [detectado]
-- Padrao de mock: [detectado]
-- Extensao de teste: [detectada] (ex: _test.go, .test.ts, _test.dart)
-- Padrao de arquivos de teste: [detectado] (ex: mesmo dir, pasta __tests__, pasta test/)
-```
-
-> **Toda a TaskCard DEVE ser adaptada ao perfil detectado.**
-> NAO assuma Go, gRPC, testify ou qualquer stack especifica sem antes confirmar.
-
----
-
-## PONTO CRITICO: Analise Obrigatoria de Testes
-
-> **Nota**: Para uma analise aprofundada de testes com rigor de QA Senior, use o **taskcard-qa-expert** via `/taskcard:generate-tests`. Ele gera a secao 10 completa (10.1 a 10.6) com rastreabilidade, cenarios de erro detalhados e mapeamento por camada.
-
-**ANTES de preencher a secao 10 (Testes) de qualquer TaskCard**, voce DEVE:
-
-1. **Buscar testes existentes** — encontrar todos os arquivos de teste no projeto usando o padrao detectado no Passo Zero (ex: `*_test.go`, `*.test.ts`, `*_test.dart`, `test_*.py`, etc.) relacionados as camadas impactadas pela task
-2. **Ler os testes encontrados** — entender quais cenarios ja estao cobertos, quais mocks existem, e como os testes estao estruturados
-3. **Identificar testes a modificar** — se a task altera interfaces, assinaturas de funcoes, modelos de dominio ou comportamento de negocio, os testes existentes dessas camadas precisam ser atualizados
-4. **Identificar testes a criar** — se a task cria novos endpoints, services, repositories, componentes ou funcoes de negocio, testes correspondentes DEVEM ser criados
-5. **Mapear padroes de teste do projeto** — identificar framework de teste, convencao de nomes, padroes de mock, fixtures e helpers reutilizaveis a partir do Passo Zero
-
-### Regras para a secao 10
+## Secao 10 (Testes): Delegacao ao qa-staff-engineer
 
-| Situacao | Acao obrigatoria |
-|----------|-----------------|
-| Task cria componente de **apresentacao** (handler, controller, widget, page) | Criar testes de validacao de entrada, mapeamento de dados e codigos de resposta. Mock da camada de negocio |
-| Task cria componente de **negocio** (service, use case, cubit, bloc) | Criar testes unitarios com mocks da camada de dados, cobrindo regras de negocio e erros de dominio |
-| Task cria componente de **dados** (repository, DAO, data source) | Criar testes de integracao cobrindo CRUD, queries e casos de borda |
-| Task modifica **interface/contrato** existente | Atualizar mocks e testes de todas as camadas que dependem do contrato |
-| Task adiciona **campo em modelo/entidade** | Atualizar fixtures, factory functions e assertions nos testes existentes |
-| Task altera **regra de negocio** | Atualizar cenarios de teste na camada de negocio e adicionar novos cenarios |
-| Task cria **migracao/schema** de banco | Testar migracao up e down, verificar schema resultante |
+A secao 10 (Testes) NAO e preenchida pelo gerador da TaskCard. Ela e delegada ao agente `qa-staff-engineer` (modo GERAR_TESTES) que:
+- Analisa o codebase, testes existentes e padroes do projeto
+- Mapeia criterios de aceite (secao 9) para testes
+- Preenche as subsecoes 10.1 a 10.6 diretamente no arquivo da TaskCard
 
-> **Nunca gere uma TaskCard sem a secao 10 preenchida.**
-> Se nao ha testes a modificar nem a criar (raro), justifique explicitamente em 10.1/10.2.
+> **Nunca gere uma TaskCard sem disparar o qa-staff-engineer para preencher a secao 10.**
+> Salve o arquivo com secoes 1-9 e 11 primeiro, depois delegue a secao 10 ao agente.
 
 ---
 
@@ -139,7 +80,7 @@ Perfil do Projeto:
 2. **Sem vagueza** — proibido termos como "ajustar conforme necessario", "melhorar se possivel"
 3. **Sem invencao** — se faltar informacao, pergunte ao usuario
 4. **Escopo fechado** — toda TaskCard deve ser executavel sem novas decisoes
-5. **Template completo** — todas as 11 secoes devem ser preenchidas
+5. **Template completo** — secoes 1-9 e 11 preenchidas pelo gerador; secao 10 (Testes) delegada ao agente `qa-staff-engineer`
 6. **Processo interativo** — faca uma pergunta por vez para preencher lacunas
 7. **Gerar sem pedir aprovacao** — NUNCA peca aprovacao para gerar os arquivos. Gere os arquivos da TaskCard imediatamente e apresente apenas um resumo curto do que foi criado (IDs, nomes, arquivos gerados)
 
@@ -234,12 +175,14 @@ docs/
 ```
 Contexto do usuario
   -> Identificar lacunas (perguntar 1 a 1)
-  -> Analisar testes existentes no projeto (buscar arquivos de teste usando o padrao detectado no Passo Zero nas camadas impactadas)
-  -> Preencher template (todas as 11 secoes, incluindo secao 10 de Testes)
+  -> Preencher template (secoes 1-9 e 11)
+  -> Remover todos os comentarios <!-- LLM-ONLY: ... --> do conteudo antes de salvar
   -> Salvar em docs/<feature>/vN/ (GERAR ARQUIVOS IMEDIATAMENTE, SEM PEDIR APROVACAO)
+  -> Delegar secao 10 (Testes) ao agente qa-staff-engineer (modo GERAR_TESTES)
+     O agente analisa o codebase, testes existentes e criterios de aceite (secao 9)
+     e preenche as subsecoes 10.1 a 10.6 diretamente no arquivo da TaskCard
   -> Se multiplas: gerar task-plan.md
   -> Apresentar resumo curto do que foi criado (arquivos gerados, IDs, nomes)
-  -> (Opcional) Usar /taskcard:generate-tests para enriquecer a secao 10 com rigor de QA Senior
 ```
 
 ### Executar TaskCard
@@ -252,7 +195,12 @@ Ler TaskCard completa
   -> Validar guardrails (secao 6) a cada passo
   -> Rodar testes (make test) e garantir que passam
   -> Validar aceite tecnico (secao 9)
-  -> Produzir relatorio final
+  -> Gate 1: qa-staff-engineer (VALIDAR_IMPLEMENTACAO)
+     APROVADO → Gate 2 | REJEITADO → loop correcao
+  -> Gate 2: tech-review-conformance
+     approved → concluido | rejected → loop → volta Gate 1
+  -> Loop correcao (max 3 tentativas → Blocked + escalar)
+  -> Produzir relatorio final com vereditos QA + Tech Review
 ```
 
 ### Relatorio de Execucao (formato padrao)

package/frameworks/skills/taskcard-expert/templates/template.md

@@ -126,8 +126,6 @@ Mapeamento entre criterios de aceite (secao 9) e testes que os validam:
 |---|------------------------------|---------------------------|------|
 | 1 | [criterio] | [TestNome] | [Unitario/Integracao/E2E] |
 
-> Para analise aprofundada com rigor de QA Senior, use `/taskcard:generate-tests`.
-
 ---
 
 ## 11. Notas / Observacoes