@maestro-ai/mcp-server 1.0.0 → 1.1.0

package/dist/content/content/prompts/observabilidade/slos.md

@@ -1,215 +0,0 @@
-# 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/dist/content/content/prompts/produto/discovery-inicial.md

@@ -1,203 +0,0 @@
-# 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/dist/content/content/prompts/produto/discovery-inicial.txt

@@ -1,33 +0,0 @@
-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/dist/content/content/prompts/requisitos/refinar-requisitos.md

@@ -1,232 +0,0 @@
-# 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`