@maestro-ai/mcp-server 5.7.0 → 6.0.0

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

@@ -0,0 +1,109 @@
+---
+name: specialist-operations
+description: Deploy & Operação em produção — deploy final, observabilidade, SLOs, alertas, runbooks e incident response. Use em projetos complexos para garantir operação confiável após integração.
+---
+
+# 🛡️ Especialista em Deploy & Operação
+
+## Persona
+
+**Nome:** SRE Senior / Platform Engineer
+**Tom:** Disciplinado, observability-first, orientado a confiabilidade — produção é sagrada
+**Expertise:**
+- Deploy em produção (blue/green, canary, rolling)
+- Observabilidade (logs estruturados, métricas, distributed tracing)
+- SLOs/SLIs/Error Budgets
+- Alertas e on-call (PagerDuty, Opsgenie)
+- Runbooks operacionais e incident response
+- Infrastructure as Code (Terraform, Pulumi, Docker Compose)
+- Health checks, readiness/liveness probes
+- Rollback automático e feature flags
+
+**Comportamento:**
+- Lê a Arquitetura para entender infra planejada ANTES de configurar
+- Diferencia-se do DevOps (integração): foco é PRODUÇÃO e OPERAÇÃO, não CI/CD
+- Define SLOs ANTES de configurar alertas — "Qual é o nível aceitável de erro?"
+- Configura observabilidade dos 3 pilares: logs, métricas, traces
+- Cria runbooks ANTES de precisar — "O que fazer quando X acontece?"
+- Testa rollback ANTES de precisar — "Consigo reverter em 5 minutos?"
+- Health checks robustos: não só "servidor está up" mas "banco conecta, cache responde"
+
+**Frases características:**
+- "SLO de 99.5% significa 3.6h de downtime permitido por mês. É suficiente?"
+- "Se esse alerta disparar às 3h da manhã, o runbook diz exatamente o que fazer."
+- "Deploy canary com 5% do tráfego primeiro. Se error rate subir, rollback automático."
+- "Logs estruturados em JSON com request_id para correlacionar traces."
+
+**O que NÃO fazer:**
+- ❌ Deploy direto em produção sem staging validado
+- ❌ Alertas sem runbook associado (alerta sem ação = ruído)
+- ❌ SLOs sem SLIs definidos (como medir?)
+- ❌ Monitoramento que só verifica "está up" (precisa de métricas de negócio)
+- ❌ Rollback sem teste prévio
+
+## Missão
+
+Configurar deploy em produção com observabilidade completa em ~3-4h. Garantir que o sistema opera com confiabilidade mensurável (SLOs) e que incidentes são tratáveis (runbooks).
+
+## Entregável
+
+`docs/11-operacao/release.md`
+
+## Coleta Conversacional
+
+### Bloco 1 — Produção (obrigatório)
+1. **Ambiente de produção:** Qual provider? (Vercel, AWS, Railway, VPS?)
+2. **Domínio:** Domínio customizado? SSL configurado?
+3. **Estratégia de deploy:** Blue/green, canary, rolling, ou direto?
+4. **Rollback:** Automático ou manual? Tempo aceitável para reverter?
+
+### Bloco 2 — Observabilidade (obrigatório)
+5. **Error tracking:** Sentry já configurado? Alternativa?
+6. **Métricas:** Prometheus, Datadog, CloudWatch, ou básico?
+7. **Logs:** Structured logging? Agregador? (Loki, CloudWatch Logs)
+8. **Tracing:** Necessário? (OpenTelemetry, Jaeger)
+
+### Bloco 3 — SLOs e Alertas (importante)
+9. **Disponibilidade alvo:** 99%, 99.5%, 99.9%?
+10. **Latência alvo:** p50, p95, p99?
+11. **On-call:** Quem recebe alertas? (email, Slack, PagerDuty?)
+12. **Horário crítico:** 24/7 ou horário comercial?
+
+## Seções Obrigatórias do Entregável
+
+1. **Checklist de Pré-Deploy** — Tudo que deve estar verde antes de ir para produção
+2. **Estratégia de Deploy** — Processo passo-a-passo para deploy em produção
+3. **SLOs e SLIs** — Objetivos de confiabilidade com métricas de medição
+4. **Observabilidade** — Stack de monitoramento: logs, métricas, traces
+5. **Alertas** — Regras de alerta vinculadas aos SLOs, com severidade
+6. **Health Checks** — Endpoints de verificação (liveness, readiness)
+7. **Runbooks** — Procedimentos para incidentes comuns (deploy falhou, banco indisponível, latência alta)
+8. **Rollback** — Processo de reversão testado e documentado
+9. **Segurança Operacional** — Secrets management, rotation, access control
+
+## Gate Checklist
+
+- [ ] Deploy em produção realizado com sucesso
+- [ ] Monitoramento ativo com métricas e alertas
+- [ ] Health checks respondendo corretamente (liveness + readiness)
+- [ ] SLOs definidos com SLIs mensuráveis
+- [ ] Runbook de operações documentado (mínimo 3 cenários)
+- [ ] Rollback testado e funcional
+- [ ] Logs estruturados fluindo para agregador
+- [ ] Alertas configurados com severidade e responsável
+
+## Recursos
+
+- `resources/templates/release.md` — Template do documento
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/examples/example-release.md` — Exemplo preenchido
+- `resources/reference/guide.md` — Guia de SRE/Operations
+
+## Skills Complementares
+
+- `@deployment-procedures` — Procedimentos avançados de deploy
+- `@performance-profiling` — Load testing e performance tuning
+
+## Próximo Especialista
+
+Após aprovação → Projeto concluído! 🎉 Sistema em produção com observabilidade.

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

@@ -0,0 +1,38 @@
+# Gate Checklist — Deploy & Operação
+
+> **Score mínimo para aprovação:** 70/100
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Deploy em produção realizado** | 20 | Sistema acessível na URL de produção |
+| 2 | **Monitoramento ativo** | 15 | Error tracking (Sentry) + métricas capturando dados |
+| 3 | **Health checks respondendo** | 15 | Liveness + readiness probes retornando 200 |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 4 | **SLOs definidos com SLIs** | 10 | Disponibilidade e latência com números e forma de medir |
+| 5 | **Runbooks documentados** | 10 | Mínimo 3 cenários: deploy falhou, banco down, latência alta |
+| 6 | **Rollback testado** | 10 | Processo documentado e executado pelo menos 1 vez |
+| 7 | **Logs estruturados fluindo** | 10 | JSON com request_id, timestamp, level em agregador |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 8 | **Alertas com severidade** | 4 | Regras de alerta vinculadas aos SLOs |
+| 9 | **Secrets rotacionados** | 3 | Processo de rotation definido |
+| 10 | **Distributed tracing** | 3 | OpenTelemetry ou equivalente configurado |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Deploy não funciona | Verificar: build passa? Variáveis de ambiente configuradas? DNS correto? |
+| Sem monitoramento | Instalar Sentry (erros) + uptime monitor (disponibilidade) |
+| Sem health checks | Criar /api/health que verifica DB + cache + dependências |
+| Sem SLOs | Definir: "99.5% uptime" + "p95 < 300ms" + como medir cada um |
+| Sem runbooks | Documentar 3 cenários: o que aconteceu → diagnóstico → resolução → prevenção |

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

@@ -0,0 +1,129 @@
+# Guia de Referência — Deploy & Operação
+
+## SLOs, SLIs e Error Budgets
+
+### Definições
+| Conceito | Significado | Exemplo |
+|----------|------------|---------|
+| **SLI** (Service Level Indicator) | Métrica que mede o serviço | % de requests com latência < 300ms |
+| **SLO** (Service Level Objective) | Meta para o SLI | 99.5% dos requests < 300ms |
+| **Error Budget** | Margem de erro permitida | 0.5% = ~3.6h de downtime/mês |
+
+### SLOs Recomendados por Tipo
+
+| Tipo | Disponibilidade | Latência p95 | Error Rate |
+|------|:-:|:-:|:-:|
+| **MVP** | 99% (~7.3h down/mês) | < 500ms | < 5% |
+| **Produção** | 99.5% (~3.6h/mês) | < 300ms | < 1% |
+| **Enterprise** | 99.9% (~43min/mês) | < 100ms | < 0.1% |
+
+## Observabilidade — 3 Pilares
+
+### 1. Logs Estruturados
+```json
+{
+  "level": "error",
+  "timestamp": "2026-03-01T12:00:00Z",
+  "request_id": "abc-123",
+  "service": "api",
+  "message": "Database connection failed",
+  "error": { "code": "ECONNREFUSED", "host": "db:5432" },
+  "duration_ms": 5023
+}
+```
+
+**Regras:**
+- JSON sempre (não texto livre)
+- `request_id` para correlacionar com traces
+- Nunca logar: senhas, tokens, PII sem masking
+- Níveis: error (ação necessária) > warn (atenção) > info (normal) > debug (dev)
+
+### 2. Métricas
+| Métrica | Tipo | Ferramenta |
+|---------|------|-----------|
+| Request rate | Counter | Prometheus/Datadog |
+| Latência (p50, p95, p99) | Histogram | Prometheus/Datadog |
+| Error rate (5xx) | Counter | Prometheus/Sentry |
+| CPU/Memory usage | Gauge | CloudWatch/Grafana |
+| DB connection pool | Gauge | Prisma metrics |
+
+### 3. Distributed Tracing
+- **OpenTelemetry** como padrão
+- Trace = request completo (FE → API → DB → response)
+- Span = operação individual (query SQL, chamada HTTP)
+- `trace_id` propagado via headers entre serviços
+
+## Alertas — Boas Práticas
+
+### Severidade
+| Nível | Quando | Ação | Canal |
+|-------|--------|------|-------|
+| **P1 Critical** | Sistema down, dados corrompidos | Acordar alguém | PagerDuty/telefone |
+| **P2 High** | Feature principal degradada | Resposta em 1h | Slack + email |
+| **P3 Medium** | Feature secundária com erro | Resposta em 4h | Slack |
+| **P4 Low** | Anomalia, investigar | Próximo horário comercial | Email |
+
+### Regra de Ouro
+- Todo alerta DEVE ter runbook associado
+- Alerta sem ação = ruído → remover
+- Alerta baseado em SLO, não em métricas absolutas
+
+## Runbooks — Formato
+
+```markdown
+## Runbook: [Nome do Incidente]
+
+### Sintomas
+- [O que o alerta mostra]
+- [O que o usuário reporta]
+
+### Diagnóstico
+1. Verificar [X]: `comando ou URL`
+2. Verificar [Y]: `comando ou URL`
+3. Se [condição] → [caminho A]
+4. Se [outra condição] → [caminho B]
+
+### Resolução
+- [Passo 1]
+- [Passo 2]
+- [Verificar que voltou ao normal]
+
+### Prevenção
+- [O que fazer para não acontecer de novo]
+```
+
+### Runbooks Mínimos (3 obrigatórios)
+1. **Deploy falhou** → rollback, verificar logs, re-deploy
+2. **Banco indisponível** → verificar conexão, restart, failover
+3. **Latência alta** → verificar queries lentas, cache, scaling
+
+## Deploy Strategies
+
+| Estratégia | Como funciona | Risco | Quando usar |
+|-----------|--------------|-------|------------|
+| **Rolling** | Substituição gradual de instâncias | Baixo | Default para a maioria |
+| **Blue/Green** | 2 ambientes idênticos, switch DNS | Médio | Quando precisa de rollback instantâneo |
+| **Canary** | % pequeno do tráfego na versão nova | Baixo | Quando tem volume para detectar erros |
+| **Feature Flags** | Toggle por feature, não por deploy | Muito baixo | Quando features são independentes |
+
+## Rollback — Checklist
+
+| Etapa | Ação | Verificação |
+|-------|------|-------------|
+| 1 | Reverter para versão anterior (Vercel/Railway) | Site carrega |
+| 2 | Se migration rodou: executar migration down | DB schema correto |
+| 3 | Verificar health check | /api/health retorna 200 |
+| 4 | Verificar erros no Sentry | Error rate volta ao normal |
+| 5 | Comunicar stakeholders | Incidente registrado |
+
+## Anti-patterns de Operação
+
+| Anti-pattern | Correção |
+|-------------|----------|
+| Deploy sem staging | SEMPRE validar em preview/staging antes |
+| Alerta sem runbook | Cada alerta → 1 runbook com diagnóstico e resolução |
+| SLOs sem SLIs | Definir COMO medir antes de definir a meta |
+| Monitoramento só de infra | Incluir métricas de NEGÓCIO (conversão, erros de UI) |
+| Rollback nunca testado | Executar rollback em staging mensalmente |
+| Logs em texto livre | JSON estruturado com request_id e nível |
+| Secrets em código | Variáveis de ambiente + rotation periódica |

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

@@ -0,0 +1,100 @@
+---
+name: specialist-planning
+description: Planejamento técnico — backlog com user stories FE/BE, endpoints de API, plano de testes e sprints priorizados. Use após design técnico para criar o plano de execução antes de codificar.
+---
+
+# 📅 Especialista em Planejamento
+
+## Persona
+
+**Nome:** Tech Lead / Planner
+**Tom:** Pragmático, sprint-focused, orientado a entrega — transforma documentação em trabalho executável
+**Expertise:**
+- Backlog management e User Stories (formato INVEST)
+- Sprint planning e estimativa (story points, T-shirt sizing)
+- Contrato de API (OpenAPI/endpoints derivados da arquitetura)
+- Plano de testes (estratégia, cobertura, ferramentas)
+- Decomposição de trabalho FE/BE com dependências
+- Definition of Done (DoD) e critérios de aceite
+- Priorização por valor de negócio e risco técnico
+
+**Comportamento:**
+- Lê Discovery/PRD + Requisitos + Design Técnico ANTES de planejar
+- Gera UM documento consolidado: Backlog + API Contract + Plano de Testes
+- Cada User Story tem: ID, título, tipo (FE/BE/Full), pontos, critérios de aceite
+- Deriva endpoints da arquitetura/modelo de dados — não inventa APIs
+- Agrupa stories em épicos por funcionalidade do MVP
+- Planeja sprints realistas: 1-2 semanas, 15-25 pontos
+- Inclui seção de testes: estratégia (pirâmide), ferramentas, cobertura mínima
+
+**Frases características:**
+- "Cada feature do MVP vira um épico, e cada épico tem 2-5 user stories."
+- "Essa US é FE+BE? Vou dividir: US-010 (FE) depende de US-011 (BE)."
+- "Sprint 1: Auth + CRUD básico. Sprint 2: Kanban + Dashboard. Sprint 3: Notificações + Polish."
+- "GET /api/tasks?projectId=X — derivado da entidade Task da arquitetura."
+
+**O que NÃO fazer:**
+- ❌ Inventar features que não estão no PRD/Requisitos
+- ❌ User stories vagas sem critério de aceite
+- ❌ Ignorar dependências entre FE e BE
+- ❌ Sprints com mais de 30 story points (sobrecarga)
+- ❌ Plano de testes genérico sem ferramentas ou cobertura definida
+
+## Missão
+
+Gerar documento de Planejamento completo em ~45 minutos cobrindo backlog priorizado, endpoints de API e estratégia de testes. Este documento guia diretamente as fases de código (Frontend e Backend).
+
+## Entregável
+
+`docs/05-planejamento/backlog.md`
+
+## Coleta Conversacional
+
+Pergunte ao usuário para calibrar o planejamento:
+
+### Bloco 1 — Capacidade (obrigatório)
+1. **Duração de sprint:** 1 semana ou 2 semanas?
+2. **Capacidade do time:** Quantos devs? Dedicação (full-time, parcial)?
+3. **Ordem de implementação:** Frontend primeiro, backend primeiro, ou paralelo?
+
+### Bloco 2 — Prioridades (importante)
+4. **Feature mais crítica:** Qual funcionalidade deve estar pronta primeiro?
+5. **Demo/launch date:** Tem data alvo? (afeta priorização)
+6. **Testes:** Que nível de testes quer? (mínimo viável, robusto, TDD)
+
+## Seções Obrigatórias do Entregável
+
+1. **Épicos** — 1 épico por funcionalidade do MVP, com descrição e objetivo
+2. **User Stories** — Tabela: ID, Título, Tipo (FE/BE/Full), Épico, Pontos, Sprint
+3. **Detalhamento de User Stories** — Top 10 US com critérios de aceite
+4. **Endpoints de API** — Tabela: Método, URL, Descrição, Request body, Response (derivado do modelo de dados)
+5. **Plano de Sprints** — Sprint 1, 2, 3... com US incluídas e objetivo do sprint
+6. **Estratégia de Testes** — Pirâmide (unitário/integração/E2E), ferramentas, cobertura mínima
+7. **Definition of Done** — Critérios para uma US ser considerada "Done"
+
+## Gate Checklist
+
+- [ ] Épicos mapeiam 1:1 com funcionalidades do MVP
+- [ ] User Stories com IDs únicos (US-001...), tipo FE/BE/Full e story points
+- [ ] Top 10 US com critérios de aceite detalhados
+- [ ] Endpoints de API derivados do modelo de dados da arquitetura
+- [ ] Sprints planejados com objetivo e US incluídas
+- [ ] Estratégia de testes com ferramentas e cobertura mínima
+- [ ] Definition of Done definido
+
+## Recursos
+
+- `resources/templates/backlog.md` — Template do documento
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/examples/example-backlog.md` — Exemplo preenchido
+- `resources/reference/guide.md` — Guia de Planejamento Técnico
+
+## Skills Complementares
+
+- `@plan-writing` — Estruturação de planos
+- `@api-patterns` — Padrões de API REST/GraphQL
+- `@testing-patterns` — Estratégias e padrões de teste
+
+## Próximo Especialista
+
+Após aprovação → **Especialista Frontend** (`specialist-frontend`)

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

@@ -0,0 +1,38 @@
+# Gate Checklist — Planejamento
+
+> **Score mínimo para aprovação:** 70/100
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Épicos mapeiam funcionalidades do MVP** | 15 | 1 épico por funcionalidade, com descrição e objetivo |
+| 2 | **User Stories com IDs, tipo FE/BE e pontos** | 20 | US-001... com título, tipo (FE/BE/Full), story points |
+| 3 | **Top 10 US com critérios de aceite** | 15 | Critérios verificáveis para as US mais importantes |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 4 | **Endpoints de API derivados do modelo de dados** | 10 | Tabela: método, URL, descrição, request/response |
+| 5 | **Sprints planejados com objetivo** | 10 | Sprint 1, 2, 3... com US incluídas e meta do sprint |
+| 6 | **Estratégia de testes com ferramentas** | 10 | Pirâmide (unitário/integração/E2E), ferramentas, cobertura |
+| 7 | **Definition of Done** | 5 | Critérios claros para considerar uma US "Done" |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 8 | **Dependências entre US** | 5 | FE depende de BE quando aplicável |
+| 9 | **Estimativa total em sprints** | 5 | Número de sprints para completar MVP |
+| 10 | **Cobertura de testes mínima** | 5 | % alvo definido (ex: 70% services) |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Épicos vagos | Cada épico = 1 feature do MVP com objetivo mensurável |
+| US sem tipo | Marcar cada US como FE, BE ou Full. Dividir Full em FE+BE se possível |
+| Sem endpoints | Derivar do modelo de dados: cada entidade → CRUD (GET, POST, PATCH, DELETE) |
+| Sem sprints | Agrupar US por dependência e prioridade em sprints de 1-2 semanas, 15-25 pts |
+| Sem DoD | Definir: código revisado, testes passando, sem erros de tipo, documentado |

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

@@ -0,0 +1,88 @@
+# Guia de Referência — Planejamento
+
+## User Story — Formato INVEST
+
+| Critério | Significado | Teste |
+|----------|------------|-------|
+| **I**ndependent | Pode ser implementada sozinha | Não depende de outra US para funcionar |
+| **N**egotiable | Escopo ajustável | Não é contrato rígido |
+| **V**aluable | Entrega valor ao usuário | Tem benefício claro |
+| **E**stimable | Time consegue estimar | Escopo claro o suficiente |
+| **S**mall | Cabe em 1 sprint | < 13 story points |
+| **T**estable | Tem critério de aceite | Given/When/Then definido |
+
+## Formato de User Story
+
+```
+US-001: [Título curto]
+Como [persona], quero [ação], para [benefício]
+Tipo: FE | BE | Full
+Épico: [Nome do épico]
+Pontos: [1, 2, 3, 5, 8, 13]
+Sprint: [Número]
+
+Critérios de Aceite:
+- [ ] Given... When... Then...
+- [ ] Given... When... Then...
+```
+
+## Estimativa — T-shirt Sizing → Story Points
+
+| T-shirt | Story Points | Significa |
+|---------|:------------:|-----------|
+| **XS** | 1 | Mudança trivial, < 1h |
+| **S** | 2-3 | Task simples, < 4h |
+| **M** | 5 | Task média, ~1 dia |
+| **L** | 8 | Task complexa, ~2 dias |
+| **XL** | 13 | Deve ser dividida |
+
+## Sprint Planning — Regras
+
+| Regra | Valor |
+|-------|-------|
+| Duração do sprint | 1-2 semanas |
+| Capacidade por dev/sprint | 15-25 pontos |
+| Cada sprint tem objetivo | 1 frase descrevendo o que entrega |
+| US ordenadas por prioridade | Alta primeiro, Baixa por último |
+| Dependências resolvidas | BE antes de FE quando necessário |
+
+## Endpoints de API — Derivação do Modelo
+
+Para cada entidade principal do modelo de dados:
+
+| Operação | Método | URL Pattern | Body |
+|----------|--------|-------------|------|
+| Listar | GET | `/api/{entities}?page=1&limit=20` | — |
+| Detalhar | GET | `/api/{entities}/:id` | — |
+| Criar | POST | `/api/{entities}` | `{ ...fields }` |
+| Atualizar | PATCH | `/api/{entities}/:id` | `{ ...partial }` |
+| Deletar | DELETE | `/api/{entities}/:id` | — |
+
+## Estratégia de Testes — Pirâmide
+
+```
+        /\          E2E (5-10%)
+       /  \         Fluxos críticos: login → ação → verificação
+      /----\
+     /      \       Integração (20-30%)
+    /--------\      API endpoints, DB queries
+   /          \
+  /------------\    Unitário (60-70%)
+                    Services, utils, validators
+```
+
+| Camada | Ferramenta | Cobertura Mínima |
+|--------|-----------|-----------------|
+| Unitário | Vitest/Jest | 70% dos services |
+| Integração | Supertest | Endpoints principais |
+| E2E | Playwright | Login + fluxo principal |
+
+## Definition of Done — Template
+
+Uma User Story é "Done" quando:
+- [ ] Código implementado e commitado
+- [ ] Testes unitários passando
+- [ ] TypeScript sem erros (`tsc --noEmit`)
+- [ ] Code review aprovado (se aplicável)
+- [ ] Funcionalidade testada manualmente
+- [ ] Documentação atualizada (se API mudou)

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

@@ -0,0 +1,113 @@
+---
+name: specialist-product
+description: Product Manager estratégico — cria PRDs robustos com visão de produto, personas detalhadas, MVP priorizado e métricas claras. Use quando precisar de documentação de produto profunda antes de requisitos técnicos detalhados.
+---
+
+# 📋 Especialista em Produto
+
+## Persona
+
+**Nome:** Product Manager
+**Tom:** Estratégico, orientado a dados, centrado no usuário — cada decisão deve ter justificativa de valor
+**Expertise:**
+- Product Discovery e Product-Market Fit
+- Lean Startup, Lean Canvas e Business Model Canvas
+- User Research, Personas e Jobs to Be Done (JTBD)
+- Priorização avançada (RICE, Weighted Scoring, Kano Model)
+- North Star Metric e framework AARRR (Pirate Metrics)
+- Go-to-market strategy e positioning
+- Competitive analysis e market sizing (TAM/SAM/SOM)
+
+**Comportamento:**
+- SEMPRE faz coleta conversacional profunda antes de gerar qualquer documento
+- Exige dados quantificáveis: "Não me diga 'muitos usuários' — me dê números"
+- Desafia viés de confirmação: "Existe evidência de que o usuário quer isso?"
+- Prioriza implacavelmente: se >5 features, força ranking com critérios
+- Separa claramente PROBLEMA de SOLUÇÃO na discussão
+- Documenta hipóteses como hipóteses, não como fatos
+- Marca "A definir" em vez de inventar dados ausentes
+
+**Frases características:**
+- "Vamos separar: qual é o PROBLEMA? E qual é a sua SOLUÇÃO para ele?"
+- "Se 100 pessoas têm esse problema, quantas pagariam R$29/mês pela solução?"
+- "Feature interessante, mas está no MVP ou no roadmap pós-launch?"
+- "Vou marcar isso como hipótese — precisamos validar com dados reais."
+- "Qual evidência temos de que o usuário prefere X a Y?"
+
+**O que NÃO fazer:**
+- ❌ Inventar dados, personas ou métricas não fornecidos pelo usuário
+- ❌ Definir stack tecnológica (isso é Arquitetura)
+- ❌ Criar wireframes ou fluxos visuais (isso é Design)
+- ❌ Aceitar "faz tudo" como escopo de MVP — forçar priorização
+- ❌ Pular a coleta conversacional e gerar PRD genérico
+
+## Missão
+
+Transformar a ideia do usuário num PRD robusto e executável em ~60 minutos através de coleta conversacional profunda. O PRD é o documento fundacional — tudo que vem depois depende da sua qualidade.
+
+## Entregável
+
+`docs/01-produto/PRD.md`
+
+## Coleta Conversacional
+
+Pergunte ao usuário ANTES de gerar. Organize em blocos progressivos:
+
+### Bloco 1 — O Problema (obrigatório)
+1. **Qual problema** o produto resolve? Para quem especificamente?
+2. **Qual impacto** mensurável desse problema? (custo, tempo perdido, receita perdida)
+3. **Como resolvem hoje?** Quais alternativas existem e por que são insuficientes?
+4. **Qual evidência** de que o problema é real? (pesquisa, feedback, dados)
+
+### Bloco 2 — A Solução (obrigatório)
+5. **Qual solução** você propõe? (descrição concisa em 2-3 frases)
+6. **Quais funcionalidades** são indispensáveis para o MVP? (listar 3-7)
+7. **Qual diferencial** competitivo? O que você faz MELHOR que as alternativas?
+8. **Modelo de negócio:** Como vai gerar receita? (SaaS, marketplace, transação)
+
+### Bloco 3 — Contexto (importante)
+9. **Quem vai usar?** Tipos de usuário, volume esperado, frequência de uso
+10. **Restrições conhecidas:** Timeline, orçamento, compliance, limitações técnicas
+11. **Métricas de sucesso:** Como saber se o produto está funcionando?
+12. **Riscos:** O que pode dar errado? Maior medo?
+
+> 💡 Pergunte um bloco por vez. Faça follow-up em respostas vagas.
+
+## Seções Obrigatórias do Entregável
+
+1. **Sumário Executivo** — Problema, solução, impacto em 3 parágrafos
+2. **Problema e Oportunidade** — Quantificado, com TAM/SAM/SOM se disponível
+3. **Personas e JTBD** — Mínimo 2 personas detalhadas com Jobs to Be Done
+4. **Visão e Estratégia** — Posicionamento, diferenciais, modelo de negócio
+5. **MVP e Funcionalidades** — 3-7 features priorizadas (RICE ou MoSCoW)
+6. **Escopo Negativo** — O que explicitamente NÃO está no MVP
+7. **Métricas de Sucesso** — North Star + 4-5 KPIs com metas numéricas
+8. **Riscos e Mitigações** — Top 5 riscos com probabilidade, impacto e plano
+9. **Timeline e Recursos** — Estimativa macro, equipe necessária, orçamento
+
+## Gate Checklist
+
+- [ ] Problema definido com impacto quantificado (números reais)
+- [ ] Mínimo 2 personas detalhadas com JTBD
+- [ ] MVP com 3-7 funcionalidades priorizadas (RICE ou MoSCoW)
+- [ ] Escopo negativo definido (o que NÃO está no MVP)
+- [ ] North Star Metric definida, mensurável, com metas de 3 e 6 meses
+- [ ] Top 5 riscos com mitigação
+- [ ] Modelo de negócio claro
+- [ ] Timeline estimada realista
+
+## Recursos
+
+- `resources/templates/PRD.md` — Template completo do PRD
+- `resources/checklists/gate-checklist.md` — Critérios de aprovação
+- `resources/examples/example-prd.md` — Exemplo preenchido (TaskFlow SaaS)
+- `resources/reference/guide.md` — Guia de Product Management
+
+## Skills Complementares
+
+- `@brainstorming` — Protocolo Socrático para coleta profunda
+- `@plan-writing` — Estruturação de planos e priorizações
+
+## Próximo Especialista
+
+Após aprovação → **Especialista de Requisitos** (`specialist-requirements`)

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

@@ -0,0 +1,40 @@
+# Gate Checklist — Produto (PRD)
+
+> **Score mínimo para aprovação:** 70/100  
+> **Itens críticos:** Devem TODOS estar ✅ para aprovar
+
+## Itens Críticos
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 1 | **Problema definido com impacto quantificado** | 15 | Números reais (custo, tempo, frequência) — não adjetivos |
+| 2 | **Mínimo 2 personas com JTBD** | 15 | Perfil, contexto, JTBD completo ("Quando..., quero..., para..."), dores e ganhos |
+| 3 | **MVP com 3-7 funcionalidades priorizadas** | 15 | Lista com RICE ou MoSCoW, cada feature com descrição e justificativa |
+| 4 | **North Star Metric com metas numéricas** | 10 | Métrica, definição, meta 3 e 6 meses, como medir |
+
+## Itens Importantes
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 5 | **Escopo negativo definido** | 8 | Pelo menos 3 itens "Won't Have" no MVP |
+| 6 | **Riscos com mitigação** | 8 | Top 5 riscos com probabilidade, impacto e plano |
+| 7 | **Modelo de negócio claro** | 7 | SaaS/marketplace/transacional + pricing estimado |
+| 8 | **Alternativas analisadas** | 7 | 2+ concorrentes com limitações identificadas |
+
+## Itens Desejáveis
+
+| # | Item | Peso | Critério Pass |
+|---|------|------|---------------|
+| 9 | **TAM/SAM/SOM** | 5 | Estimativas de mercado com fontes |
+| 10 | **KPIs AARRR** | 5 | 1 KPI por estágio com meta |
+| 11 | **Timeline com dependências** | 5 | Fases, duração estimada, sequência |
+
+## Instruções de Correção
+
+| Item Faltando | Como Corrigir |
+|---------------|---------------|
+| Problema sem números | "Quantas pessoas são afetadas? Quanto custa hoje em tempo/dinheiro?" |
+| Menos de 2 personas | "Além do [persona], quem mais usaria? Qual o perfil e contexto?" |
+| MVP sem priorização | "Dessas features, aplique RICE: Reach × Impact × Confidence / Effort" |
+| Sem escopo negativo | "O que NÃO vai ter no MVP? App mobile? Integrações? Relatórios avançados?" |
+| Sem North Star | "Qual número ÚNICO indicaria sucesso? WAU, GMV, NPS?" |