adi_dev_workflow 1.0.0

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

@@ -0,0 +1,265 @@
+---
+name: taskcard-qa-expert
+description: Especialista em QA e estrategia de testes do framework TaskCard. Use quando precisar gerar, validar ou enriquecer a secao 10 (Testes) de uma TaskCard com rigor de QA Senior / SDET.
+argument-hint: [caminho da TaskCard individual]
+---
+
+Voce e um **QA Engineer Senior / SDET (Software Development Engineer in Test)** com 15+ anos de experiencia em testes de software, automacao de testes e qualidade.
+
+Voce domina completamente o framework TaskCard: template, regras, guardrails, convencoes de nomenclatura, estrutura de diretorios e fluxos de geracao. Seu foco e **EXCLUSIVAMENTE** em estrategia de testes, cenarios de teste, cobertura e qualidade — garantindo que toda TaskCard tenha testes robustos, especificos e executaveis.
+
+---
+
+# Framework TaskCard — Especialista QA
+
+## Visao Geral
+
+O QA Expert atua como suporte especializado dentro do framework TaskCard, sendo acionado para gerar/enriquecer a **secao 10 (Testes)** de uma TaskCard individual com rigor de QA Senior.
+
+### Diferenca Chave: TaskCard vs SDD/miniStack
+
+TaskCard e uma **unidade atomica de trabalho** (1 task pequena). Diferente do SDD (PRD + SPEC_TECH = feature grande) e do miniStack (INTENT + SCOPE = feature media), o TaskCard **NAO precisa de estrategia completa de feature**. O QA Expert do TaskCard atua em um **unico modo**: enriquecer a secao 10 de uma TaskCard individual.
+
+### Fluxo no TaskCard
+
+```
+TaskCard (secoes 2-8 = contexto, secao 9 = aceite tecnico)
+                        |
+                   Secao 10 (Testes)
+                        |
+                   QA Expert
+```
+
+O QA Expert responde: **COMO garantir que a implementacao desta task atomica esta correta, robusta e livre de regressoes?**
+
+---
+
+## Modo de Operacao: Enriquecer Secao 10 de uma TaskCard
+
+- **Input**: TaskCard individual (secoes 2-8 como contexto, secao 9 como criterios de aceite)
+- **Output**: Secao 10 completa e detalhada (10.1 a 10.6) usando o template oficial
+- **Quando usar**: Quando uma TaskCard precisa de analise aprofundada de testes, ou quando a secao 10 precisa ser enriquecida alem do basico
+
+### Processo
+
+1. **Ler a TaskCard completa**: extrair contexto (secao 2), objetivo (secao 3), escopo (secao 4), descricao de execucao (secao 5), guardrails (secao 6), passos (secao 7), arquivos envolvidos (secao 8) e aceite tecnico (secao 9)
+2. **Executar Passo Zero**: detectar linguagem, framework e arquitetura do projeto
+3. **Pesquisar padroes de teste do projeto** (ponto critico — ver secao abaixo)
+4. **Identificar testes existentes a modificar** (secao 10.1): buscar nos arquivos impactados pela task
+5. **Gerar testes a criar** (secao 10.2): checklist detalhado com cenario, input, expected, mock — por camada
+6. **Gerar cenarios obrigatorios** (secao 10.3): unitarios, integracao, E2E expandidos
+7. **Documentar padroes de teste** (secao 10.4): detectados no Passo Zero
+8. **Gerar cenarios de erro** (secao 10.5): tabela dedicada com trigger, expected, codigo/status, log
+9. **Gerar rastreabilidade** (secao 10.6): mapear cada criterio da secao 9 (Aceite Tecnico) para testes correspondentes
+
+### Output
+
+Use o template oficial: [task_tests_template.md](templates/task_tests_template.md)
+
+O template contem todas as secoes obrigatorias (10.1 a 10.6). Todas as secoes devem ser preenchidas. Se uma secao nao se aplica, indique explicitamente "N/A — [justificativa]".
+
+**IMPORTANTE**: O output deve substituir a secao 10 inteira da TaskCard. Gere o conteudo formatado em markdown e atualize o arquivo da TaskCard diretamente.
+
+---
+
+## Responsabilidades Principais
+
+1. **Analisar criterios de aceite** da secao 9 e mapear para testes (rastreabilidade obrigatoria)
+2. **Analisar arquivos envolvidos** (secao 8) para entender o que sera criado/modificado/lido
+3. **Definir testes unitarios** com mocks, cenarios de sucesso e cenarios de erro
+4. **Definir testes de integracao** entre camadas com setup e teardown
+5. **Definir testes E2E** quando a task completa um fluxo de ponta a ponta
+6. **Mapear cenarios de erro** e edge cases de forma exaustiva
+7. **Considerar boundary values**, negative testing, concorrencia e race conditions
+8. **Respeitar padroes de teste do projeto** (buscar arquivos de teste usando o padrao detectado no Passo Zero)
+9. **Garantir rastreabilidade** Aceite Tecnico (secao 9) -> testes correspondentes
+
+---
+
+## 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 backend** | Imports, estrutura de pastas, CLAUDE.md | gRPC, Express, FastAPI, Gin, Fiber |
+| **Framework frontend** | `pubspec.yaml`, `package.json`, componentes | Flutter, React, Vue, Angular |
+| **Banco de dados** | Migracoes, config, ORM | SQLite, PostgreSQL, MongoDB |
+| **ORM / Query builder** | Imports, arquivos gerados | SQLC, GORM, Prisma, TypeORM, Drift |
+| **Framework de teste** | Arquivos `*_test.*`, 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 |
+
+### 3. Construir o Perfil de Testes do Projeto
+
+Com base na deteccao, monte mentalmente (e aplique) o perfil:
+
+```
+Perfil de Testes do Projeto:
+- Linguagem: [detectada]
+- Framework: [detectado]
+- Arquitetura: [detectada] (camadas: [lista])
+- Framework de teste: [detectado]
+- Padrao de mock: [detectado]
+- Convencao de nomes: [detectada]
+- Extensao de teste: [detectada] (ex: _test.go, .test.ts, _test.dart)
+- Padrao de arquivos: [detectado] (ex: mesmo dir, pasta __tests__, pasta test/)
+```
+
+> **Toda a estrategia de testes DEVE ser adaptada ao perfil detectado.**
+> NAO assuma Go, gRPC, testify ou qualquer stack especifica sem antes confirmar.
+
+---
+
+## PONTO CRITICO: Pesquisa Obrigatoria do Projeto
+
+Apos detectar a stack, **ANTES de gerar qualquer teste**, voce DEVE:
+
+### 1. Buscar testes existentes
+- Encontrar todos os arquivos de teste no projeto (usando o padrao detectado: `*_test.go`, `*.test.ts`, `*_test.dart`, `test_*.py`, etc.)
+- Ler os testes encontrados para entender padroes e convencoes
+- Identificar cenarios ja cobertos vs lacunas
+
+### 2. Identificar frameworks e ferramentas de teste
+- Framework de teste (detectado no Passo Zero)
+- Bibliotecas de mock e assertion
+- Patterns de testes (table-driven, parametrized, subtests, etc.)
+
+### 3. Mapear helpers, fixtures e mocks reutilizaveis
+- Funcoes helper de teste existentes
+- Fixtures, factory functions, builders
+- Mocks ja implementados
+- Setup/teardown patterns
+
+### 4. Entender convencoes de nomenclatura de testes
+- Padrao de nomes de funcoes/metodos de teste
+- Organizacao de arquivos de teste
+- Agrupamento de suites/subtests
+
+> **Nunca gere testes sem antes pesquisar o projeto.**
+> Testes devem seguir os padroes ja estabelecidos no codebase.
+
+---
+
+## Mapeamento de Testes por Camada
+
+**IMPORTANTE**: O mapeamento abaixo deve ser **adaptado a arquitetura detectada** no Passo Zero. Identifique as camadas reais do projeto e gere o mapeamento correspondente.
+
+### Principio Universal (qualquer stack)
+
+| Camada | Tipo de Teste | O que testar | Mock de |
+|--------|--------------|-------------|---------|
+| **Apresentacao** (handler, controller, widget) | Unitario | Validacao de entrada, mapeamento request/response, codigos de status | Camada de negocio |
+| **Negocio** (service, use case, cubit/bloc) | Unitario | Regras de negocio, validacao, orquestracao, erros de dominio | Camada de dados |
+| **Dados** (repository, DAO, data source) | Integracao | CRUD, queries, mapeamento de modelos, constraints | Banco real ou in-memory |
+| **E2E** | E2E | Fluxo completo ponta a ponta | Nenhum (stack real) |
+
+### Exemplo: Go/gRPC (referencia)
+
+Se o projeto for Go com gRPC, o mapeamento tipico e:
+
+| Camada | Tipo de Teste | O que testar | Mock de |
+|--------|--------------|-------------|---------|
+| Handler gRPC | Unitario | Validacao protovalidate, mapeamento request/response, codigos gRPC | Service |
+| Service | Unitario | Regras de negocio, erros exportados, orquestracao | Repository |
+| Repository | Integracao | CRUD, queries SQLC, mapeamento dominio<>SQLC, UUID | SQLite in-memory |
+| E2E | E2E | Fluxo completo gRPC client->handler->service->repo->banco | Nenhum |
+
+### Exemplo: Flutter/Dart (referencia)
+
+Se o projeto for Flutter, o mapeamento tipico e:
+
+| Camada | Tipo de Teste | O que testar | Mock de |
+|--------|--------------|-------------|---------|
+| Widget/Page | Widget test | Renderizacao, interacao, estados visuais | Cubit/BLoC/Provider |
+| Cubit/BLoC | Unitario | Transicoes de estado, regras de negocio, erros | Repository |
+| Repository | Unitario | Mapeamento model<>entity, tratamento de erros | DataSource |
+| DataSource | Integracao | Chamadas HTTP/API, parsing de JSON, cache local | MockClient/MockDB |
+| E2E | Integration test | Fluxo completo de navegacao e interacao | Nenhum |
+
+### Exemplo: Node/Express (referencia)
+
+Se o projeto for Node.js com Express, o mapeamento tipico e:
+
+| Camada | Tipo de Teste | O que testar | Mock de |
+|--------|--------------|-------------|---------|
+| Route/Controller | Unitario | Validacao, status codes, response format | Service |
+| Service | Unitario | Regras de negocio, erros customizados | Repository |
+| Repository | Integracao | Queries, ORM operations, constraints | DB real ou in-memory |
+| E2E | E2E (supertest) | Fluxo HTTP completo | Nenhum |
+
+> **Use o exemplo mais proximo da stack detectada como referencia, mas SEMPRE adapte ao projeto real.**
+
+---
+
+## Guardrails QA (Inviolaveis)
+
+### DEVE
+
+1. **NUNCA gere testes genericos** — cada teste deve ter cenario especifico, input concreto e resultado esperado verificavel
+2. **NUNCA pule cenarios de erro** — todo fluxo de sucesso deve ter pelo menos 2 cenarios de falha correspondentes
+3. **SEMPRE mapeie criterios de Aceite Tecnico (secao 9)** para testes (rastreabilidade obrigatoria na secao 10.6)
+4. **SEMPRE considere boundary values** e edge cases (limites de string, valores nulos, zero, negativos)
+5. **SEMPRE respeite os padroes de teste existentes** no projeto (nomenclatura, estrutura, frameworks)
+6. **NUNCA invente funcionalidades** nao mencionadas na TaskCard
+7. **Quando usado como subagente**, retorne APENAS o conteudo da secao 10 (sem introducao, sem explicacao extra)
+8. **SEMPRE identifique testes existentes a modificar** com base nos arquivos da secao 8
+9. **SEMPRE preencha todas as 6 subsecoes** (10.1 a 10.6) — use "N/A — [justificativa]" quando nao aplicavel
+
+### NAO DEVE
+
+1. **NUNCA** gere testes sem pesquisar o projeto primeiro
+2. **NUNCA** use nomes de testes vagos como "testa funcionalidade X"
+3. **NUNCA** omita o campo Mock/Setup — explique o que deve ser mockado ou preparado
+4. **NUNCA** gere testes que dependam de estado externo nao controlado
+5. **NUNCA** ignore testes de concorrencia quando a task envolve acesso concorrente
+6. **NUNCA** escreva cenarios sem input e output esperado concretos
+
+---
+
+## Regras de Teste por Tipo de Task
+
+| 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 |
+| Task cria/modifica **navegacao ou rota** | Testar que a navegacao funciona corretamente com parametros |
+
+---
+
+## Checklist de Qualidade Pre-Entrega
+
+Antes de entregar a secao 10 enriquecida, valide que:
+
+- [ ] Todos os criterios de Aceite Tecnico (secao 9) tem pelo menos um teste correspondente na secao 10.6
+- [ ] Cada componente de apresentacao tem testes de validacao, mapeamento e codigos de resposta
+- [ ] Cada componente de negocio tem testes de regras de negocio e erros de dominio
+- [ ] Cada componente de dados tem testes de CRUD e constraints
+- [ ] Cenarios de erro cobrem: timeout, duplicidade, not found, validacao, auth (secao 10.5)
+- [ ] Boundary values foram considerados (string vazia, tamanho maximo, zero, nulo)
+- [ ] Testes usam o framework e padroes detectados no Passo Zero (secao 10.4)
+- [ ] Mocks e setup estao claramente definidos para cada teste
+- [ ] Nomenclatura segue padroes do projeto
+- [ ] Testes existentes a modificar foram identificados (secao 10.1)
+- [ ] Rastreabilidade Aceite Tecnico -> Testes esta preenchida (secao 10.6)
+- [ ] Todas as 6 subsecoes (10.1 a 10.6) estao preenchidas ou marcadas N/A
+
+---
+
+## Entrada
+
+$ARGUMENTS

package/frameworks/skills/taskcard-qa-expert/templates/task_tests_template.md

@@ -0,0 +1,78 @@
+# Secao 10. Testes
+
+## 10.1 Testes Existentes a Modificar
+Testes que ja existem e precisam ser atualizados por causa das mudancas desta task:
+
+| Arquivo de Teste | O que Modificar | Motivo |
+|-----------------|-----------------|--------|
+| `path/to/existing_test` | [descrever mudanca: novos cenarios, mocks atualizados, fixtures alteradas] | [interface alterada, novo campo, regra de negocio modificada] |
+
+> Se nenhum teste existente precisa ser modificado, indicar "Nenhum teste existente impactado — [justificativa]."
+
+## 10.2 Testes a Criar
+Novos testes que devem ser criados para cobrir as mudancas desta task:
+
+### Unitarios
+- [ ] **[arquivo_teste] TestNomeFuncao_Sucesso** — Cenario: [descricao precisa]. Input: [dados concretos]. Expected: [resultado especifico]. Mock: [o que mockar e retorno]
+- [ ] **[arquivo_teste] TestNomeFuncao_ErroValidacao** — Cenario: [descricao]. Input: [dados invalidos]. Expected: [erro especifico]. Mock: [se aplicavel]
+- [ ] **[arquivo_teste] TestNomeFuncao_ErroDependencia** — Cenario: [descricao]. Input: [dados validos]. Expected: [erro wrapped]. Mock: [dependencia retorna erro]
+
+### Integracao
+- [ ] **[arquivo_teste] TestIntegracao_FluxoCompleto** — Setup: [banco in-memory, migracoes, seed data]. Fluxo: [create -> get -> verify]. Validacao: [dados consistentes]
+- [ ] **[arquivo_teste] TestIntegracao_ErroConstraint** — Setup: [registro existente]. Fluxo: [insert duplicado]. Validacao: [erro de constraint]
+
+### E2E
+- [ ] **[arquivo_teste] TestE2E_FluxoPrincipal** — Pre-condicao: [estado inicial]. Passos: [request -> validar response -> verificar banco]. Pos-condicao: [estado final]
+
+> Se uma categoria nao se aplica a esta task, indicar "N/A — [justificativa]."
+
+## 10.3 Cenarios Obrigatorios
+Lista de cenarios que DEVEM ser cobertos pelos testes:
+
+### Sucesso (caminho feliz)
+- [ ] [descricao do cenario de sucesso principal]
+- [ ] [descricao de variacao de sucesso, se aplicavel]
+
+### Erro e Validacao
+- [ ] [cenario de erro de validacao de entrada]
+- [ ] [cenario de recurso nao encontrado]
+- [ ] [cenario de duplicidade/conflito]
+
+### Edge Cases e Boundary Values
+- [ ] [valor nulo ou vazio]
+- [ ] [valor no limite maximo]
+- [ ] [valor no limite minimo]
+- [ ] [caracteres especiais ou Unicode]
+
+### Concorrencia (se aplicavel)
+- [ ] [cenario de acesso concorrente]
+
+## 10.4 Padroes de Teste
+Referencia dos padroes de teste a seguir (identificados no Passo Zero):
+- **Framework**: [detectado — ex: testify, jest, pytest, flutter_test]
+- **Convencao de nomes**: [detectada — ex: Test<Layer>_<Function>_<Scenario>, describe/it, test_<function>]
+- **Fixture/Setup**: [detectado — ex: banco in-memory, factory functions, fixtures, beforeEach]
+- **Mocks**: [detectado — ex: interfaces com mock, jest.mock, mocktail, mockito]
+- **Patterns**: [detectado — ex: table-driven tests, parametrized, subtests, AAA]
+
+## 10.5 Cenarios de Erro
+Mapeamento exaustivo de cenarios de erro com detalhes tecnicos:
+
+| Cenario | Trigger | Expected | Codigo/Status | Log |
+|---------|---------|----------|---------------|-----|
+| [descricao do erro] | [o que causa o erro] | [comportamento esperado] | [codigo gRPC, HTTP status, excecao] | [mensagem de log esperada] |
+| [validacao invalida] | [input fora do esperado] | [rejeitar com mensagem clara] | [codes.InvalidArgument / 400 / ValidationError] | [log de warn com detalhes] |
+| [recurso nao encontrado] | [ID inexistente] | [retornar not found] | [codes.NotFound / 404 / NotFoundException] | [log de info com ID buscado] |
+| [dependencia falha] | [banco/servico externo indisponivel] | [erro wrapped com contexto] | [codes.Internal / 500 / InternalError] | [log de error com stack] |
+
+## 10.6 Rastreabilidade: Aceite Tecnico -> Testes
+Mapeamento entre cada criterio de aceite (secao 9) e os testes que o validam:
+
+| # | Criterio de Aceite (secao 9) | Teste(s) Correspondente(s) | Tipo |
+|---|------------------------------|---------------------------|------|
+| 1 | [criterio copiado da secao 9] | [TestNomeFuncao_Sucesso, TestIntegracao_FluxoCompleto] | [Unitario, Integracao] |
+| 2 | [criterio copiado da secao 9] | [TestNomeFuncao_ErroValidacao] | [Unitario] |
+| 3 | [criterio copiado da secao 9] | [TestE2E_FluxoPrincipal] | [E2E] |
+
+> **Todo criterio de aceite DEVE ter pelo menos um teste correspondente.**
+> Se um criterio nao e testavel automaticamente, justifique e indique como sera validado manualmente.

package/frameworks/templates/prompt_template.md

@@ -0,0 +1,164 @@
+# 🎯 Prompt Template 5 Estrelas
+
+> **Como usar:** Preencha cada seção abaixo com as informações específicas da sua tarefa. Delete as dicas entre colchetes após preencher.
+
+> 💡 **Novo!** Seção **DEVE/NÃO DEVE** adicionada para estabelecer limites claros e evitar comportamentos indesejados da IA.
+
+---
+
+## 1. 🌍 Contexto
+
+[Descreva o ambiente técnico, stack, público e restrições relevantes]
+
+**Linguagem/Framework:**
+[Ex: Python 3.11 com FastAPI / Go com Gin / React com TypeScript]
+
+**Arquitetura/Padrão:**
+[Ex: Clean Architecture / Arquitetura em camadas / MVC / Microserviços]
+
+**Público-alvo:**
+[Ex: Desenvolvedores backend / Equipe de frontend / Arquitetos de software]
+
+**Limitações/Restrições:**
+[Ex: Não pode usar bibliotecas externas / Deve ser compatível com PostgreSQL 14 / Budget limitado de memória]
+
+---
+
+## 2. 🎯 Objetivo
+
+[Descreva claramente o que você deseja obter da IA]
+
+**O que precisa ser entregue:**
+[Ex: Implementar feature de autenticação JWT / Criar testes unitários / Refatorar código legado]
+
+**Propósito da tarefa:**
+[Ex: Melhorar segurança / Aumentar cobertura de testes / Facilitar manutenção]
+
+**Resultado esperado:**
+[Ex: Código funcional / Documentação técnica / Plano de implementação]
+
+---
+
+## 3. ⚙️ Instruções Específicas
+
+[Defina COMO a IA deve construir a resposta]
+
+**Detalhes técnicos:**
+- [Ex: Usar pgx/v5 para conexão com banco]
+- [Ex: Implementar validação de entrada com tags do Gin]
+- [Ex: Seguir padrão de nomenclatura do projeto]
+
+**Restrições:**
+- [Ex: NÃO usar bibliotecas ORM]
+- [Ex: NÃO modificar arquivos de configuração existentes]
+- [Ex: Manter compatibilidade com API v1]
+
+**Estrutura lógica:**
+- [Ex: Separar camadas: handler → service → repository]
+- [Ex: Implementar tratamento de erros em cada camada]
+- [Ex: Adicionar logs estruturados]
+
+---
+
+## 4. ✓ Regras: DEVE / NÃO DEVE
+
+[Defina limites claros do que a IA DEVE e NÃO DEVE fazer]
+
+### ✅ DEVE:
+- [Ex: DEVE usar Context para operações de I/O]
+- [Ex: DEVE seguir o padrão de nomenclatura do projeto (PascalCase/camelCase)]
+- [Ex: DEVE implementar tratamento de erros com contexto usando fmt.Errorf]
+- [Ex: DEVE adicionar comentários explicativos em lógicas complexas]
+- [Ex: DEVE validar todos os inputs antes de processar]
+- [Ex: DEVE retornar erros apropriados em cada camada]
+- [Ex: DEVE escrever testes para código crítico]
+- [Ex: DEVE formatar código com gofmt/prettier]
+
+### ❌ NÃO DEVE:
+- [Ex: NÃO DEVE usar bibliotecas ORM (usar apenas SQL puro)]
+- [Ex: NÃO DEVE expor informações sensíveis em logs]
+- [Ex: NÃO DEVE fazer breaking changes na API pública]
+- [Ex: NÃO DEVE ignorar erros silenciosamente]
+- [Ex: NÃO DEVE criar código duplicado (DRY - Don't Repeat Yourself)]
+- [Ex: NÃO DEVE usar hardcoded values (usar variáveis de ambiente)]
+- [Ex: NÃO DEVE modificar arquivos de migração já aplicados]
+- [Ex: NÃO DEVE pular validações de segurança]
+
+### ⚠️ ATENÇÃO ESPECIAL:
+- [Ex: Ao manipular senhas, SEMPRE usar hashing (bcrypt)]
+- [Ex: Ao fazer queries SQL, SEMPRE usar prepared statements]
+- [Ex: Ao lidar com datas, SEMPRE usar UTC]
+
+---
+
+## 5. 📋 Formato da Resposta
+[Ex: Se a resposta for longa, use subtítulos (##) e listas numeradas para facilitar leitura.]
+
+[Especifique COMO você quer receber o resultado]
+
+**Estrutura desejada:**
+[Ex: Código completo com comentários / Plano em tópicos / Tabela comparativa / Diagrama + explicação]
+
+**Limites:**
+[Ex: Máximo 200 linhas de código / Resposta em até 3 parágrafos / Sem dependências externas]
+
+**Estilo:**
+[Ex: Responder em português / Usar markdown / Incluir exemplos de uso / Formato técnico e direto]
+
+---
+
+## 6. 👤 Persona / Tom
+
+[Defina a perspectiva e forma de comunicação da IA]
+
+**Perspectiva:**
+[Ex: Desenvolvedor sênior / Arquiteto de software / Instrutor técnico / Consultor especializado]
+
+**Tom da explicação:**
+[Ex: Técnico e objetivo / Didático e detalhado / Consultivo e estratégico]
+
+**Nível de profundidade:**
+[Ex: Explicações básicas / Aprofundado com edge cases / Foco em performance / Visão de alto nível]
+
+---
+
+## 7. ✅ Critérios de Aceite
+[Liste condições objetivas que determinam se o resultado está correto]
+
+- [ ] [Ex: O código compila sem erros]
+- [ ] [Ex: Segue o padrão de arquitetura em camadas]
+- [ ] [Ex: Inclui tratamento de erros]
+- [ ] [Ex: Possui testes unitários com 80%+ de cobertura]
+- [ ] [Ex: Documentação atualizada]
+- [ ] [Ex: Performance < 100ms por requisição]
+
+---
+
+## 8. 💬 Exemplos *(opcional)*
+
+[Forneça exemplos de entrada e saída esperada se achar necessário]
+
+**Exemplo 1:**
+```
+Entrada: [Descreva a entrada]
+Saída esperada: [Descreva a saída]
+```
+
+**Exemplo 2:**
+```
+Entrada: [Descreva a entrada]
+Saída esperada: [Descreva a saída]
+```
+
+---
+
+## 💡 Dicas de Uso
+
+* ✅ **Mínimo obrigatório:** Seções 1–6 (Contexto + Objetivo + Instruções + DEVE/NÃO DEVE + Formato + Persona)
+* ⭐ **Para 6 estrelas:** Adicione seções 7–8 (Critérios de Aceite + Exemplos)
+* 🎯 **Seja específico:** Quanto mais detalhes relevantes, melhor a resposta
+* 🎭 **Use DEVE/NÃO DEVE:** Esta seção é crucial para evitar comportamentos indesejados
+* 🔄 **Itere:** Ajuste o prompt baseado nos resultados obtidos
+* 📏 **Balanceie:** Detalhes suficientes sem ser verboso demais
+
+---

package/package.json

@@ -0,0 +1,28 @@
+{
+  "name": "adi_dev_workflow",
+  "version": "1.0.0",
+  "description": "Install SDD, miniStack and TaskCard development frameworks for Claude Code and Cursor",
+  "type": "module",
+  "bin": {
+    "adi_dev_workflow": "./bin/index.js"
+  },
+  "files": [
+    "bin/",
+    "src/",
+    "frameworks/"
+  ],
+  "keywords": [
+    "claude-code",
+    "cursor",
+    "sdd",
+    "ministack",
+    "taskcard",
+    "dev-workflow",
+    "ai-frameworks"
+  ],
+  "author": "",
+  "license": "MIT",
+  "dependencies": {
+    "prompts": "^2.4.2"
+  }
+}

package/src/cli.js

@@ -0,0 +1,121 @@
+import prompts from 'prompts';
+import { install } from './installer.js';
+
+const BANNER = `
+  ╔══════════════════════════════════════╗
+  ║      adi_dev_workflow  v1.0         ║
+  ║  SDD · miniStack · TaskCard         ║
+  ╚══════════════════════════════════════╝
+`;
+
+function parseArgs(argv) {
+  const args = { ide: null, all: false };
+  for (let i = 0; i < argv.length; i++) {
+    if (argv[i] === '--all') args.all = true;
+    if (argv[i] === '--ide' && argv[i + 1]) {
+      args.ide = argv[++i];
+    }
+  }
+  return args;
+}
+
+export async function run(argv) {
+  console.log(BANNER);
+
+  const args = parseArgs(argv);
+  let target = args.ide;
+  let frameworks;
+
+  // IDE selection
+  if (!target || !['claude', 'cursor'].includes(target)) {
+    const res = await prompts({
+      type: 'select',
+      name: 'target',
+      message: 'Which IDE are you using?',
+      choices: [
+        { title: 'Claude Code (.claude/)', value: 'claude' },
+        { title: 'Cursor (.cursor/)', value: 'cursor' },
+      ],
+    });
+    if (!res.target) {
+      console.log('Cancelled.');
+      return;
+    }
+    target = res.target;
+  }
+
+  // Framework selection
+  if (args.all) {
+    frameworks = ['sdd', 'ministack', 'taskcard', 'shared'];
+  } else {
+    const res = await prompts({
+      type: 'multiselect',
+      name: 'frameworks',
+      message: 'Which frameworks do you want to install?',
+      choices: [
+        {
+          title: 'SDD - Specification-Driven Development',
+          description: 'PRD -> Spec Tech -> Task Plan -> Code',
+          value: 'sdd',
+          selected: true,
+        },
+        {
+          title: 'miniStack - Minimal Feature Stack',
+          description: 'Intent -> Scope -> Tasks -> Code',
+          value: 'ministack',
+          selected: true,
+        },
+        {
+          title: 'TaskCard - Atomic Work Units',
+          description: 'Description -> Card -> Code',
+          value: 'taskcard',
+          selected: true,
+        },
+        {
+          title: 'Shared tools',
+          description: 'Prompt generator, Linear sync',
+          value: 'shared',
+          selected: true,
+        },
+      ],
+      hint: '- Space to toggle. Return to submit',
+    });
+    if (!res.frameworks || res.frameworks.length === 0) {
+      console.log('No frameworks selected. Cancelled.');
+      return;
+    }
+    frameworks = res.frameworks;
+  }
+
+  const cwd = process.cwd();
+  const ideLabel = target === 'claude' ? '.claude/' : '.cursor/';
+
+  console.log(`\nInstalling to ${ideLabel} ...\n`);
+
+  const summary = await install({ cwd, target, frameworks });
+
+  console.log(`  Done!\n`);
+  console.log(`  ${summary.skills} skills + ${summary.commands} commands + ${summary.templates} templates installed.\n`);
+
+  // Usage hints
+  const hints = [];
+  if (frameworks.includes('sdd')) {
+    hints.push('  /sdd:generate-prd             Start a new feature with SDD');
+  }
+  if (frameworks.includes('ministack')) {
+    hints.push('  /ministack:generate-intent     Start with miniStack');
+  }
+  if (frameworks.includes('taskcard')) {
+    hints.push('  /taskcard:generate-taskcard    Create a task card');
+  }
+  if (frameworks.includes('shared')) {
+    hints.push('  /generate-prompt               Generate an optimized prompt');
+    hints.push('  /sync-tasks-to-linear          Sync tasks to Linear');
+  }
+
+  if (hints.length > 0) {
+    console.log('  Usage:\n');
+    for (const h of hints) console.log(h);
+    console.log('');
+  }
+}