jarvis-ai-framework 1.0.0

package/workflows/product/prod.spec.breakdown.md

@@ -0,0 +1,163 @@
+---
+name: prod.spec.breakdown
+description: Quebra uma especificação de produto grande (Documento de Requisitos de Produto ou Documento de Requisitos Funcionais) em fatias gerenciáveis — versões, épicos e histórias — sem perder o objetivo de valor.
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: high
+model_justification: Breakdown de produto exige julgamento de valor, sequenciamento e decomposição em entregas incrementais
+---
+
+# Quebra de especificação (breakdown)
+
+Este comando transforma uma especificação **grande demais para executar de uma vez** em um **plano detalhado (breakdown)**: versões / releases, épicos e esboço de histórias ou tarefas — com foco em **valor perceptível ao usuário**, não só em camadas técnicas.
+
+Antes de iniciar, revise as regras invioláveis em `$PROD_RULES/**/*`. Se a variável for desconhecida, leia `.$IDE/rules/product/**/*.*`.
+
+Guia humano (termos por extenso): `docs/produto/prod.spec.breakdown.md`.
+
+Utilize o `$ARGUMENTS` como ponto de partida (caminho da spec, nome da feature ou descrição do que fatiar):
+
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+## Quando usar
+
+- Documento de Requisitos de Produto ou Documento de Requisitos Funcionais monolítico
+- Time pergunta “por onde começamos?”
+- Precisa de milestones / entregas parciais antes de criar vários épicos à mão
+- Antes de `/prod.spec.epic` em série ou de um tsunami de `/prod.spec.issue`
+
+## Quando **não** usar
+
+- Spec ainda ambígua → execute `$PROD_FLOWS/prod.spec.clarify.md` **primeiro**
+- Escopo já cabe em uma história → `$PROD_FLOWS/prod.spec.issue.md`
+- Só quer um único épico sem árvore de releases → `$PROD_FLOWS/prod.spec.epic.md`
+- Quebra de **tech spec** em subtarefas de engenharia → isso é `eng.breakdown-subtasks` (outro domínio)
+
+## Pré-requisitos
+
+1. Existir (ou o usuário apontar) um Documento de Requisitos de Produto e/ou Documento de Requisitos Funcionais em `$PROD_DOCS` (ou path explícito nos argumentos).
+2. Se não houver spec pai: ofereça criar com `$PROD_FLOWS/prod.spec.prd.md` ou `$PROD_FLOWS/prod.spec.frd.md`. Não invente escopo do zero sem confirmação.
+3. Se a spec estiver cheia de “talvez” / “depois a gente vê”: sugira clarify antes; só continue se o usuário assumir o risco.
+
+## Skills
+
+Use a Skill tool:
+
+- **`prod-specs`** — gerar/atualizar o artefato de breakdown conforme o template e padrões do projeto
+
+Template canônico do skill: `skills/prod-specs/templates/prod-breakdown-template.md`  
+(Se existir cópia em `$PROD_TEMPLATES/prod-breakdown-template.md`, prefira a do `$PROD_TEMPLATES`.)
+
+## Busca no Central Docs (condicional)
+
+Se `CENTRAL_DOCS_REPO` estiver no `ENV.md`:
+
+1. `jarvis docs sync --silent` (best-effort)
+2. Localizar Documento de Requisitos de Produto / funcional relacionado (nome, tags, `TASK_MANAGER_KEY`)
+3. Usar como contexto; se não achar, seguir com arquivos locais em `$PROD_DOCS`
+
+## Sessões
+
+- Rascunhos WIP: `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`
+- Artefato canônico do breakdown: sob a pasta do Documento de Requisitos de Produto pai em `$PROD_DOCS` (não substitua a pasta de sessão pela canônica)
+
+## Resultado esperado
+
+1. Arquivo de **plano detalhado (breakdown)** em Markdown, no idioma da conversa.
+2. Convenção de nome sugerida (ajuste ao padrão de `prod-rules` se o projeto já tiver um):
+
+   `$PROD_DOCS/prd-{id}-{slug}/breakdown-{id}-{slug}.md`
+
+   Se não houver pasta de Documento de Requisitos de Produto, confirme com o usuário onde gravar.
+3. Árvore validada com o usuário: Versão → Épico → Histórias/tarefas (títulos + intenção de valor).
+4. Lista ordenada da **primeira fatia recomendada** para começar engenharia.
+
+**Não** crie automaticamente dezenas de arquivos de épico/história sem perguntar. O breakdown é o mapa; a materialização usa:
+
+- `$PROD_FLOWS/prod.spec.epic.md`
+- `$PROD_FLOWS/prod.spec.issue.md`
+
+## Diretrizes de produto (obrigatórias)
+
+- Prefira **fatias verticais** (usuário percebe valor) a fatias só técnicas (“primeiro só o banco”).
+- Cada épico proposto deve ter resultado de usuário em uma frase.
+- Histórias esboçadas devem parecer INVEST o suficiente para virar issue depois (não detalhe aceite micro aqui se for só título — deixe para `prod.spec.issue`).
+- Explicitar **fora de escopo** de cada versão quando fizer diferença de prioridade.
+- Dependências e caminho crítico: só o necessário para não planejar o impossível.
+- Idioma padrão: português do Brasil (salvo pedido do usuário).
+- Nunca inventar métricas, datas ou stakeholders — perguntar ou marcar como pendente.
+
+## Etapas de execução
+
+### 1. Carregar contexto
+
+- Ler `$IDE/ENV.md` (pastas `PROD_*`, `SESSIONS_DIR`, `TASK_MANAGER`)
+- Localizar e ler a spec pai (Documento de Requisitos de Produto e/ou Documento de Requisitos Funcionais)
+- Resumir em 3–5 bullets o problema, valor e restrições (confirmar com o usuário se estiver incerto)
+
+### 2. Detectar se precisa de clarify
+
+Se houver ambiguidades bloqueantes (papéis, regras de negócio críticas, fora de escopo indefinido):
+
+- Oferecer `$PROD_FLOWS/prod.spec.clarify.md`
+- Só seguir no breakdown se o usuário confirmar
+
+### 3. Propor a árvore de entregas
+
+Montar rascunho interno (ainda sem gravar arquivo final):
+
+```
+Versão / Release
+  └── Épico (valor)
+        └── Histórias / tarefas (títulos)
+```
+
+Perguntar **uma coisa por vez** (usar AskUserQuestion se disponível; senão tabela A/B/C/D das prod-rules):
+
+- Ordem de valor (o que aprender primeiro com usuários?)
+- Quantas versões fazem sentido agora (evitar over-planning)
+- Se alguma fatia é spike / risco técnico consciente
+
+### 4. Validar o relacionamento
+
+Mostrar a árvore ao usuário e **pedir confirmação explícita** antes de gravar o breakdown (o template exige isso).
+
+### 5. Gerar o artefato
+
+- Executar skill `prod-specs` com o template de breakdown
+- Preencher resumo, lançamentos, épicos, dependências (seções opcionais só se o usuário pedir ou se forem críticas)
+- Gravar em `$PROD_DOCS/...` (ou path acordado)
+- Atualizar índice/docs existentes se o projeto já tiver índice de produto
+
+### 6. Oferecer próximos comandos
+
+Ao final, perguntar o que materializar agora:
+
+| Opção | Comando |
+|-------|---------|
+| Criar o primeiro épico | `$PROD_FLOWS/prod.spec.epic.md` |
+| Criar histórias da primeira fatia | `$PROD_FLOWS/prod.spec.issue.md` |
+| Esclarecer um ramo ainda frouxo | `$PROD_FLOWS/prod.spec.clarify.md` |
+| Ir para engenharia na fatia 1 | `/eng.start` (com `TASK_MANAGER_KEY`) |
+
+## Do / Don’t
+
+**Do**
+
+- Manter rastreio ao documento pai
+- Nomear fatias pelo resultado de usuário
+- Deixar explícito o que **não** entra na versão 1
+
+**Don’t**
+
+- Transformar breakdown em lista de tarefas de infra sem história de valor
+- Criar 15 épicos “por precaução”
+- Copiar a spec pai inteira no arquivo de breakdown
+- Confundir com `eng.breakdown-subtasks` (tech spec → subtarefas de código)
+
+## Status
+
+Itens criados ou referenciados devem respeitar `$ITEM_STATUS` das prod-rules (`icebox`, `in_review`, `backlog`, …). Breakdown recém-criado em geral nasce como `in_review` até o usuário priorizar a versão 1 (`backlog`).

package/workflows/product/prod.spec.clarify.md

@@ -0,0 +1,178 @@
+---
+name: prod.spec.clarify
+description: Identificar áreas subespecificadas na especificação da feature atual fazendo até 5 perguntas de esclarecimento altamente direcionadas e incorporando as respostas de volta na spec.
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+recommended_model: gpt-4o
+model_tier: medium
+model_justification: Esclarecimento de specs requer análise estruturada e formulação de perguntas, mas segue processo bem definido
+---
+
+## Clarify workflow
+
+Detectar e reduzir ambiguidades ou pontos de decisão ausentes na especificação da feature ativa e registrar os esclarecimentos diretamente no arquivo da spec.
+
+Rascunhos WIP (se houver) em `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/`. O heading `### Session YYYY-MM-DD` é um log **dentro da spec canônica** — não é a pasta `$SESSIONS_DIR`.
+
+Observação: Este workflow de esclarecimento deve ser executado (e concluído) ANTES da etapa de planejamento. Se o usuário declarar explicitamente que está pulando o esclarecimento (por exemplo, spike exploratório), você pode prosseguir, mas deve avisar que o risco de retrabalho posterior aumenta.
+
+Utilize o que o usuário fornecer analisar em:
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+Etapas de execução:
+
+1. Carregue o arquivo atual da spec. Realize uma varredura estruturada de ambiguidades e cobertura usando esta taxonomia. Para cada categoria, marque o status: Claro / Parcial / Ausente. Produza um mapa de cobertura interno usado para priorização (não divulgue o mapa bruto a menos que nenhuma pergunta seja feita). Analise o arquivo da spec e realize uma cobertura apenas com os itens que estão incluídos na especificação do usuário.
+
+Ao final do processo, peça ao usuário para confirmar o esclarecimento e liste os itens ausentes, perguntando se ele quer esclarecê-los.
+
+Escopo Funcional & Comportamento:
+- Principais objetivos do usuário & critérios de sucesso
+- Declarações explícitas de fora de escopo
+- Diferenciação de papéis / personas dos usuários
+
+Domínio & Modelo de Dados:
+- Entidades, atributos, relacionamentos
+- Regras de identidade & unicidade
+- Transições de ciclo de vida/estado
+- Suposições de volume de dados / escala
+
+Interação & Fluxo de UX:
+- Jornadas / sequências críticas do usuário
+- Estados de erro/vazio/carregamento
+- Observações de acessibilidade ou localização
+
+Atributos de Qualidade Não Funcionais:
+- Desempenho (latência, metas de throughput)
+- Escalabilidade (horizontal/vertical, limites)
+- Confiabilidade & disponibilidade (expectativas de uptime e recuperação)
+- Observabilidade (logging, métricas, sinais de tracing)
+- Segurança & privacidade (authN/Z, proteção de dados, suposições de ameaça)
+- Restrições de compliance / regulatórias (se houver)
+
+Integração & Dependências Externas:
+- Serviços/APIs externos e modos de falha
+- Formatos de importação/exportação de dados
+- Suposições de protocolo/versionamento
+
+Casos Limite & Tratamento de Falhas:
+- Cenários negativos
+- Rate limiting / throttling
+- Resolução de conflitos (por exemplo, edições simultâneas)
+
+Restrições & Trade-offs:
+- Restrições técnicas (linguagem, armazenamento, hospedagem)
+- Trade-offs explícitos ou alternativas rejeitadas
+
+Terminologia & Consistência:
+- Termos de glossário canônicos
+- Sinônimos evitados / termos obsoletos
+
+Sinais de Conclusão:
+- Testabilidade dos critérios de aceitação
+- Indicadores mensuráveis de Definition of Done
+
+Diversos / Placeholders:
+- Marcadores TODO / decisões não resolvidas
+- Adjetivos ambíguos (“robusto”, “intuitivo”) sem quantificação
+
+Para cada categoria com status Parcial ou Ausente, adicione uma oportunidade de pergunta candidata, a menos que:
+- O esclarecimento não altere materialmente a estratégia de implementação ou validação
+- A informação seja melhor postergada para a fase de planejamento (anote internamente)
+
+3. Gere (internamente) uma fila priorizada de perguntas de esclarecimento candidatas (máximo de 5). IMPORTANTE: Não as apresente todas de uma vez. Aplique estas restrições:
+   - Máximo de 10 perguntas no total ao longo de toda a sessão.
+   - Cada pergunta deve ser respondida COM:
+      - Uma seleção curta de múltipla escolha (2–5 opções distintas, mutuamente exclusivas), OU
+      - Uma resposta de uma palavra / frase curta (restrinja explicitamente: “Responda em <=5 palavras”).
+   - Inclua apenas perguntas cujas respostas impactem materialmente arquitetura, modelagem de dados, decomposição de tarefas, design de testes, comportamento de UX, prontidão operacional ou validação de compliance.
+   - Garanta equilíbrio de cobertura por categoria: tente cobrir primeiro as áreas não resolvidas de maior impacto; evite fazer duas perguntas de baixo impacto quando uma área de alto impacto (por exemplo, postura de segurança) está sem resolução.
+   - Exclua perguntas já respondidas, preferências estilísticas triviais ou detalhes de execução de planejamento (a menos que bloqueiem a correção).
+   - Priorize esclarecimentos que reduzam risco de retrabalho posterior ou evitem testes de aceitação desalinhados.
+   - Se mais de 5 categorias permanecerem sem resolução, selecione as 5 principais pelo critério heurístico (Impacto * Incerteza).
+
+4. Loop de questionamento sequencial (interativo):
+    - Apresente EXATAMENTE UMA pergunta por vez.
+    - Se estivermos esclarecendo um PRD, não pergunte sobre microinterações. Deixe para esclarecer microinteração apenas na fase de criação de histórias e tarefas.
+    - Para perguntas de múltipla escolha:
+       - **Analise todas as opções** e determine a **opção mais adequada** com base em:
+          - Melhores práticas para o tipo de projeto
+          - Padrões comuns em implementações similares
+          - Redução de risco (segurança, desempenho, manutenibilidade)
+          - Alinhamento com quaisquer metas ou restrições explícitas do projeto visíveis na spec
+       - Apresente a **opção recomendada** de forma destacada no topo com uma explicação clara (1-2 frases explicando por que é a melhor escolha).
+       - Formate como: `**Recomendado:** Opção [X] - <justificativa>`
+       - Em seguida, renderize todas as opções em uma tabela Markdown:
+
+       | Option | Description |
+       |--------|-------------|
+       | A | <Descrição da Opção A> |
+       | B | <Descrição da Opção B> |
+       | C | <Descrição da Opção C> (adicione D/E conforme necessário até 5) |
+       | Short | Forneça uma resposta curta diferente (<=5 palavras) (Inclua somente se alternativa livre fizer sentido) |
+
+       - Após a tabela, adicione: `Você pode responder com a letra da opção (por exemplo, "A"), aceitar a recomendação dizendo "sim" ou "recomendado", ou fornecer sua própria resposta curta.`
+    - Para perguntas de resposta curta (sem opções discretas significativas):
+       - Forneça sua **resposta sugerida** com base nas melhores práticas e no contexto.
+       - Formate como: `**Sugerido:** <sua resposta proposta> - <breve justificativa>`
+       - Depois, escreva: `Formato: Resposta curta (<=5 palavras). Você pode aceitar a sugestão dizendo "sim" ou "sugerido", ou fornecer sua própria resposta.`
+    - Após o usuário responder:
+       - Se o usuário responder com “sim”, “recomendado” ou “sugerido”, use a recomendação/sugestão previamente apresentada como resposta.
+       - Caso contrário, valide se a resposta corresponde a uma opção ou se respeita a restrição de <=5 palavras.
+       - Se estiver ambígua, peça um rápido esclarecimento (conta ainda como a mesma pergunta; não avance).
+       - Assim que estiver satisfatória, registre-a na memória de trabalho (ainda sem gravar em disco) e avance para a próxima pergunta enfileirada.
+    - Pare de fazer perguntas adicionais quando:
+       - Todas as ambiguidades críticas forem resolvidas cedo (itens restantes na fila tornam-se desnecessários), OU
+       - O usuário sinalizar conclusão (“done”, “good”, “no more”), OU
+       - Você atingir 5 perguntas realizadas.
+    - Nunca revele previamente perguntas futuras na fila.
+    - Se não houver perguntas válidas no início, relate imediatamente que não existem ambiguidades críticas.
+
+5. Integração após CADA resposta aceita (abordagem de atualização incremental):
+    - Mantenha uma representação em memória da spec (carregada uma única vez no início) além do conteúdo bruto do arquivo.
+    - Para a primeira resposta integrada nesta sessão:
+       - Garanta que exista uma seção `## Clarifications` (crie-a logo após a seção contextual/de visão geral de nível mais alto conforme o template da spec, se estiver ausente).
+       - Sob ela, crie (se não existir) um subtítulo `### Session YYYY-MM-DD` para hoje.
+    - Acrescente imediatamente após a aceitação um item em bullet: `- Q: <pergunta> → A: <resposta final>`.
+    - Em seguida, aplique a clarificação diretamente nas seções mais apropriadas:
+       - Ambiguidade funcional → Atualize ou adicione um bullet em Requisitos Funcionais.
+       - Interação do usuário / distinção de atores → Atualize a subseção de Histórias de Usuário ou Atores (se existir) com o papel, restrição ou cenário esclarecido.
+       - Forma de dados / entidades → Atualize o Modelo de Dados (adicione campos, tipos, relacionamentos) preservando a ordem; registre restrições adicionadas de forma sucinta.
+       - Restrição não funcional → Adicione/modifique critérios mensuráveis na seção de Não Funcionais / Atributos de Qualidade (converta adjetivos vagos em métricas ou metas explícitas).
+       - Caso limite / fluxo negativo → Acrescente um novo bullet em Casos Limite / Tratamento de Erros (ou crie tal subseção se o template tiver placeholder).
+       - Conflito de terminologia → Normalize o termo na spec; mantenha o original apenas se necessário adicionando `(anteriormente referido como "X")` uma única vez.
+    - Se o esclarecimento invalidar uma afirmação ambígua anterior, substitua essa afirmação em vez de duplicá-la; não deixe texto contraditório.
+    - Salve o arquivo da spec APÓS cada integração para minimizar risco de perda de contexto (sobrescrita atômica).
+    - Preserve a formatação: não reordene seções não relacionadas; mantenha a hierarquia de headings intacta.
+    - Mantenha cada clarificação inserida mínima e testável (evite desvio narrativo).
+
+6. Validação (executada após CADA escrita e no passe final):
+   - A sessão de clarificações contém exatamente um bullet por resposta aceita (sem duplicatas).
+   - Total de perguntas feitas (aceitas) ≤ 5.
+   - Seções atualizadas não contêm placeholders vagos remanescentes que a nova resposta deveria resolver.
+   - Nenhuma afirmação anterior contraditória permanece (verifique se alternativas agora inválidas foram removidas).
+   - Estrutura Markdown válida; únicos headings novos permitidos: `## Clarifications`, `### Session YYYY-MM-DD`.
+   - Insira as sessões de esclarecimento após o bloco de Requisitos.
+   - Consistência de terminologia: mesmo termo canônico usado em todas as seções atualizadas.
+
+7. Escreva a spec atualizada de volta em `FEATURE_SPEC`.
+
+8. Informe a conclusão (após o término do loop de perguntas ou encerramento antecipado):
+   - Número de perguntas feitas & respondidas.
+   - Caminho para a spec atualizada.
+   - Seções tocadas (liste os nomes).
+   - Tabela de resumo de cobertura listando cada categoria da taxonomia com Status: Resolvido (era Parcial/Ausente e foi tratada), Adiado (excede a cota de perguntas ou melhor tratar no planejamento), Claro (já estava suficiente), Pendente (ainda Parcial/Ausente mas de baixo impacto).
+   - Se restarem itens Pendentes ou Adiados, recomende prosseguir para `/product/prod.spec.plan.md` ou rodar `/product/prod.spec.clarify.md` novamente após o planejamento.
+   - Próximo comando sugerido.
+
+Regras de comportamento:
+
+- Se nenhuma ambiguidade significativa for encontrada (ou se todas as perguntas potenciais forem de baixo impacto), responda: “Nenhuma ambiguidade crítica detectada que valha esclarecimento formal.” e sugira prosseguir.
+- Se o arquivo da spec estiver ausente, instrua o usuário a rodar `/product/prod.spec.md` primeiro (não crie uma nova spec aqui).
+- Nunca exceda 5 perguntas feitas no total (reformulações de uma mesma pergunta não contam como novas).
+- Evite perguntas especulativas sobre stack tecnológica, a menos que a ausência bloqueie a clareza funcional.
+- Respeite sinais de encerramento antecipado do usuário (“stop”, “done”, “proceed”).
+- Se nenhuma pergunta for feita devido à cobertura completa, forneça um resumo de cobertura compacto (todas as categorias Claras) e sugira avançar.
+- Se a cota for atingida com categorias de alto impacto ainda não resolvidas, destaque-as explicitamente como Adiadas com a justificativa.
+

package/workflows/product/prod.spec.epic.md

@@ -0,0 +1,154 @@
+---
+name: prod.spec.epic
+description: Fluxo de trabalho para criação de épicos que agrupam histórias de usuários e tarefas relacionadas seguindo as diretrizes do Product Spec Kit.
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+recommended_model: gpt-4o
+model_tier: medium
+model_justification: Criação de épicos segue templates estruturados e requer compreensão de contexto de produto
+---
+
+# Crie um fluxo de trabalho épico
+
+Este fluxo de trabalho orienta você na criação de um épico usando `$PROD_TEMPLATES/prod-epic-template.md`. épicos agrupam histórias de usuários relacionadas que oferecem uma funcionalidade significativa.
+
+Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entender o contexto do que foi pedido.
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+## Quando usar
+- Ao dividir grandes recursos ou PRDs em partes gerenciáveis
+- Quando o trabalho abrange vários sprints ou iterações
+- Ao coordenar o trabalho entre várias equipes
+- Se precisar agrupar várias histórias ou tasks de um mesmo tema ou entrega
+- Para recursos ou componentes principais que precisam de rastreamento em um nível superior
+- Quando o usuári quiser criar um épico independente de especificações anteriores ou para projetos que já estão em andamento
+
+## Pré-requisitos e opcionais
+- Ter uma PRD existente ou requisitos de produto é importante, mas opcional. Questione o usuário se ele deseja criar um PRD ou se ele deseja criar um épico independente de especificações anteriores ou para projetos que já estão em andamento
+- Ter um breakdown existente é importante, mas opcional. Questione o usuário se ele deseja criar um breakdown (siga o fluxo de trabalho `prod.spec.breakdown.md`) ou se ele deseja criar um épico independente de especificações anteriores ou para projetos que já estão em andamento
+- Compreensão de alto nível da abordagem técnica
+
+## Resultado final
+- Por padrão, use o modelo `$PROD_TEMPLATES/prod-epic-template.md` integralmente
+- Siga a estrutura do modelo exatamente como definida, não pule passos, a não ser que o usuário solicite explicitamente
+- Nomeie o arquivo usando a convenção: `$PROD_DOCS/{epic-ID}-{epic-name}.md` (se não existir uma PRD para pegar o nome, ignore esse prefixo)
+- O arquivo final deverá estar no mesmo idioma da interação do usuário
+
+## Diretrizes do épico
+- Concentre-se no “o que” e não no “como”
+- Cada épico deve agregar valor independente
+- Mantenha os épicos em um tamanho gerenciável (normalmente de 2 a 4 semanas de trabalho)
+- Garantir critérios de aceitação claros, não levando para o micro interações de usuário (isso fica em histórias e tasks), mas sim na solução de alto nível, possibilitando que as histórias e tasks sejam criadas com base nessas informações
+- Link para PRD relacionado ou iniciativa dos pais
+
+## Etapas de execução
+
+### 1. Validar pré-requisitos
+Verifique se existe um PRD ou plano de detalhamento. Caso contrário, oriente o usuário a criar um primeiro usando o fluxo de trabalho apropriado.
+
+### 2. Defina detalhes épicos
+1. **Nome épico**: título claro e voltado para a ação
+2. **Lançamento**: Lançamento associado (se aplicável)
+3. **Contexto**: Antecedentes e importância
+4. **Declaração do problema**: qual problema do usuário ou da empresa isso resolve
+5. **Solução**: abordagem de alto nível para resolver o problema
+
+### 3. Definir critérios de aceitação
+- Definir 3-5 critérios de aceitação de alto nível
+- Concentre-se nos resultados e não nos detalhes da implementação
+- Garantir que os critérios sejam testáveis e mensuráveis
+- Baseie-se nas necessidades do usuário, não em detalhes técnicos
+
+### 4. Identifique histórias relacionadas
+- Liste histórias de usuários conhecidas que pertencem a este épico
+- Cada história deve ser valiosa de forma independente
+- Incluir IDs de histórias e breves descrições
+- Defina prioridades sempre que possível
+
+### 5. Considerações técnicas do documento
+- Principais decisões de arquitetura
+- Dependências principais
+- Considerações de desempenho
+- Requisitos de segurança
+
+## Melhores práticas
+
+### Do
+- Mantenha os épicos focados em um único objetivo
+- Garantir que cada épico ofereça valor tangível
+- Torne os critérios de aceitação claros e testáveis
+- Alinhar com estratégia de produto e PRD
+- Incluir as partes interessadas relevantes na revisão
+
+### Don't
+- Faça épicos muito grandes ou muito pequenos
+- Incluir detalhes de implementação nos critérios de aceitação
+- Esquecer de vincular a PRDs relacionados ou iniciativas dos pais
+- Ignorar dependências técnicas
+- Ignore o processo de revisão
+
+## Integração com outros fluxos de trabalho
+- **PRD**: os épicos devem estar alinhados aos requisitos do produto. Se não existir um PRD, oriente o usuário a criar um usando o fluxo em `prod.spec.prd.md` ou a fornecer mais informações para que o épico seja construído
+- **Histórias**: eventualmente os épicos serão divididos em diversas histórias de usuários ou tasks, então, mantenha as informações de forma que isso seja possível
+- **Sprints**: os épicos normalmente abrangem vários sprints ou semanas, abrangendo várias entregas menores em formatos de histórias e tasks
+- **Problemas**: pode gerar tarefas ou bugs relacionados
+
+## Próximas etapas
+Depois de criar um épico, pergunte para o usuário:
+1. Se o ele quer explorar ou modificar algum tópico do épico ou se aprova o conteúdo final
+1. Escrever as histórias de usuário ou tasks relacionadas ao épico que forma planejadas e/ou que o usuário sugeriu. Utilize o fluxo de trabalho `prod.spec.issue.md`
+
+## Atualize os docs
+Após a aprovação do usuário:
+1. Atualize a PRD com as alterações relacionadas ao épico
+2. Atualize o arquivo de breakdown (plan) com as alterações relacionadas ao épico
+
+## Busca no Central Docs (condicional)
+
+Se `CENTRAL_DOCS_REPO` definido no ENV.md, antes de criar o épico:
+
+- Executar busca automática no central-docs:
+  ```bash
+  jarvis docs sync --silent
+  ```
+- Buscar PRD e épicos existentes relacionados usando o contexto do usuário
+- Se PRD ou épico encontrado: carregar como contexto e informar o usuário
+- Se não encontrado: continuar com fluxo normal
+
+## Publicação no Central Docs (condicional)
+
+Após salvar o épico localmente e obter aprovação do usuário:
+
+1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+   - Perguntar ao usuário:
+     ```
+     Deseja publicar este épico no repositório central de documentação?
+     - ( ) Sim, publicar agora
+     - ( ) Não, vou publicar depois manualmente
+     ```
+
+2. Se **Sim**:
+   - Extrair o slug do nome do arquivo (ex: `epic-123-checkout.md` → `checkout`)
+   - Executar:
+     ```bash
+     jarvis docs publish \
+       --file {caminho_do_epico} \
+       --tipo epic \
+       --feature {slug}
+     ```
+
+3. Informar resultado:
+   - ✅ Sucesso: "Épico publicado no central-docs. MR criado: [URL]"
+   - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
+
+4. Se **Não**:
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo epic --feature {slug}`"
+
+> **Nota**: A publicação cria um Merge Request no GitLab. O épico só será visível no central-docs após aprovação e merge do MR.
+
+Utilize o que o usuário fornecer analisar em:
+<requirement>
+#$ARGUMENTS
+</requirement>

package/workflows/product/prod.spec.frd.md

@@ -0,0 +1,96 @@
+---
+name: prod.spec.frd
+description: Fluxo para criação de FRD (Feature Requirements Document), que auxilia na definição detalhada dos requisitos funcionais de uma feature
+auto_execution_mode: 3
+env_file: "@/ENV.md"
+recommended_model: claude-sonnet-4-20250514
+model_tier: high
+model_justification: FRDs requerem análise detalhada de requisitos funcionais, comportamento de usuário e especificações técnicas
+---
+
+# FRD - Functional Requirement Document
+
+Este comando tem como objetivo criar, atualizar ou editar uma FRD seguindo o template especificado e as instruções.
+
+Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/**/*`. Se você não estiver familiarizado com essa variável, leia as regras diretamente na pasta `.$IDE/rules/product/**/*.*`.
+
+Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entender o contexto do que foi pedido.
+<requirement>
+#$ARGUMENTS
+</requirement>
+
+## Skills que devem ser usadas
+
+Utilize a Skill tool para executar as skills necessárias:
+
+- **Para gerar ou modificar especificações de produto** use a Skill tool para executar a skill `prod-specs` para gerar uma o output final de uma FRD de acordo com os padrões estabelecidos;
+
+## Busca no Central Docs (condicional)
+
+Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+
+1. **Buscar PRD correspondente:**
+   - Executar busca automática no central-docs:
+     ```bash
+     jarvis docs sync --silent
+     ```
+   - Buscar PRD relacionado usando:
+     - Nome/contexto fornecido pelo usuário
+     - Jira ID (se disponível)
+     - Tags semânticas
+   - Se PRD encontrado no central-docs:
+     - Carregar automaticamente como base para o FRD
+     - Informar ao usuário: "✅ PRD encontrado no central-docs: [nome]"
+     - Passar como contexto para a skill `prod-specs`
+   - Se não encontrado:
+     - Perguntar ao usuário se tem PRD localmente
+     - Continuar com fluxo normal
+
+## Instruções
+
+- Se o usuário forneceu ou está atuando em um projeto existente, priorize obter informações sobre o projeto a partir de:
+  - **Central-docs** (se configurado) - busca automática do PRD correspondente
+  - Documentação existente (README, docs/, PRDs, FRDs, ARDs, etc.)
+  - Commits recentes para entender o que está sendo desenvolvido
+  - Arquivos de AI como CLAUDE.md e AGENTS.md para obter informações estruturadas sobre o contexto do projeto/produto.
+- Para fazer perguntas para o usuário, tente usar o tool `AskUserQuestion` se ele estiver disponível no seu ambiente
+- Use a Skill tool para executar a skill `prod-specs` para gerar o output final de acordo com os padrões estabelecidos, enviando as informações que encontrou como contexto
+- Quando receber output disponibilizado pela skill, mostre para o usuário o resultado final para a aprovação e validação.
+- Quando confirmado e validado pelo usuário:
+  - Se o usuário estiver modificando ou atualizando uma spec existente, salve o arquivo modificado
+  - Se for uma spec nova:
+    - Salve na pasta `$PROD_DOCS` seguindo todos os padrões de nomenclatura e estrutura de pastas já estabelecidos em `$PROD_RULES/**/*`
+
+## Publicação no Central Docs (condicional)
+
+Após salvar o FRD localmente e obter aprovação do usuário:
+
+1. Se `CENTRAL_DOCS_REPO` definido no ENV.md:
+   - Perguntar ao usuário:
+     ```
+     Deseja publicar este FRD no repositório central de documentação?
+     - ( ) Sim, publicar agora
+     - ( ) Não, vou publicar depois manualmente
+     ```
+
+2. Se **Sim**:
+   - Extrair o slug do nome do arquivo (ex: `frd-wallet-saque.md` → `wallet-saque`)
+   - Executar:
+     ```bash
+     jarvis docs publish \
+       --file {caminho_do_frd} \
+       --tipo frd \
+       --feature {slug}
+     ```
+
+3. Informar resultado:
+   - ✅ Sucesso: "FRD publicado no central-docs. MR criado: [URL]"
+   - ❌ Erro: Exibir mensagem de erro e orientar troubleshooting
+
+4. Se **Não**:
+   - Informar: "Para publicar depois, execute: `jarvis docs publish --file {caminho} --tipo frd --feature {slug}`"
+
+5. Se `CENTRAL_DOCS_REPO` não estiver definido:
+   - Informar: "Para habilitar publicação automática, configure `CENTRAL_DOCS_REPO` no ENV.md"
+
+> **Nota**: A publicação cria um Merge Request no GitLab. O FRD só será visível no central-docs após aprovação e merge do MR.