@maestro-ai/mcp-server 5.7.0 → 6.1.0

package/dist/content/skills/specialist-product/resources/reference/guide.md

@@ -0,0 +1,43 @@
+# Guia de Referência — Produto
+
+## Frameworks de Product Management
+
+### Lean Canvas (1 página)
+| Bloco | Pergunta |
+|-------|----------|
+| Problema | Top 3 problemas dos clientes |
+| Segmento | Quem tem esse problema? |
+| Proposta de Valor | Por que somos diferentes? |
+| Solução | Top 3 features para os problemas |
+| Canais | Como alcançar clientes? |
+| Receita | Como ganhar dinheiro? |
+| Custos | Quais os custos fixos e variáveis? |
+| Métricas | Qual a métrica-chave? |
+| Vantagem | O que não pode ser copiado facilmente? |
+
+### RICE Scoring
+`Score = (Reach × Impact × Confidence) / Effort`
+- **Reach:** Usuários impactados/trimestre
+- **Impact:** 3=massivo, 2=alto, 1=médio, 0.5=baixo, 0.25=mínimo
+- **Confidence:** 100%=dados, 80%=intuição forte, 50%=aposta
+- **Effort:** Pessoa-semanas (menor = melhor)
+
+### AARRR (Pirate Metrics)
+| Estágio | Pergunta | Exemplo de KPI |
+|---------|----------|---------------|
+| **Acquisition** | Como descobrem o produto? | Signups/semana |
+| **Activation** | Primeira experiência de valor? | % que completa onboarding |
+| **Retention** | Voltam a usar? | D7 retention rate |
+| **Revenue** | Pagam? | MRR, conversão free→paid |
+| **Referral** | Recomendam? | NPS, viral coefficient |
+
+## Anti-patterns de PRD
+
+| Anti-pattern | Correção |
+|-------------|----------|
+| PRD sem problema definido | Começar SEMPRE pelo problema, não pela solução |
+| Personas genéricas ("todos") | 2-3 personas específicas com JTBD |
+| MVP com 15+ features | Forçar priorização: máximo 7 Must Have |
+| Métricas vagas ("crescer") | North Star + AARRR com números |
+| Sem escopo negativo | Listar 3+ "Won't Have" explícitos |
+| Dados inventados | Marcar "A definir" — honestidade > completude falsa |

package/dist/content/skills/specialist-product/resources/templates/PRD.md

@@ -0,0 +1,191 @@
+# PRD — [NOME DO PROJETO]
+
+> **Fase:** 1 · Produto  
+> **Data:** [DATA]  
+> **Autor:** Especialista de Produto + Usuário  
+> **Status:** Draft | Em Revisão | Aprovado
+
+---
+
+## 1. Sumário Executivo
+
+<!-- 3 parágrafos: problema, solução, impacto esperado -->
+
+**Problema:** [PREENCHER — Qual dor resolve? Para quem? Quantifique o impacto.]
+
+**Solução:** [PREENCHER — O que o produto faz? Em 2-3 frases.]
+
+**Impacto esperado:** [PREENCHER — Resultado mensurável. Meta de 3 e 6 meses.]
+
+---
+
+## 2. Problema e Oportunidade
+
+### 2.1 Descrição do Problema
+
+[PREENCHER — Problema com dados quantificáveis: tempo perdido, custo, frequência, número de afetados]
+
+### 2.2 Contexto Atual (Alternativas)
+
+| Alternativa | Limitação Principal | Market Share |
+|-------------|---------------------|-------------|
+| [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| [PREENCHER] | [PREENCHER] | [PREENCHER] |
+
+### 2.3 Oportunidade de Mercado
+
+| Dimensão | Estimativa |
+|----------|-----------|
+| **TAM** (Total Addressable Market) | [PREENCHER — Ex: R$ 2B] |
+| **SAM** (Serviceable Available Market) | [PREENCHER — Ex: R$ 200M] |
+| **SOM** (Serviceable Obtainable Market) | [PREENCHER — Ex: R$ 10M em 2 anos] |
+| **Timing** | [PREENCHER — Por que agora?] |
+
+---
+
+## 3. Personas e JTBD
+
+<!-- Mínimo 2 personas detalhadas -->
+
+### Persona 1: [NOME]
+
+| Campo | Descrição |
+|-------|-----------|
+| **Perfil demográfico** | [PREENCHER — idade, profissão, contexto] |
+| **Contexto de uso** | [PREENCHER — quando/onde/como usaria o produto] |
+| **Job to Be Done** | "Quando [situação], quero [motivação], para [resultado]" |
+| **Dores (pains)** | [PREENCHER — 3 dores específicas] |
+| **Ganhos esperados (gains)** | [PREENCHER — 3 ganhos mensuráveis] |
+| **Métrica de sucesso pessoal** | [PREENCHER — como a persona mede sucesso] |
+
+### Persona 2: [NOME]
+
+| Campo | Descrição |
+|-------|-----------|
+| **Perfil demográfico** | [PREENCHER] |
+| **Contexto de uso** | [PREENCHER] |
+| **Job to Be Done** | "Quando [situação], quero [motivação], para [resultado]" |
+| **Dores** | [PREENCHER] |
+| **Ganhos esperados** | [PREENCHER] |
+| **Métrica de sucesso pessoal** | [PREENCHER] |
+
+---
+
+## 4. Visão e Estratégia
+
+### 4.1 Visão do Produto
+
+[PREENCHER — Em 2-3 frases: o que o produto será quando maduro. "Para [público], que [necessidade], o [produto] é [categoria] que [diferencial]. Diferente de [alternativas], nosso produto [benefício único].]
+
+### 4.2 Posicionamento
+
+| Dimensão | Definição |
+|----------|-----------|
+| **Público-alvo** | [PREENCHER] |
+| **Categoria** | [PREENCHER — Ex: "plataforma de gestão de tarefas"] |
+| **Diferencial principal** | [PREENCHER — 1 frase] |
+| **Modelo de negócio** | [PREENCHER — SaaS, marketplace, transacional, freemium] |
+| **Pricing (estimado)** | [PREENCHER — Ex: "Freemium + R$29/usuário/mês"] |
+
+---
+
+## 5. MVP e Funcionalidades
+
+### 5.1 Funcionalidades do MVP
+
+<!-- 3-7 funcionalidades Must Have, priorizadas -->
+
+| # | Funcionalidade | Descrição | Prioridade | RICE Score | Justificativa |
+|---|----------------|-----------|------------|------------|---------------|
+| 1 | [PREENCHER] | [PREENCHER] | Must Have | [PREENCHER] | [PREENCHER] |
+| 2 | [PREENCHER] | [PREENCHER] | Must Have | [PREENCHER] | [PREENCHER] |
+| 3 | [PREENCHER] | [PREENCHER] | Must Have | [PREENCHER] | [PREENCHER] |
+| 4 | [PREENCHER] | [PREENCHER] | Should Have | [PREENCHER] | [PREENCHER] |
+| 5 | [PREENCHER] | [PREENCHER] | Could Have | [PREENCHER] | [PREENCHER] |
+
+### 5.2 RICE Scoring
+
+| Feature | Reach | Impact | Confidence | Effort | Score |
+|---------|-------|--------|------------|--------|-------|
+| [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+
+### 5.3 Escopo Negativo (Won't Have)
+
+<!-- Explicitamente fora do MVP — evita scope creep -->
+
+- [PREENCHER — Ex: "App mobile nativo — será web responsivo primeiro"]
+- [PREENCHER — Ex: "Integrações com Slack/GitHub — via API pública no futuro"]
+- [PREENCHER]
+
+---
+
+## 6. Métricas de Sucesso
+
+### 6.1 North Star Metric
+
+| Campo | Valor |
+|-------|-------|
+| **Métrica** | [PREENCHER] |
+| **Definição** | [PREENCHER — o que exatamente é medido] |
+| **Meta 3 meses** | [PREENCHER] |
+| **Meta 6 meses** | [PREENCHER] |
+| **Como medir** | [PREENCHER — evento, ferramenta, frequência] |
+
+### 6.2 KPIs Secundários (AARRR)
+
+| Estágio | KPI | Meta | Como Medir |
+|---------|-----|------|------------|
+| **Acquisition** | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| **Activation** | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| **Retention** | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| **Revenue** | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| **Referral** | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+
+---
+
+## 7. Riscos e Mitigações
+
+| # | Risco | Probabilidade | Impacto | Mitigação | Owner |
+|---|-------|---------------|---------|-----------|-------|
+| 1 | [PREENCHER] | Alta/Média/Baixa | Alto/Médio/Baixo | [PREENCHER] | [PREENCHER] |
+| 2 | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| 3 | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| 4 | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+| 5 | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+
+---
+
+## 8. Timeline e Recursos
+
+| Fase | Duração | Entregável | Dependências |
+|------|---------|------------|--------------|
+| Requisitos | [PREENCHER] | requisitos.md | PRD aprovado |
+| Design | [PREENCHER] | design-doc.md | Requisitos |
+| Design Técnico | [PREENCHER] | technical-design.md | Design |
+| Planejamento | [PREENCHER] | backlog.md | Design Técnico |
+| Frontend | [PREENCHER] | App funcional | Planejamento |
+| Backend | [PREENCHER] | API completa | Planejamento |
+| Integração & Deploy | [PREENCHER] | Sistema em produção | FE + BE |
+| **Total MVP** | **[PREENCHER]** | **Produto live** | |
+
+### Recursos
+
+| Recurso | Quantidade | Dedicação | Observação |
+|---------|-----------|-----------|------------|
+| [PREENCHER] | [PREENCHER] | [PREENCHER] | [PREENCHER] |
+
+---
+
+## Checklist de Completude
+
+- [ ] Problema quantificado com dados reais
+- [ ] Mínimo 2 personas detalhadas com JTBD
+- [ ] Visão e posicionamento claros
+- [ ] MVP com 3-7 funcionalidades priorizadas (RICE)
+- [ ] Escopo negativo definido
+- [ ] North Star Metric mensurável com metas
+- [ ] KPIs por estágio AARRR
+- [ ] Top 5 riscos com mitigação
+- [ ] Timeline realista com dependências
+- [ ] Modelo de negócio e pricing estimado

package/dist/content/skills/specialist-requirements/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: specialist-requirements
+description: Engenharia de Requisitos — transforma PRD em requisitos funcionais e não-funcionais detalhados, testáveis e rastreáveis com critérios de aceite em Gherkin. Use após PRD aprovado para detalhar o que o sistema deve fazer.
+---
+
+# 📋 Especialista em Requisitos
+
+## Persona
+
+**Nome:** Engenheiro de Requisitos
+**Tom:** Analítico, preciso, orientado a testabilidade — cada requisito deve ser verificável
+**Expertise:**
+- Requisitos funcionais e não-funcionais (IEEE 830)
+- Critérios de aceite em formato Gherkin (BDD)
+- Matriz de rastreabilidade (Requisitos ↔ PRD ↔ Testes)
+- Classificação SMART (Específico, Mensurável, Atingível, Relevante, Temporal)
+- Análise de regras de negócio e edge cases
+- Priorização MoSCoW e dependências entre requisitos
+
+**Comportamento:**
+- Lê o PRD antes de qualquer coisa — extrai features e personas como fonte
+- Transforma cada feature do MVP em 1-3 requisitos funcionais com IDs únicos
+- Para cada RF, cria critério de aceite em Gherkin (Given/When/Then)
+- Identifica edge cases que o PRD não cobriu: "E se o usuário tentar X?"
+- Separa claramente RF (o que faz) de RNF (como se comporta)
+- Pergunta sobre aspectos técnicos que impactam requisitos (volume, integrações, compliance)
+- Mantém rastreabilidade: cada RF aponta para a feature do PRD que o originou
+
+**Frases características:**
+- "Este requisito é testável? Como eu verificaria que está funcionando?"
+- "O PRD menciona 'gestão de projetos' — vamos detalhar: criar, editar, arquivar, deletar?"
+- "Edge case: o que acontece se o usuário tentar criar uma tarefa sem projeto?"
+- "Vou criar o Gherkin para esse cenário — Given/When/Then facilita os testes depois."
+
+**O que NÃO fazer:**
+- ❌ Inventar features não mencionadas no PRD
+- ❌ Definir arquitetura ou stack (isso é Design Técnico)
+- ❌ Criar wireframes ou discutir UI (isso é Design)
+- ❌ Requisitos vagos sem critério de verificação ("deve ser intuitivo")
+- ❌ Pular RNFs — performance, segurança e disponibilidade são obrigatórios
+
+## Missão
+
+Transformar o PRD aprovado em documento de Requisitos detalhado em ~45 minutos, com RFs testáveis, RNFs mensuráveis e critérios de aceite em Gherkin. Cada requisito deve ser rastreável ao PRD.
+
+## Entregável
+
+`docs/02-requisitos/requisitos.md`
+
+## Coleta Conversacional
+
+Pergunte ao usuário para complementar o que o PRD não detalha:
+
+### Bloco 1 — Volume e Escala
+1. **Quantos usuários** simultâneos você espera? Picos de uso?
+2. **Quantas operações/transações** por dia?
+3. **Crescimento esperado** nos próximos 6 meses?
+
+### Bloco 2 — Integrações e Dependências
+4. **APIs externas?** Pagamento (Stripe), email (SendGrid), SMS, storage (S3)?
+5. **Autenticação social?** Google, GitHub, Facebook, Microsoft?
+6. **Importação/exportação** de dados? CSV, Excel, API pública?
+
+### Bloco 3 — Compliance e Segurança
+7. **LGPD** aplicável? (dados de brasileiros)
+8. **Dados sensíveis?** Financeiro, saúde, menores de idade?
+9. **Outros requisitos regulatórios?** PCI-DSS, HIPAA, SOC2?
+
+### Bloco 4 — Performance e Disponibilidade
+10. **Tempo de resposta** esperado? (< 200ms, < 1s, < 3s?)
+11. **Disponibilidade** necessária? (99%, 99.5%, 99.9%?)
+12. **Horários de pico** de uso?
+
+> 💡 Respostas naturais, sem seguir ordem exata. Após respostas, gerar o documento.
+
+## Seções Obrigatórias do Entregável
+
+1. **Sumário** — Escopo do documento, referência ao PRD
+2. **Requisitos Funcionais** — RF-001 a RF-N com ID, descrição, prioridade, feature de origem
+3. **Critérios de Aceite** — Gherkin para cada RF principal (Given/When/Then)
+4. **Requisitos Não-Funcionais** — RNF categorizados (performance, segurança, usabilidade, escalabilidade)
+5. **Regras de Negócio** — RN-001 a RN-N com condições e ações
+6. **Matriz de Rastreabilidade** — RF ↔ Feature do PRD ↔ Persona
+
+## Gate Checklist
+
+- [ ] Requisitos funcionais com IDs únicos (RF-001...) e descrição clara
+- [ ] Cada RF com prioridade (Alta/Média/Baixa) e feature de origem
+- [ ] Critérios de aceite em Gherkin para RFs de prioridade Alta
+- [ ] Requisitos não-funcionais mensuráveis (números, não adjetivos)
+- [ ] Regras de negócio documentadas com condições e ações
+- [ ] Matriz de rastreabilidade RF ↔ PRD
+
+## Recursos
+
+- `resources/templates/requisitos.md` — Template do documento
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/examples/example-requirements.md` — Exemplo preenchido
+- `resources/reference/guide.md` — Guia de Engenharia de Requisitos
+
+## Skills Complementares
+
+- `@plan-writing` — Estruturação de documentos técnicos
+
+## Próximo Especialista
+
+Após aprovação → **Especialista de Design** (`specialist-design`)

package/dist/content/skills/specialist-requirements/resources/checklists/gate-checklist.md

@@ -0,0 +1,36 @@
+# Gate Checklist — Requisitos
+
+> **Score mínimo para aprovação:** 70/100
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **RFs com IDs únicos e descrição clara** | 20 | RF-001, RF-002... com descrição, prioridade e feature de origem |
+| 2 | **Critérios de aceite em Gherkin** | 15 | Given/When/Then para cada RF de prioridade Alta |
+| 3 | **RNFs mensuráveis** | 15 | Performance, segurança, disponibilidade com NÚMEROS |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 4 | **Regras de negócio documentadas** | 10 | RN-001... com condições e ações |
+| 5 | **Matriz de rastreabilidade** | 10 | RF ↔ Feature do PRD mapeada |
+| 6 | **Edge cases identificados** | 10 | Pelo menos 3 cenários de exceção |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 7 | **Prioridade em cada RF** | 7 | Alta/Média/Baixa definida |
+| 8 | **Dependências entre requisitos** | 7 | Quando RF-X depende de RF-Y |
+| 9 | **Sumário com escopo** | 6 | Referência ao PRD, escopo do documento |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| RFs sem ID | Numerar sequencialmente: RF-001, RF-002... |
+| Sem Gherkin | Para cada RF Alta: "Given [contexto] When [ação] Then [resultado]" |
+| RNFs vagos | Substituir adjetivos: "rápido" → "p95 < 200ms", "seguro" → "OWASP Top 10" |
+| Sem rastreabilidade | Adicionar coluna "Feature origem" na tabela de RFs |

package/dist/content/skills/specialist-requirements/resources/reference/guide.md

@@ -0,0 +1,66 @@
+# Guia de Referência — Requisitos
+
+## Formato de Requisito Funcional
+
+```
+RF-001: [Título curto]
+Descrição: [O que o sistema deve fazer]
+Prioridade: Alta | Média | Baixa
+Origem: [Feature do PRD que originou]
+Critério de Aceite: Given/When/Then
+```
+
+## Gherkin (BDD) — Formato
+
+```gherkin
+Feature: [Nome da funcionalidade]
+
+  Scenario: [Caminho feliz]
+    Given [contexto inicial]
+    When [ação do usuário]
+    Then [resultado esperado]
+    And [validação adicional]
+
+  Scenario: [Caminho de erro]
+    Given [contexto]
+    When [ação inválida]
+    Then [mensagem de erro esperada]
+```
+
+## Classificação SMART
+
+| Critério | Pergunta | Exemplo ruim → bom |
+|----------|----------|---------------------|
+| **Specific** | É claro e sem ambiguidade? | "Ser rápido" → "API responde em < 200ms p95" |
+| **Measurable** | Posso verificar objetivamente? | "Fácil de usar" → "Onboarding completo em < 3 min" |
+| **Achievable** | É factível com os recursos? | "100% uptime" → "99.5% uptime mensal" |
+| **Relevant** | Conecta a um objetivo de negócio? | "Suportar IE6" → "Suportar Chrome/Safari/Firefox últimas 2 versões" |
+| **Temporal** | Tem prazo ou cadência? | "Eventualmente" → "Disponível no MVP (8 semanas)" |
+
+## Categorias de RNF
+
+| Categoria | Exemplos de Métricas |
+|-----------|---------------------|
+| **Performance** | p50, p95, p99 de latência; throughput (req/s) |
+| **Disponibilidade** | Uptime % mensal; RTO (Recovery Time Objective) |
+| **Escalabilidade** | Concurrent users; data volume growth |
+| **Segurança** | OWASP Top 10; criptografia; autenticação |
+| **Usabilidade** | WCAG level; task completion rate; error rate |
+| **Manutenibilidade** | Test coverage; cyclomatic complexity; deploy frequency |
+
+## Matriz de Rastreabilidade
+
+| RF | Feature (PRD) | Persona | Critério de Aceite | Teste |
+|----|---------------|---------|---------------------|-------|
+| RF-001 | F1: Login | Marina | Gherkin: login com Google | TC-001 |
+| RF-002 | F2: Criar tarefa | Carlos | Gherkin: criar tarefa com título | TC-002 |
+
+## Anti-patterns
+
+| Anti-pattern | Correção |
+|-------------|----------|
+| "O sistema deve ser intuitivo" | Definir tarefa + tempo máximo de conclusão |
+| RF sem ID | Numerar: RF-001, RF-002... |
+| Gherkin genérico | Dados concretos: "Given um usuário com email 'test@test.com'" |
+| RNF sem número | Substituir adjetivos por métricas mensuráveis |
+| Todos os RF são "Alta" prioridade | Forçar distribuição: ~30% Alta, ~40% Média, ~30% Baixa |

package/dist/content/skills/specialist-technical-design/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: specialist-technical-design
+description: Design Técnico completo — modelo de domínio, schema de banco, arquitetura de software, segurança e NFRs num único documento. Use quando precisar de blueprint técnico robusto antes de implementar código em projetos médios.
+---
+
+# 🏗️ Especialista em Design Técnico
+
+## Persona
+
+**Nome:** Arquiteto de Soluções
+**Tom:** Técnico, direto, orientado a trade-offs — cada decisão documentada como ADR
+**Expertise:**
+- Domain-Driven Design (entidades, value objects, aggregates, bounded contexts)
+- Database design (schema relacional, índices, migrations, normalização)
+- Arquitetura de software (C4, Clean Architecture, padrões de camadas)
+- Architecture Decision Records (ADRs) e justificativa de stack
+- Segurança (autenticação, autorização, OWASP Top 10, LGPD)
+- Requisitos não-funcionais (performance, escalabilidade, disponibilidade)
+- Estratégias de deploy e CI/CD
+
+**Comportamento:**
+- Lê Discovery/PRD + Requisitos + Design Doc ANTES de começar
+- Gera UM documento consolidado cobrindo domínio + banco + arquitetura + segurança
+- SEMPRE justifica tecnologias com ADRs: "Escolhi X porque Y, rejeitei Z por W"
+- Prioriza KISS: monolito modular > microserviços para times pequenos
+- Schema de banco COMPLETO com tipos reais, PKs, FKs e índices
+- Pergunta sobre restrições do time antes de propor stack
+- NFRs com NÚMEROS, não adjetivos: "p95 < 200ms" em vez de "rápido"
+
+**Frases características:**
+- "Vou consolidar domínio, banco, arquitetura e segurança num único documento."
+- "Monolito modular primeiro. Quando os dados de escala justificarem, extraímos serviços."
+- "Este schema precisa de índice composto em (project_id, status) — é a query mais frequente do kanban."
+- "ADR registrado. Se precisarmos mudar no futuro, teremos o contexto da decisão."
+
+**O que NÃO fazer:**
+- ❌ Over-engineering (CQRS, Event Sourcing, microserviços sem justificativa de dados)
+- ❌ Stack que o time não domina sem plano de learning
+- ❌ Schema de banco incompleto (tabelas sem tipos ou sem índices)
+- ❌ Ignorar segurança no MVP — OWASP Top 5 é mínimo
+- ❌ NFRs vagos ("deve ser rápido")
+
+## Missão
+
+Gerar documento de Design Técnico consolidado em ~60 minutos cobrindo domínio, banco, arquitetura, segurança e NFRs. Este é o documento técnico mais importante — serve como referência para Frontend, Backend e Deploy.
+
+## Entregável
+
+`docs/04-technical-design/technical-design.md`
+
+## Coleta Conversacional
+
+Pergunte ao usuário ANTES de gerar:
+
+### Bloco 1 — Stack e Time (obrigatório)
+1. **Stack preferida?** Restrições ou tecnologias que o time domina?
+2. **Tamanho do time?** Quantos devs? Senioridade?
+3. **Monorepo ou repos separados?**
+
+### Bloco 2 — Infraestrutura (obrigatório)
+4. **Hospedagem:** Vercel, AWS, VPS, Docker, on-premise?
+5. **Banco de dados:** PostgreSQL, MySQL, MongoDB, SQLite?
+6. **Orçamento de infra:** Grátis, <$50/mês, <$200, ilimitado?
+
+### Bloco 3 — Segurança e Compliance (importante)
+7. **Autenticação:** Email/senha? OAuth social? SSO?
+8. **Dados sensíveis:** LGPD? PCI-DSS? Dados financeiros ou saúde?
+9. **Integrações externas:** Quais APIs? (pagamento, email, storage)
+
+### Bloco 4 — Escala (importante)
+10. **Usuários simultâneos** esperados? Picos?
+11. **Volume de dados:** MBs, GBs, TBs?
+12. **Tempo de resposta** aceitável?
+
+## Seções Obrigatórias do Entregável
+
+1. **Sumário Executivo** — Visão arquitetural em 1 parágrafo
+2. **Modelo de Domínio** — Entidades, atributos, relacionamentos, regras de negócio, linguagem ubíqua
+3. **Schema de Banco** — Tabelas com tipos reais, PKs/FKs, índices, estratégia de migrations
+4. **Stack Tecnológica** — Frontend, Backend, Banco, Infra — cada item justificado
+5. **Diagrama C4** — Nível 1 (Context) e Nível 2 (Container)
+6. **ADRs** — Mínimo 3 decisões (stack, banco, autenticação)
+7. **Segurança** — Autenticação, autorização, OWASP Top 10, dados sensíveis
+8. **NFRs** — Performance, disponibilidade, escalabilidade com números
+9. **Estratégia de Deploy** — Ambientes, CI/CD, migrations
+
+## Gate Checklist
+
+- [ ] Entidades do domínio com atributos e relacionamentos completos
+- [ ] Schema de banco com tipos reais, PKs/FKs e índices planejados
+- [ ] Stack tecnológica justificada com mínimo 3 ADRs
+- [ ] Diagrama C4 nível 1 e 2
+- [ ] Autenticação e autorização definidas
+- [ ] OWASP Top 5 mitigado
+- [ ] NFRs mensuráveis (tempo resposta, disponibilidade, escala)
+- [ ] Estratégia de deploy com ambientes
+
+## Recursos
+
+- `resources/templates/technical-design.md` — Template consolidado
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/examples/example-technical-design.md` — Exemplo preenchido
+- `resources/reference/guide.md` — Guia de Design Técnico
+
+## Skills Complementares
+
+- `@api-patterns` — Padrões REST/GraphQL, status codes, response format
+- `@database-design` — Schema design avançado, índices, normalização
+- `@architecture` — Padrões arquiteturais, C4, Clean Architecture
+- `@performance-profiling` — NFRs de performance e load testing
+
+## Próximo Especialista
+
+Após aprovação → **Especialista de Planejamento** (`specialist-planning`)

package/dist/content/skills/specialist-technical-design/resources/checklists/gate-checklist.md

@@ -0,0 +1,38 @@
+# Gate Checklist — Design Técnico
+
+> **Score mínimo para aprovação:** 70/100
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Modelo de domínio com entidades e relacionamentos** | 15 | Todas entidades com atributos, tipos e cardinalidade |
+| 2 | **Schema de banco com PKs/FKs e índices** | 15 | Tabelas com tipos reais, constraints, índices para queries frequentes |
+| 3 | **Stack justificada com mínimo 3 ADRs** | 15 | Cada ADR: contexto, decisão, alternativas rejeitadas, consequências |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 4 | **Diagrama C4 nível 1 e 2** | 10 | Context + Container diagrams presentes |
+| 5 | **Autenticação e autorização definidas** | 10 | Método, fluxo, roles/permissões documentados |
+| 6 | **NFRs mensuráveis** | 10 | Performance, disponibilidade, escala com números concretos |
+| 7 | **OWASP Top 5 mitigado** | 10 | Pelo menos 5 vulnerabilidades com mitigação |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 8 | **Estratégia de deploy com ambientes** | 5 | Dev/staging/prod, CI/CD descrito |
+| 9 | **Migrations e seeds planejados** | 5 | Ferramenta, rollback, dados de teste |
+| 10 | **Dados sensíveis mapeados (LGPD)** | 5 | Classificação por tipo + proteção |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Entidades incompletas | Listar TODAS as entidades do domínio com atributos e tipos reais |
+| Schema sem índices | Identificar queries mais frequentes → criar índices correspondentes |
+| ADRs genéricos | Formato: "Escolhi X porque Y. Rejeitei Z por W. Consequência: +A, -B" |
+| NFRs vagos | Substituir "rápido" por "p95 < 200ms", "disponível" por "99.5% uptime" |
+| Sem segurança | Mapear OWASP Top 5: Injection, Broken Auth, XSS, CSRF, SSRF |

package/dist/content/skills/specialist-technical-design/resources/reference/guide.md

@@ -0,0 +1,86 @@
+# Guia de Referência — Design Técnico
+
+## Documento Consolidado: 5 Seções
+
+O Design Técnico é um documento ÚNICO que cobre:
+
+1. **Modelo de Domínio** — Entidades, relacionamentos, regras de negócio
+2. **Schema de Banco** — Tabelas, tipos, PKs/FKs, índices, migrations
+3. **Arquitetura** — C4, stack justificada, ADRs
+4. **Segurança** — Autenticação, OWASP, dados sensíveis
+5. **NFRs** — Performance, disponibilidade, escalabilidade
+
+## Modelo de Domínio — Checklist Rápido
+
+- [ ] Todas as entidades do domínio listadas
+- [ ] Cada entidade com atributos e tipos
+- [ ] Relacionamentos com cardinalidade (1:1, 1:N, N:N)
+- [ ] Tabelas intermediárias para N:N
+- [ ] `id` (UUID), `created_at`, `updated_at` em todas
+- [ ] Regras de negócio vinculadas às entidades
+
+## Schema de Banco — Tipos Comuns
+
+| Conceito | PostgreSQL | MySQL |
+|----------|-----------|-------|
+| ID | UUID + gen_random_uuid() | CHAR(36) ou BINARY(16) |
+| String curta | VARCHAR(N) | VARCHAR(N) |
+| String longa | TEXT | TEXT |
+| Inteiro | INTEGER | INT |
+| Decimal | DECIMAL(10,2) | DECIMAL(10,2) |
+| Boolean | BOOLEAN | TINYINT(1) |
+| Data | DATE | DATE |
+| Timestamp | TIMESTAMP | DATETIME |
+| Enum | ENUM type ou VARCHAR | ENUM |
+| JSON | JSONB | JSON |
+
+## Índices — Quando Criar
+
+| Cenário | Tipo de Índice |
+|---------|---------------|
+| Login por email | UNIQUE em email |
+| FK mais consultada | INDEX simples |
+| Filtro combinado (projeto + status) | INDEX composto |
+| Busca textual | GIN (PostgreSQL) ou FULLTEXT |
+| Dados únicos (email, slug) | UNIQUE |
+
+## ADR — Template Mínimo
+
+```markdown
+### ADR-NNN: [Título]
+- **Status:** Aceito
+- **Contexto:** [Por que essa decisão é necessária?]
+- **Decisão:** [O que decidimos?]
+- **Alternativas:** [O que rejeitamos e por quê?]
+- **Consequências:** (+) benefícios (-) trade-offs
+```
+
+## Segurança — OWASP Top 5 Essencial
+
+| # | Vulnerabilidade | Mitigação Padrão |
+|---|----------------|-----------------|
+| 1 | **Injection** | ORM com queries parametrizadas |
+| 2 | **Broken Auth** | JWT + refresh rotation + bcrypt + rate limit |
+| 3 | **XSS** | React escapa por padrão + CSP headers |
+| 4 | **CSRF** | SameSite cookies + CSRF tokens |
+| 5 | **Broken Access** | RBAC middleware em cada rota |
+
+## NFRs — Referência de Valores Realistas
+
+| Métrica | MVP | Escala Média | Enterprise |
+|---------|-----|-------------|-----------|
+| API p95 | < 500ms | < 200ms | < 100ms |
+| Uptime | 99% | 99.5% | 99.9% |
+| Concurrent users | 100 | 1.000 | 10.000+ |
+| Deploy frequency | Semanal | Diário | Múltiplas/dia |
+| Recovery time | < 4h | < 1h | < 15min |
+
+## Anti-patterns
+
+| Anti-pattern | Correção |
+|-------------|----------|
+| Schema sem tipos reais | Definir tipo exato do banco (VARCHAR(255), não "string") |
+| ADR genérico "Escolhemos React" | Contexto + alternativas + consequências |
+| Microserviços para time de 2 | Monolito modular, extrair serviços quando dados justificarem |
+| NFRs aspiracionais (99.99%) | Números realistas para o MVP e orçamento |
+| Segurança "depois do launch" | OWASP Top 5 no mínimo desde o início |