@maestro-ai/cli 1.0.0

package/content/prompts/observabilidade/slos.md

@@ -0,0 +1,215 @@
+# Prompt: Definição de SLOs e SLIs
+
+> **Prioridade**: 🔴 CRÍTICA  
+> **Aplicável a**: Projetos Nível 2 (Médio) e Nível 3 (Complexo)
+
+---
+
+## Contexto
+
+SLOs (Service Level Objectives) são metas internas de confiabilidade que guiam decisões de engenharia. Sem SLOs definidos:
+- Não há critério objetivo para "bom o suficiente"
+- Não há base para priorizar estabilidade vs features
+- Não há como medir degradação gradual
+
+---
+
+## Prompt Base: Derivar SLOs de Requisitos
+
+```text
+Atue como engenheiro de confiabilidade (SRE).
+
+Aqui estão os requisitos não-funcionais do sistema:
+[COLE OS RNFs]
+
+Contexto:
+- Tipo de sistema: [ex: e-commerce, fintech, SaaS B2B]
+- Usuários esperados: [ex: 10k DAU, 100 req/s pico]
+- Criticidade: [baixa/média/alta/crítica]
+- SLA contratual (se houver): [ex: 99.9% uptime]
+
+Derive SLOs práticos incluindo:
+
+1. **SLO de Disponibilidade**
+   - SLI (métrica exata a medir)
+   - Target (ex: 99.9%)
+   - Error Budget resultante
+   - Exclusões (manutenções, dependências)
+
+2. **SLO de Latência**
+   - SLIs para p50, p95, p99
+   - Targets por endpoint crítico
+   - Janela de medição
+
+3. **SLO de Taxa de Erros**
+   - SLI (como calcular)
+   - Target máximo aceitável
+   - O que conta como erro
+
+4. **Alertas Recomendados**
+   - Condições de disparo
+   - Severidadades (warning/critical)
+   - Janelas de avaliação
+
+5. **Dashboard Essencial**
+   - Métricas a exibir
+   - Queries de exemplo (PromQL/Datadog)
+
+Use o template em `06-templates/slo-sli.md` como base.
+```
+
+---
+
+## Prompt: SLOs para Sistema Existente
+
+```text
+Tenho um sistema em produção com as seguintes características:
+- Stack: [DESCREVA]
+- Métricas disponíveis: [ex: Prometheus, Datadog, CloudWatch]
+- Dados históricos: [ex: 6 meses de logs]
+- Incidentes recentes: [LISTE SE HOUVER]
+
+Analise os dados históricos e sugira:
+1. SLOs realistas baseados no comportamento atual
+2. Gaps entre performance atual e SLOs ideais
+3. Priorização de melhorias para atingir SLOs target
+4. Error budget atual (quanto já estamos consumindo)
+```
+
+---
+
+## Prompt: Definir Error Budget Policy
+
+```text
+Temos os seguintes SLOs definidos:
+[COLE SEUS SLOs]
+
+Crie uma Error Budget Policy que defina:
+
+1. **Ações por nível de consumo**
+   - 0-50%: operação normal
+   - 50-75%: ações preventivas
+   - 75-90%: ações corretivas
+   - >90%: emergência
+
+2. **Regras para deploys**
+   - Quando pausar deploys
+   - Critérios para liberar novamente
+   - Exceções (hotfixes críticos)
+
+3. **Responsabilidades**
+   - Quem monitora
+   - Quem decide pausar
+   - Quem aprova exceções
+
+4. **Post-mortem obrigatório**
+   - Gatilhos para post-mortem
+   - Template de análise
+   - Prazo para completar
+```
+
+---
+
+## Prompt: Revisar SLOs Existentes
+
+```text
+Aqui estão os SLOs atuais do sistema:
+[COLE SEUS SLOs]
+
+Dados dos últimos 3 meses:
+- Disponibilidade real: [ex: 99.85%]
+- Latência p95 real: [ex: 450ms]
+- Taxa de erros média: [ex: 0.15%]
+- Incidentes: [LISTE]
+
+Avalie:
+1. Os SLOs estão calibrados corretamente?
+   - Muito fáceis (gastamos pouco error budget)?
+   - Muito difíceis (violamos frequentemente)?
+2. Há SLOs faltando?
+3. Os SLIs estão medindo a coisa certa?
+4. Sugira ajustes com justificativa.
+```
+
+---
+
+## Prompt: SLOs para Microserviços
+
+```text
+Tenho uma arquitetura de microserviços com:
+- API Gateway
+- Serviços: [auth, orders, payments, notifications]
+- Dependências externas: [Stripe, SendGrid, etc]
+
+Defina:
+1. SLOs por serviço individual
+2. SLO composto para a jornada do usuário
+3. Como calcular SLO quando há dependências em cadeia
+4. Como tratar dependências externas no error budget
+5. Estratégia de alertas em cascata
+```
+
+---
+
+## Exemplos de SLIs por Tipo de Sistema
+
+### API REST
+
+```promql
+# Disponibilidade
+sum(rate(http_requests_total{status!~"5.."}[30d])) 
+/ sum(rate(http_requests_total[30d])) * 100
+
+# Latência p99
+histogram_quantile(0.99, 
+  sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
+
+# Taxa de erros
+sum(rate(http_requests_total{status=~"5.."}[5m])) 
+/ sum(rate(http_requests_total[5m])) * 100
+```
+
+### Aplicação Web (Core Web Vitals)
+
+| Métrica | SLI | SLO Target |
+|---------|-----|------------|
+| LCP | Largest Contentful Paint | p75 < 2.5s |
+| FID | First Input Delay | p75 < 100ms |
+| CLS | Cumulative Layout Shift | p75 < 0.1 |
+
+### Mensageria/Filas
+
+| Métrica | SLI | SLO Target |
+|---------|-----|------------|
+| Throughput | Mensagens processadas/s | > 1000/s |
+| Latência | Tempo do envio ao processamento | p99 < 5s |
+| Delivery Rate | Mensagens entregues/enviadas | > 99.99% |
+
+### Banco de Dados
+
+| Métrica | SLI | SLO Target |
+|---------|-----|------------|
+| Query Latency | Tempo de resposta de queries | p99 < 100ms |
+| Connection Success | Conexões bem-sucedidas | > 99.9% |
+| Replication Lag | Atraso de réplica | < 1s |
+
+---
+
+## Checklist de Implementação
+
+- [ ] SLOs definidos para disponibilidade, latência, erros
+- [ ] SLIs com definição precisa de cálculo
+- [ ] Error budgets calculados
+- [ ] Alertas configurados por nível de severidade
+- [ ] Dashboard com SLIs em tempo real
+- [ ] Error Budget Policy documentada
+- [ ] Processo de revisão periódica agendado
+- [ ] Post-mortem template preparado
+
+---
+
+## Referências
+
+- [Google SRE Book - SLOs](https://sre.google/sre-book/service-level-objectives/)
+- [The Art of SLOs (Google)](https://sre.google/workbook/implementing-slos/)
+- [Practical Guide to SLOs](https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli)

package/content/prompts/produto/discovery-inicial.md

@@ -0,0 +1,203 @@
+# Prompt: Discovery Inicial de Produto
+
+> **Quando usar**: Início de projeto, quando há apenas uma ideia ou anotações soltas
+> **Especialista**: [Gestão de Produto](../../02-especialistas/Especialista%20em%20Gestão%20de%20Produto%20.md)
+> **Nível**: Simples
+
+---
+
+## Fluxo de Contexto
+
+Este é geralmente o **primeiro prompt** de um novo projeto.
+
+Após gerar, salve o resultado em:
+- `docs/CONTEXTO.md` - Como base inicial
+- `docs/01-produto/PRD.md` - Documento de produto
+
+---
+
+## Prompt Completo
+
+```text
+Atue como gerente de produto sênior especializado em discovery.
+
+## Input
+
+Vou colar abaixo anotações soltas sobre uma ideia de produto:
+
+---
+
+[COLE SUAS ANOTAÇÕES, IDEIAS, TRANSCRIÇÕES DE REUNIÕES]
+
+---
+
+## Sua Missão
+
+Organize as informações em um Discovery estruturado:
+
+### 1. Problema Central
+- Qual dor estamos resolvendo?
+- Por que é um problema hoje?
+- Qual o custo de não resolver?
+
+### 2. Proposta de Solução
+- Como pretendemos resolver?
+- Qual o diferencial da nossa abordagem?
+- O que NÃO vamos fazer (escopo negativo)?
+
+### 3. Público-Alvo
+
+#### Segmentação
+- Quem são os usuários principais?
+- Qual o tamanho do mercado aproximado?
+
+#### Personas (2-3)
+Para cada persona:
+- Nome fictício e contexto
+- Dores específicas
+- Objetivos
+- Comportamento atual (como resolve hoje)
+
+### 4. Jobs-to-be-Done (JTBD)
+
+Para cada job principal:
+- "Quando [situação], eu quero [motivação], para que [resultado esperado]."
+
+### 5. Análise de Concorrentes
+
+| Concorrente | Tipo | Pontos Fortes | Pontos Fracos | Diferencial |
+|-------------|------|---------------|---------------|-------------|
+| [Nome] | Direto | ... | ... | ... |
+| [Nome] | Indireto | ... | ... | ... |
+
+### 6. Hipóteses e Riscos
+
+#### Hipóteses a Validar
+- [Hipótese 1] - Como validar
+- [Hipótese 2] - Como validar
+
+#### Riscos Identificados
+| Risco | Probabilidade | Impacto | Mitigação |
+|-------|---------------|---------|-----------|
+| [Risco 1] | Alta/Média/Baixa | Alto/Médio/Baixo | [Ação] |
+
+### 7. Métricas de Sucesso (North Star)
+
+- Métrica principal que indica sucesso
+- KPIs secundários
+- Como medir cada um
+
+### 8. MVP Sugerido
+
+- Funcionalidades essenciais (máximo 5)
+- O que fica para depois
+- Critério de sucesso do MVP
+
+### 9. Próximos Passos
+
+- [ ] Ação 1 - Responsável - Prazo
+- [ ] Ação 2 - Responsável - Prazo
+- [ ] Ação 3 - Responsável - Prazo
+```
+
+---
+
+## Exemplo de Uso
+
+```text
+Atue como gerente de produto sênior especializado em discovery.
+
+## Input
+
+Vou colar abaixo anotações soltas sobre uma ideia de produto:
+
+---
+
+Conversa com dona de salão:
+- Perde muito tempo atendendo WhatsApp pra agendar
+- Às vezes esquece de confirmar com cliente
+- Cliente reclama que não consegue ver horários disponíveis
+- Concorrente dela tem um sistema mas é muito caro (R$200/mês)
+- Ela queria algo simples, só agendamento mesmo
+- Importante: integrar com WhatsApp de alguma forma
+- Tem 3 funcionárias, cada uma faz serviços diferentes
+- Horário: seg-sab 9h-19h
+- Acha que uns 50-100 clientes por mês
+
+Ideias iniciais:
+- App web responsivo (sem app nativo por enquanto)
+- Integrar com API do WhatsApp Business
+- Cliente escolhe profissional, serviço e horário
+- Enviar lembrete automático
+- Relatório simples de agendamentos
+
+---
+
+[CONTINUA COM O PROMPT COMPLETO]
+```
+
+---
+
+## Resposta Esperada
+
+### 1. Problema Central
+
+**Dor**: Pequenos negócios de serviços (salões, clínicas) gastam tempo excessivo gerenciando agendamentos manualmente via WhatsApp.
+
+**Por que é problema**: 
+- Interrompe trabalho principal para atender mensagens
+- Erros de marcação (sobreposição de horários)
+- Cliente insatisfeito com demora na resposta
+
+**Custo**: ~2h/dia em atendimento de agendamentos = 40h/mês
+
+### 2. Proposta de Solução
+
+**Como resolver**: Plataforma self-service onde cliente agenda sozinho, 24h.
+
+**Diferencial**: Integração nativa com WhatsApp (onde o cliente já está).
+
+**Escopo negativo**: 
+- Não vamos fazer controle financeiro
+- Não vamos fazer estoque de produtos
+
+### 3. Personas
+
+**1. Maria, Dona de Salão**
+- 38 anos, 3 funcionárias
+- Dor: Perde clientes por não responder rápido
+- Objetivo: Mais tempo para atender, menos no celular
+- Hoje: WhatsApp manual + agenda de papel
+
+**2. Carla, Cliente Frequente**
+- 28 anos, profissional
+- Dor: Só consegue ligar em horário comercial
+- Objetivo: Agendar quando quiser, sem esperar
+- Hoje: Manda WhatsApp e espera resposta
+
+### 4. JTBD
+
+- "Quando quero marcar um horário, quero ver a disponibilidade em tempo real, para não precisar esperar resposta."
+- "Quando está chegando meu horário, quero receber lembrete, para não esquecer."
+
+### 5. MVP Sugerido
+
+1. Cadastro de serviços e profissionais
+2. Agenda online com horários disponíveis
+3. Cliente agenda sem login (só telefone)
+4. Confirmação automática via WhatsApp
+5. Painel simples para o salão
+
+---
+
+## Checklist Pós-Geração
+
+- [ ] Problema central está claro e validável
+- [ ] 2-3 personas com dores específicas
+- [ ] JTBDs escritos no formato correto
+- [ ] Concorrentes mapeados (diretos e indiretos)
+- [ ] Hipóteses listadas com forma de validar
+- [ ] MVP com máximo 5 features
+- [ ] Métricas de sucesso definidas
+- [ ] Próximos passos com responsáveis
+- [ ] Salvar em `docs/CONTEXTO.md` e `docs/01-produto/PRD.md`

package/content/prompts/produto/discovery-inicial.txt

@@ -0,0 +1,33 @@
+Atue como gerente de produto sênior.
+
+Vou colar anotações soltas sobre uma ideia de produto:
+[COLE TEXTO]
+
+Organize em:
+- problema principal que resolve
+- proposta de solução
+- público-alvo e 2-3 personas
+- principais jobs-to-be-done
+- concorrentes diretos/indiretos
+- riscos e hipóteses que precisam ser validadas
+
+---
+
+## Resposta Esperada (Exemplo)
+
+**Problema**: Pequenas empresas gastam muito tempo gerenciando agendamentos manualmente.
+
+**Solução**: Sistema de agendamento online self-service integrado ao WhatsApp.
+
+**Público-alvo**: Salões de beleza, clínicas, consultórios.
+
+**Personas**:
+1. Maria, dona de salão, 35 anos - quer reduzir ligações
+2. João, cliente - quer agendar fora do horário comercial
+
+**JTBD**:
+- "Quando quero marcar um horário, quero fazer pelo celular para não precisar ligar"
+
+**Concorrentes**: Calendly, Appointy, sistemas específicos do setor
+
+**Riscos**: Adoção por clientes mais velhos, integração com WhatsApp Business

package/content/prompts/requisitos/refinar-requisitos.md

@@ -0,0 +1,232 @@
+# Prompt: Refinar Requisitos
+
+> **Quando usar**: Após discovery inicial, para estruturar requisitos formais
+> **Especialista**: [Engenharia de Requisitos](../../02-especialistas/Especialista%20em%20Engenharia%20de%20Requisitos%20com%20IA.md)
+> **Nível**: Simples a Médio
+
+---
+
+## Fluxo de Contexto
+
+Antes de usar este prompt, tenha em mãos:
+- `docs/CONTEXTO.md` - Entendimento do projeto
+- Notas de reuniões ou transcrições
+
+Após gerar, salve o resultado em:
+- `docs/02-requisitos/requisitos.md`
+
+---
+
+## Prompt Completo
+
+```text
+Atue como analista de requisitos sênior.
+
+## Contexto do Projeto
+
+[COLE O CONTEÚDO DE docs/CONTEXTO.md]
+
+## Notas Brutas
+
+Vou colar abaixo anotações soltas de reuniões com o cliente:
+
+---
+
+[COLE TEXTO - Anotações, transcrições, emails, etc]
+
+---
+
+## Sua Missão
+
+Organize as informações em requisitos formais:
+
+### 1. Visão Geral
+Resumo do sistema em 2-3 parágrafos.
+
+### 2. Requisitos Funcionais
+
+Para cada requisito funcional:
+- **ID**: RF-XXX
+- **Título**: [Nome curto]
+- **Descrição**: O sistema deve [ação] para que [benefício]
+- **Prioridade**: Must/Should/Could/Won't (MoSCoW)
+- **Critérios de Aceitação**: Lista de condições verificáveis
+- **Dependências**: Outros RFs que precisam existir
+
+Agrupe os requisitos por módulo/feature.
+
+### 3. Requisitos Não-Funcionais
+
+Para cada requisito não-funcional:
+- **ID**: RNF-XXX
+- **Categoria**: Performance/Segurança/Usabilidade/Confiabilidade/Compatibilidade
+- **Descrição**: [Descrição mensurável]
+- **Métrica**: [Como medir]
+- **Target**: [Valor objetivo]
+
+### 4. Regras de Negócio
+
+Regras que o sistema deve sempre respeitar:
+- **RN-XXX**: [Regra em linguagem natural]
+- Contexto: Quando se aplica
+- Exceções: Se houver
+
+### 5. Matriz de Priorização MoSCoW
+
+| Prioridade | Requisitos | Justificativa |
+|------------|------------|---------------|
+| Must Have | [RFs essenciais] | Sem esses o sistema não funciona |
+| Should Have | [RFs importantes] | Alto valor, mas MVP funciona sem |
+| Could Have | [RFs desejáveis] | Nice to have |
+| Won't Have | [Fora do escopo] | Explicitamente excluídos |
+
+### 6. User Stories (Épicos Principais)
+
+Para os 3-5 fluxos principais, escreva User Stories:
+
+**US-XXX: [Título]**
+- Como [persona]
+- Quero [ação]
+- Para que [benefício]
+
+### 7. Critérios de Aceitação em Gherkin
+
+Para os requisitos mais críticos, escreva cenários BDD:
+
+```gherkin
+Funcionalidade: [Nome do RF]
+
+  Cenário: [Cenário de sucesso]
+    Dado que [pré-condição]
+    Quando [ação do usuário]
+    Então [resultado esperado]
+
+  Cenário: [Cenário de erro]
+    Dado que [pré-condição]
+    Quando [ação inválida]
+    Então [mensagem de erro esperada]
+```
+
+### 8. Dúvidas Pendentes
+
+Lista de perguntas que precisam ser respondidas pelo cliente:
+- [ ] [Dúvida 1] - Impacto: [Alto/Médio/Baixo]
+- [ ] [Dúvida 2] - Impacto: [Alto/Médio/Baixo]
+
+### 9. Glossário
+
+Termos específicos do domínio com definições claras.
+```
+
+---
+
+## Exemplo de Uso
+
+```text
+Atue como analista de requisitos sênior.
+
+## Contexto do Projeto
+
+Sistema de agendamento online para salões de beleza.
+
+## Notas Brutas
+
+Reunião 15/01 com Maria (dona do salão):
+- Cliente deve poder marcar horário pelo celular
+- Precisa ver quais horários estão disponíveis
+- Cada profissional tem sua agenda
+- Confirmação via WhatsApp é essencial
+- Cancelar precisa de pelo menos 2h de antecedência
+- Quer ver quantos agendamentos teve no mês
+- Não quer fazer pagamento online agora, só agendamento
+- Sistema precisa ser fácil, ela não é muito de tecnologia
+- Queria algo mais barato que R$200/mês
+```
+
+---
+
+## Resposta Esperada
+
+### 1. Visão Geral
+
+Sistema web responsivo para agendamento de serviços em salões de beleza. 
+Permite que clientes visualizem disponibilidade e agendem horários de forma 
+autônoma, recebendo confirmações via WhatsApp.
+
+### 2. Requisitos Funcionais
+
+#### Módulo: Agendamento
+
+**RF-001: Visualizar horários disponíveis**
+- Descrição: O sistema deve exibir os horários disponíveis por profissional
+- Prioridade: Must Have
+- Critérios de Aceitação:
+  - Mostra apenas horários futuros
+  - Filtra por profissional selecionado
+  - Indica duração do serviço
+- Dependências: RF-003
+
+**RF-002: Realizar agendamento**
+- Descrição: O sistema deve permitir que cliente agende um horário
+- Prioridade: Must Have
+- Critérios de Aceitação:
+  - Cliente informa nome e telefone
+  - Seleciona profissional, serviço e horário
+  - Recebe confirmação visual na tela
+- Dependências: RF-001
+
+**RF-003: Enviar confirmação WhatsApp**
+- Descrição: O sistema deve enviar mensagem de confirmação via WhatsApp
+- Prioridade: Must Have
+- Critérios de Aceitação:
+  - Mensagem enviada em até 1 minuto após agendar
+  - Contém data, hora, serviço e profissional
+
+### 3. Requisitos Não-Funcionais
+
+**RNF-001: Tempo de Resposta**
+- Categoria: Performance
+- Descrição: Telas devem carregar rapidamente
+- Métrica: Latência p95
+- Target: < 2 segundos
+
+**RNF-002: Disponibilidade**
+- Categoria: Confiabilidade
+- Descrição: Sistema deve estar disponível para agendamentos
+- Métrica: Uptime mensal
+- Target: 99.5%
+
+### 7. Gherkin
+
+```gherkin
+Funcionalidade: Agendar horário
+
+  Cenário: Cliente agenda horário com sucesso
+    Dado que estou na página de agendamento
+    E existe o profissional "Ana" com horário "14:00" disponível
+    Quando seleciono o serviço "Corte Feminino"
+    E escolho a profissional "Ana"
+    E escolho o horário "14:00"
+    E informo meu telefone "11999998888"
+    Então devo ver a mensagem "Agendamento confirmado!"
+    E devo receber uma mensagem no WhatsApp
+
+  Cenário: Cliente tenta agendar horário ocupado
+    Dado que o horário "14:00" já está ocupado
+    Quando tento selecionar o horário "14:00"
+    Então devo ver a mensagem "Horário indisponível"
+```
+
+---
+
+## Checklist Pós-Geração
+
+- [ ] Requisitos funcionais têm IDs únicos (RF-XXX)
+- [ ] Cada RF tem prioridade MoSCoW
+- [ ] Requisitos não-funcionais são mensuráveis
+- [ ] Regras de negócio estão documentadas
+- [ ] Pelo menos 3 cenários Gherkin para fluxos críticos
+- [ ] Dúvidas pendentes listadas com impacto
+- [ ] Glossário com termos do domínio
+- [ ] Matriz MoSCoW organizada
+- [ ] Salvar em `docs/02-requisitos/requisitos.md`