jarvis-ai-framework 1.0.3 → 2.0.0

package/skills/prod-specs/references/prod.spec.epic.md

@@ -1,107 +0,0 @@
----
-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.
-
-
-## 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
-
-Utilize o que o usuário fornecer analisar em:
-<requirement>
-#$ARGUMENTS
-</requirement>

package/skills/prod-specs/references/prod.spec.frd.md

@@ -1,135 +0,0 @@
----
-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"
-allowed-tools: Read, Grep
-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 - Feature Requirements Document
-
-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
-- Quando é necessário documentar requisitos funcionais detalhados para uma feature
-- Antes do desenvolvimento para garantir clareza sobre o que deve ser construído
-- Para alinhar equipes técnicas e de produto sobre os requisitos esperados
-- Para documentar critérios de aceitação claros e testáveis
-- Para descrever o funcionamento detalhado da feature a partir do comportamento do usuário, de especificações de produto e de design
-
-## Princípios Fundamentais
-1. **Sempre use o template** localizado em  `$SKILL_TEMPLATE_FOLDER/prod-frd-template.md`
-2. **Nunca crie o arquivo final com suposições não validadas** — sempre confirme sugestões primeiro
-3. **Seja inteligente, não robótico** — analise o contexto e proponha sugestões inteligentes, não faça perguntas vazias
-
----
-
-## Sobre a atuação e função de uma FRD
-
-A FRD não é um épico, história ou task: ela serve como documento de detalhamento que descreve profundamente os requisitos funcionais e não funcionais de uma solução de produto, atuando como ponte entre a especificação de produto e o código. Ela unifica requisitos e critérios da funcionalidade do ponto de vista de produto, usuário, design e técnico.
-
-- A partir de FRDs é possível criar épicos, histórias e tasks
-- FRDs são relacionadas a PRDs e também a ARDs
-- FRDs são formadas por features, ações e jornadas que o usuário executa na plataforma
-- FRD não é um produto, mas uma solução dentro de um produto
-- Dentro das FRDs devem ter as descrições micro de ações e sub-funcionalidades
-- Uma FRD descreve a solução nível médio, que faz parte de um produto ou solução maior descrita no PRD
-- A FRD precisa descrever o comportamento do usuário e do sistema de forma detalhada, agrupando micro-ações e jobs to be done do usuário
-
----
-
-## Fluxo de Trabalho
-
-O fluxo é dividido em checkpoints obrigatórios (gates). Você NÃO DEVE avançar para o próximo gate até que o usuário aprove explicitamente o atual. NUNCA gere o arquivo final até que TODOS os gates sejam aprovados.
-
-Não busque validação de tudo de uma vez; valide os gates de forma incremental.
-
-### Gate 1: Reconhecer e contextualizar
-
-- Reconheça o que o usuário forneceu (liste o que foi recebido) 
-- Utilize o contexto fornecido pelo usuário ou pelo agente para criar o output final
-- Se houverem PRDs, liste-as para que o usuário possa escolher qual é o PRD de origem desta FRD. Se não houver PRD, pergunte se o usuário quer criar uma antes ou continuar sem PRD relacionada
-- Faça 2–3 perguntas estratégicas sobre: escopo da feature, usuário impactado, restrições técnicas ou de design conhecidas
-- **PARE e aguarde a resposta do usuário antes de prosseguir**
-
-### Gate 2: Lista de Features e Jornada do Usuário
-
-- Pergunte para o usuário se ele já tem informações de features relacionadas a essa FRD
-- Proponha a lista de features que compõem este FRD — cada feature deve ser uma funcionalidade específica e implementável, e não uma tarefa técnica ou história de usuário
-- Utilize as informações do usuário para escrever uma descrição de até 350 caracteres de cada feature, sintetizando o que aquela feature deve fazer e o seu resultado
-- Formato: "Para a feature [Nome], sugiro: [descrição]. Justificativa: [por quê].
-- Apresente um rascunho da jornada do usuário com base no que foi fornecido. Pergunte se o usuário tem artefatos de design (layouts, imagens, diagramas, links de Figma ou similares) que possam enriquecer a jornada
-- **PARE e aguarde confirmação do usuário antes de prosseguir**
-
-### Gate 3: Sugerir conteúdo para seções ausentes
-
-- Para CADA seção do template que o usuário NÃO forneceu conteúdo explicitamente, apresente suas sugestões com justificativa. Se o usuário pular, não inclua o bloco no output final 
-- Agrupe sugestões relacionadas (ex.: todos os requisitos juntos, todas as dependências juntas)
-- Formato: "Para [Nome da Seção], sugiro: [conteúdo]. Justificativa: [por quê]. Devo incluir, modificar ou remover?"
-- Seções que DEVEM ser validadas se não fornecidas: TL;DR, Introdução e contexto, Requisitos e critérios, Dependências, O que essa solução não é
-- Se você identificar que está em uma pasta que contém o código do projeto/produto, procure entender o contexto. Mostre uma sugestão para o usuário de critérios técnicos do que você encontrou (endpoints, tabelas, tecnologias), e pergunte se ele quer confirmar, validar ou deixar para depois. Se depois, preencha apenas com comportamentos de produto e do usuário
-- **PARE e aguarde o usuário aprovar, modificar ou rejeitar CADA grupo de sugestões antes de prosseguir**
-
-### Gate 4: Gerar output final
-
-- Se está modificando uma FRD existente, atualize apenas as seções alteradas ou especificadas pelo usuário. Não modifique o arquivo sem pedido explícito
-- Somente após os Gates 1–3 aprovados, gere o output final usando o template em `$SKILL_TEMPLATE_FOLDER/prod-frd-template.md`
-- O output deve conter APENAS: conteúdo fornecido pelo usuário + sugestões aprovadas, seguindo o template
-- Se uma seção não tiver conteúdo fornecido ou aprovado, deixe em branco com marcador TODO e informe o usuário
-
----
-
-## Abordagens por Contexto
-
-**Contexto rico** (documento, PRD ou requisitos detalhados fornecidos):
-- Analise o que está completo vs. o que está faltando
-- Sugira complementos com raciocínio: "Com base em X, sugiro Y porque Z. Está correto?"
-- Agrupe sugestões relacionadas
-
-**Contexto mínimo** (apenas uma ideia ou nome de feature):
-- Faça perguntas direcionadas para o TL;DR (O QUÊ / POR QUÊ / COMO)
-- Infira contexto adicional e valide: "A partir das suas respostas, infiro X. Devo incluir isso?"
-
-**Feature de projeto existente**:
-- Leia o código-fonte, documentos e FRDs existentes primeiro
-- Sugira a jornada e as features com base na análise para confirmação
-
-**Design disponível**:
-- Use os artefatos de design (Figma, imagens) como fonte primária para a jornada
-- Derive os requisitos a partir dos fluxos de tela, não ao contrário
-
----
-
-## Padrões de Qualidade
-
-✅ **Boa sugestão**: Contextual, específica, orientada ao comportamento do usuário
-```
-Com base no fluxo de cadastro de oficinas, sugiro como requisito:
-"Quando o usuário clica em 'Salvar', o sistema valida os campos obrigatórios
-em tempo real e exibe mensagens de erro inline abaixo de cada campo inválido."
-
-Isso cobre o comportamento esperado e o estado de erro. Posso usá-lo?
-```
-
-❌ **Má sugestão**: Genérica, sem comportamento definido
-```
-O sistema deve validar os dados do formulário.
-```
-
----
-
-## Evite
-- Perguntas vazias sem sugestões quando há contexto disponível
-- Perguntar sobre cada pequeno detalhe separadamente
-- Misturar requisitos funcionais com não funcionais no mesmo item
-- Requisitos vagos ou não testáveis ("o sistema deve ser rápido")
-- Combinar múltiplos comportamentos em um único requisito
-- Inventar jornadas, fluxos ou restrições técnicas sem base no input do usuário
-- Criar o documento final antes de o usuário validar as suposições
-- Superengenheirar — foque nas necessidades principais, não em casos extremos desnecessários

package/skills/prod-specs/references/prod.spec.issue.md

@@ -1,145 +0,0 @@
----
-name: prod.spec.issue
-description: Criar um especificação de issues como Histórias de Usuário, Tarefas técnicas e bugs, seguindo as melhores práticas de gestão de produto e projeto.
-auto_execution_mode: 3
-env_file: "@/ENV.md"
-recommended_model: gpt-4o
-model_tier: medium
-model_justification: Criação de issues é estruturada e segue templates, requer boa compreensão mas não raciocínio extremamente complexo
----
-
-# Fluxo de Criação de Issues
-
-Antes de iniciar, revise o arquivo de regras invioláveis em `$PROD_RULES/prod-spec-rules.md`.
-
-Este fluxo orienta você na criação de issues (histórias de usuários, tarefas, bugs etc) bem definidas usando o template `$PROD_TEMPLATES/prod-issue-template.md`. Cada issue deve ser uma unidade de trabalho autocontida que pode ser completada dentro de uma única sprint.
-
-Uma issue é a menor unidade de trabalho que pode ser feita. Ela deve entregar valor sozinha. Ela precisa ser o menor tamanho possível para entregar rápido e com qualidade, mas não pode ser tão pequena que não entrega valor percebido para o usuário ou para o produto.
-
-Um grupo de histórias de um mesmo assunto podem formar um épico.
-
-## Quando Usar
-- Ao decompor épicos em histórias de usuário implementáveis
-- Criar tarefas técnicas
-- Criar requisitos não funcionais
-- Documentar e rastrear bugs
-- Quando você precisa capturar trabalho que não requer documentação completa de PRD
-- Para qualquer item de trabalho que precisa ser rastreado em uma sprint ou que necessita ser feita no projeto
-- Para criar ou modificar novas funcionalidades, jornadas, ações de usuário e outras modificações dentro do projeto
-
-## Pré-requisitos
-- Entendimento claro do trabalho a ser feito. Leia a PRD, épicos, histórias criadas anteriormente para entender o contexto a ser feito.
-- Entenda também últimos commits do projeto e outras alterações que possam ter sido feitas em sessões anteriores
-- Se não houver uma PRD ou épico relacionado, sugira para o usuário a criação do épico ou da PRD, mas é totalmente opcional
-- Referências de design (para histórias de usuário)
-- Quaisquer restrições técnicas ou requisitos relevantes
-
-## Resultado Final
-- Siga a estrutura exata do template `$PROD_TEMPLATES/prod-issue-template.md`
-- Convenção de nomenclatura: `{issue_type}-{id}-{issue_name}.md` (ex: story-123-fluxo-lembrar-senha.md)
-- O idioma do arquivo deve corresponder ao idioma de interação do usuário
-- Se o usuário não tiver um título claro, crie um título baseado no conteúdo do arquivo e no contexto do épico
-- Uma História ou Task pode ou não ter subtasks. Sugira as subtasks que são as menores partes da issue para guiar o PM ou o Dev na criação dessas histórias ou tasks.
-- Se o usuário pedir para salvar no `$TASK_MANAGER`, leia `TASK_MANAGER`, `TOKEN_TASK_MANAGER` e `TASK_MANAGER_URL_BASE` no ENV.md e use `eng-task-comment` / adapter do vendor (jira | linear | github | asana).
-  - Se `TASK_MANAGER` estiver vazio (freelance) ou faltar token/URL, **não invente board** — pergunte as informações necessárias ou salve só o markdown local.
-
-## Estrutura da Issue
-
-### 1. Título e Metadados
-- **Título**: Título claro e orientado à ação (ex: "Implementar Formulário de Login do Usuário")
-- **PRD Relacionada**: Link para a PRD pai, se aplicável
-- **Épico Relacionado**: Link para o épico pai, se aplicável
-- **Tipo**: História/Tarefa/Bug
-- **Prioridade**: Alta/Média/Baixa
-
-### 2. Contexto
-
-Deve descrever o contexto do problema ou funcionalidade a ser implementada:
-- Informações de contexto
-- Valor de negócio
-- Como se encaixa no panorama maior
-- Qualquer pesquisa de usuário ou dados relevantes
-
-Para resumir a ação final que deve ser feita, use o formato abaixo:
-```
-**Como** [papel do usuário]  
-**Eu quero** [objetivo]  
-**Para que** [benefício/valor]
-```
-
-#### Assets de Design
-- Links para mockups/wireframes
-- Referências do design system
-- Links de protótipos
-
-Se usuário não tiver fornecido os links ou os assets de design, questione se podemos avançar sem eles. Se ele aprover, continue. Se ele entregar os assets, liste-os no template. Se ele enviar imagens, utilize-as como referência, entendendo os principais pontos e fluxos descritos no design.
-
-### 3. Critérios de Aceitação
-- Siga o formato do template
-- Agrupe critérios relacionados sob subtítulos claros
-- Inclua todos os cenários possíveis e casos extremos
-- Seja específico sobre elementos de UI e comportamento
-- Inclua estados de erro e validações
-
-Exemplo:
-```
-#### Fluxo de Autenticação
-- Quando o usuário clicar no botão "Login" na página inicial, o sistema exibe modal de login
-- Quando o usuário inserir formato de email inválido, o sistema exibe mensagem de erro abaixo do campo
-- Quando a autenticação falhar, o sistema mostra mensagem de erro específica
-- Após login bem-sucedido, o sistema redireciona para o dashboard do usuário
-```
-
-### 4. Requisitos Técnicos
-Nesse bloco, você deve ser explicito sobre como serão organizados os requisitos técnicos e defuncionamento. Utilize FRD para descrever os requisitos técnicos.
-- Orientações de implementação (sugestões, não requisitos)
-- Considerações de performance
-- Requisitos de segurança
-- Requisitos de dados
-- Dependências
-
-### 5. Casos Extremos e Tratamento de Erros
-- Liste potenciais casos extremos
-- Defina como o sistema deve lidar com cada caso
-- Inclua mensagens de erro amigáveis ao usuário
-
-### 6. Fora do Escopo
-- Declare claramente o que não está incluído
-- Referencie melhorias futuras se necessário
-
-## Melhores Práticas
-
-### Para Histórias de Usuário
-- Foque nas necessidades do usuário, não na implementação
-- Deixe as histórias descritivas para que agentes de IA possam construir as features corretas
-- Torne-as independentes e negociáveis. As histórias devem entregar valor para o usuário ou para o produto en suas entregas.
-- Elas devem ser o menor tamanho possível para entregar rápido e com qualidade, mas não pode ser tão pequena que não entrega valor percebido para o usuário ou para o produto.
-- Garanta que sejam valiosas para os usuários
-
-### Para Tarefas
-- Seja específico sobre o que precisa ser feito
-- Inclua critérios de sucesso
-- Anote quaisquer dependências
-- Estime o esforço se possível
-- Torne-as independentes e negociáveis
-- Elas devem ser o menor tamanho possível para entregar rápido e com qualidade, mas não pode ser tão pequena que não entrega valor percebido para o usuário ou para o produto.
-
-### Para Bugs
-- Inclua passos para reproduzir
-- Peça para o usuário se ele tem evidências como vídeos ou imagens para adicionar na história. Se ele enviar, coloque o link no arquivo final, e salve os arquivos em `<project-path>/docs/master-docs/assets/`
-- Documente comportamento esperado vs. real
-- Pergunte detalhes do ambiente, erros no console, mensagens de erro do próprio produto
-- Solicite informações de identificação do cliente, o fluxo que ele seguiu para reproduzir o erro, e quaisquer outros detalhes que possam ajudar a reproduzir o erro
-
-## Armadilhas Comuns
-- Critérios de aceitação vagos ou incompletos
-- Casos extremos faltando
-- Descrições excessivamente técnicas
-- Falta de critérios claros de sucesso
-- Não vincular ao trabalho relacionado
-
-## Pontos de Integração
-- **PRDs**: Devemos atualizar a PRD com as modificações feitas nas FRDs, sem abordar o micro, mas alterações de alto nível.
-- **FRDs**: Devemos atualizar a FRD com as modificações feitas nas issues, sem abordar o micro, mas alterações de alto nível.
-- **Épicos**: Issues como Histórias ou Tasks devem se encaixar no escopo do épico
-- **Código**: Devem referenciar ID da issue nos commits

package/skills/prod-specs/references/prod.spec.prd.md

@@ -1,118 +0,0 @@
----
-name: prod.spec.prd
-description: Instruções para alterar ou criar um especificação de produto PRD - Product Requirement Document seguindo o template e as melhores prática de mercado, de forma que possa ser utilizado e expandido por agentes de IA e humanos.
-auto_execution_mode: 3
-env_file: "@/ENV.md"
-allowed-tools: Read, Grep
-recommended_model: claude-sonnet-4-20250514
-model_tier: high
-model_justification: PRDs requerem análise profunda de requisitos, estruturação de documentos complexos e compreensão de contexto de negócio
----
-
-# PRD - Product Requirement Document
-
-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 iniciar uma nova especificação de PRD (Product Requirment Document)
-- Precisar modificar um PRD existente
-- Quando documentação abrangente é necessária
-- Como fonte única de verdade para o desenvolvimento do produto e base para derivar histórias e tarefas
-
-## Princípios Fundamentais
-1. **Sempre use o template** desta skill localizado em `$SKILL_TEMPLATE_FOLDER/prod-prd-template.md` dessa skill para o output final
-2. **Nunca crie o arquivo final com suposições não validadas** — sempre confirme sugestões primeiro
-3. **Seja inteligente, não robótico** — analise o contexto e proponha sugestões inteligentes, não faça perguntas vazias
-
----
-
-## Fluxo de Trabalho
-
-O fluxo é dividido em checkpoints obrigatórios (gates). Você NÃO DEVE avançar para o próximo gate até que o usuário aprove explicitamente o atual. NUNCA gere o arquivo final até que TODOS os gates sejam aprovados.
-
-Não busque validação de tudo de uma vez; valide os gates de forma incremental.
-
-### Gate 1: Reconhecer e esclarecer
-- Reconheça o que o usuário forneceu (liste o que foi recebido).
-- Identifique o que foi fornecido explicitamente vs. o que está faltando
-- Evite fazer novas buscas ou leitura de arquivos se você já recebeu informações suficientes para prosseguir. Caso contrário, peça mais informações para o usuário. Diga exatamente o que você precisa para preencher o template completamente.
-- Faça 2–3 perguntas estratégicas sobre: clareza do problema, limites de escopo, restrições técnicas
-- **PARE e aguarde a resposta do usuário antes de prosseguir**
-
-### Gate 2: Sugerir conteúdo para seções ausentes
-- Para CADA seção do template que o usuário NÃO forneceu conteúdo explicitamente, apresente suas sugestões com justificativa. Se o usuário pular, não coloque o bloco no output final.
-- Agrupe sugestões relacionadas (ex.: todos os indicadores de sucesso juntos, todas as evoluções futuras juntas)
-- Formato: "Para [Nome da Seção], sugiro: [conteúdo]. Justificativa: [por quê]. Devo incluir, modificar ou remover?"
-- Seções que DEVEM ser validadas se não fornecidas pelo usuário: TL;DR, Contexto, Definição do Problema, Indicadores de Sucesso, O que esta Iniciativa Não É, Evoluções Futuras, Fora do Escopo
-- **PARE e aguarde o usuário aprovar, modificar ou rejeitar CADA grupo de sugestões antes de prosseguir**
-
-### Gate 3: Confirmar lista de FRDs
-O FRD representa funcionalidades e características do produto/solução. Não são tarefas, histórias ou micro ações dentro da funcionalidade. O FRD decompõe o PRD em soluções de médio porte que, juntas, formam a solução final.
-
-- Utilize primariamente a lista de FRDs que o usuário deve ter fornecido. 
-- Se usuário não forneceu qualquer tipo de FRD, apresente uma lista sugestiva a partir das informações do projeto que você tem até agora e use práticas e seu conhecimento de mercado para sugerir uma lista completa de FRDs que podem ser concluídos, com ID, nome e uma descrição em uma linha
-- Separe claramente: FRDs baseados no input do usuário vs. FRDs que você está sugerindo
-- **PARE e aguarde a confirmação do usuário antes de prosseguir**
-
-### Gate 4: Gerar output final
-- Se está modificando um PRD existente, apenas atualize as seções que foram alteradas ou adicionadas ou especificadas pelo usuário. Não modifique o arquivo sem pedido explicito do usuário.
-- Somente após os Gates 1–3 aprovados, gere o output final usando o template localizado em `$SKILL_TEMPLATE_FOLDER/prod-prd-template.md`
-- O output final deve conter APENAS: conteúdo fornecido pelo usuário + sugestões aprovadas pelo usuário, seguindo o template
-- Se uma seção não tiver conteúdo fornecido ou aprovado, deixe em branco com um marcador TODO e informe o usuário
-- Antes de disponibilizar o output final, valide se está seguindo todos os padrões estabelecidos no template
-- Disponibilize o output final como artefato para o usuário ou para o Agente AI utilizado, conforme a necessidade
-
----
-
-## Abordagens por Contexto
-
-**Contexto rico** (documento/requisitos detalhados fornecidos):
-- Analise o que está completo vs. o que está faltando
-- Sugira complementos com raciocínio: "Com base em X, sugiro Y porque Z. Está correto?"
-- Agrupe sugestões relacionadas (ex.: todos os indicadores de sucesso juntos)
-
-**Contexto mínimo** (apenas uma ideia):
-- Faça perguntas direcionadas para o TL;DR (O QUÊ / POR QUÊ / COMO)
-- Infira contexto adicional e valide: "A partir das suas respostas, infiro X. Devo incluir isso?"
-
-**Projeto existente**:
-- Leia o código-fonte, documentos e commits recentes primeiro
-- Sugira o TL;DR com base na análise para confirmação
-
-**Funcionalidades mencionadas**:
-- Sugira a lista de FRDs e confirme antes de incluir
-
----
-
-## Padrões de Qualidade
-
-✅ **Boa sugestão**: Contextual, específica, demonstra entendimento do domínio
-```
-Com base em ser um plugin de sincronização para criadores, sugiro:
-- Confiabilidade de Sincronização: taxa de sucesso de 99,5%
-- Tempo Economizado: redução de 15 min/publicação
-- Adoção: 70% usando 3+ vezes/semana após 30 dias
-
-Esses indicadores estão alinhados com "eliminar o atrito da sincronização manual." Posso usá-los?
-```
-
-❌ **Má sugestão**: Genérica, sem raciocínio
-```
-Quais métricas? A) Engajamento B) Receita C) Outro
-```
-
----
-
-## Evite
-- Perguntas vazias sem sugestões quando há contexto disponível
-- Perguntar sobre cada pequeno detalhe separadamente
-- Sugestões genéricas que se aplicam a qualquer produto
-- Inventar pesquisas de usuário, dados de concorrentes ou restrições técnicas
-- Criar o documento final antes de o usuário validar as suposições
-- Usar frases e termos como:
-  - "Vamos construir uma solução", "Vamos criar", "Vamos planejar"
-  - Os PRDs descrevem o produto como se ele já existisse, não como se fosse ser construído no futuro
-  - Em vez disso, use: "Esta é uma solução", "Nossa solução", "Nossa abordagem", "Este produto", "Esta funcionalidade"

package/skills/prod-specs/templates/prod-prd-full-template.md

@@ -1,159 +0,0 @@
----
-name: [Nome]  
-version: [X.Y.Z]
-created_at: [YYYY-MM-DD]
-updated_at: [YYYY-MM-DD]
-link_task: [URL referêncial do $TASK_MANAGER]
----
-
-
-# [Nome do PRD]
-
-## TL:DR;
-
-- **O que** resolver: 
-  - [Descreva no mínimo 2 bullet points qual o problema queremos resolver? O que está nos motivando/estimulando a criar uma solução? Quais as dores que o usuário tem sentido?]
-- **Por que** resolver: 
-  - [Descreva no mínimo 2 bullet points quais as razões pelas quais queremos resolver ou explorar; marcadores. Escreva no máximo 3 bullet points. Se o usuário enviar informações, use-as.]
-- **Como** resolver: 
-  - [Descreva no mínimo 2 bullet points as descrições da solução ou hipóteses que iremos construir. Se o usuário não deixou claro, pergunte.]
-
-## Contexto
-
-[Descrição detalhada do contexto divididos em 3-4 parágrafos que somados devem ter um total máximo de 250 palavras, respondendo: Qual o problema que iremos resolver ou a oportunidade que iremos explorar? O que está acontecendo hoje? Que dor existe? Por que isso é importante para o usuário e quais os impactos benéficos para o negócio? Você pode expandir e usar as informações da TL:DR, mas sempre pergunte ao usuário caso não houver informações suficientes. Procure na web casos parecidos para criar uma resposta mais correta e completa.]
-
-### Declaração dos problemas
-[Use o formato abaixo para listar os problemas que queremos resolver. Utilize as informações do usuário para sugerir problemas comuns que essa solução irá resolver. Foque-se nos problemas que o usuário enfrenta. Sugira a partir de pesquisas na web por casos reais e também utilize informações já feitas no próprio projeto.]
-
-```
-- Clientes não conseguem fazer seus pagamentos de maneira eficaz
-- Ainda temos processos manuais em fluxos altamente sensíveis
-- Usuário não tem feedback imediato sobre conclusão ou erro do pagamento via plataforma
-```
-
-
-## Solução
-[Visão geral de 2 a 3 parágrafos respondendo: O que estamos construindo? Por que? Para quem? Impacto esperado? Você pode expandir as informações do TLDR;]
-
-[Descreva qual é a solução e por que é a melhor solução. Qual é o custo de oportunidade de não fazer isso? A descrição da nossa solução e como ela ajudará o usuário a resolver o problema e a empresa a explorar esta oportunidade.]
-
-### Funcionalidades chave
-
-```
-#### Suportar múltiplos métodos de pagamento
-- Pagamento com criptomoedas: permite que usuários paguem utilizando criptmoedas como Bitcoin, ETH e outras
-- Integração com cartão de crédito via gateways: para facilitar a integração e pagamento feito com cartão na plataforma, sem a necessidade de ter regulações oficiais.
-- Suporte com carteiras digitais como Apple Pay e Google Pay: facilitando a adoção de usuários sem a necessidade de cadastro de novas informações na plataforma.
-- Pagamento via PIX: facilitando a adoção com pagamentos utilizando código copia/cola e QR Code; 
-
-#### Prevenção a fraude
-- Detecção de fraudes via machine learning: automatizando ao máximo a detecção de possíveis compras fraudulentas e prevenindo lavagem de dinheiro.
-- Assessment de risco em tempo real: com fallback para a mesa de operações quando validação automática falhar.
-
-#### Pagamento via plataforma
-- Pagamento utilizando saldo: clientes fazem recarga de saldo na plataforma para fazer pagamentos diretamente na plataforma
-- Agendamento de pagamentos: usuário agendar pagamentos via plataforma para que sejam executados automaticamente em dia específico
-- URL aberta para um terceiro pagar: cliente poderá compartilhar a págian de pagamento com os valores a serem pagos para outras pessoas efetuarem o pagamento.
-```
-
-## Critérios Gerais
-[Siga o padrão que está abaixo. Lembre-se que os critérios em uma PRD devem ser descrições de alto nível, de regras de funcionamento e enfatizando as regras de negócio. Definir o que e não o como. ]
-
-```
-### CRT-1: [nome do cenário]
-- Usuário pode filtrar resultados da pesquisa por faixa de preço
-- Deve ter possibilidade de login via redes sociais
-- O sistema deve processar e exibir atualizações de localização com latência máxima de 30 segundos para 95% das requisições, mesmo com 1000+ veículos simultâneos
-- Todos os dados sensíveis devem ser criptografados em repouso e em trânsito, seguindo conformidade com LGPD e GDPR
-- Todas as funcionalidades devem passar por revisão de segurança automatizada e validação manual das 10 vulnerabilidades OWASP mais frequentes.
-
-### CRT-2: [nome do cenário]
-
-- Arquivos enviados devem permitir os formatos MP3, WAV e MPG4, com tamanho máximo de 100MB
-- O usuário pode ouvir o áudio enviado antes de confirmar o envio, e arquivos corrompidos ou fora do padrão devem gerar alerta e impedir o envio
-- Todos os dados sensíveis devem ser criptografados em repouso e em trânsito, seguindo conformidade com LGPD e GDPR.
-- O produto deve ser integrado de forma bidirecional com os sistemas externos aprovados, passando nos cenários de teste de integração.
-
-### CRT-3: [nome do cenário]
-
-- Campo de busca deve sugerir resultados em tempo real com tolerância a erros de digitação
-- Resultados da busca devem ser apresentados em até 1 segundo e exibidos em páginas paginadas.
-- Histórico de ações realizadas pelo usuário deve ser registrado e disponível mediante consulta no painel administrativo.
-
-### CRT-4: [nome do cenário]
-- Usuário deve conseguir redefinir senha com validação via e-mail em menos de 5 minutos
-- Sistema deve bloquear a conta após cinco tentativas de login mal-sucedidas e registrar o evento para consulta posterior.
-```
-
-
-## Indicadores de Sucesso
-[Sugira e pergunte para o usuário quais indicadores que devem ser monitorados para entendermos o sucesso.]
-
-```
-- Aumentar sucesso de pagamento em 21%
-- Reduzir perdas por fraude em 25%
-- Melhorar satisfação do cliente em 30%
-- Manter uptime de plataform em 99%
-```
-
-
-## Escopo
-
-### Dentro do Escopo
-✅ [Item 1]  
-✅ [Item 2]  
-✅ [Item 3]
-
-### Fora do escopo
-❌ [Item 1]  
-❌ [Item 2]  
-❌ [Item 3]
-
-### Evoluções futuras
-🔮 [Item 1]  
-🔮 [Item 2]
-
-## Artefatos e documentações
-- [Link file 1]
-- [Link file 2]
-
-## Competidores
-
-[Descrição de soluções já utilizadas no mercado pelos usuários. Crie seções com cada um dos competidores, descrevendo suas principais features e contextos. Siga o padrão abaixo:]
-
-```
-### Nome do Competidor 1
-
-[Nome do Competidor 1](URL do site)
-
-- Breve descrição (segmento, localização, data de fundação)
-- Tamanho da empresa: número de funcionários, presença geográfica, faturamento estimado (se público)
-- Histórico relevante e diferenciais
-
-#### Principais features
-- Lista das principais funcionalidades ou produtos oferecidos
-- Características essenciais (preço, usabilidade, benefícios, diferenciais técnicos)
-- Estrutura de suporte e atendimento ao cliente (se aplicável)
-
-#### Economics / Base de usuários
-
-- Faturamento anual, margem de lucro ou dados financeiros relevantes (se públicos)
-- Número de usuários/clientes ativos (caso disponível)
-- Participação de mercado relativa
-- Crescimento recente ou taxa de aquisição de novos clientes, se possível
-
-```
-
-## Restrições, Suposições e Riscos
-[Pergunte para o usuário se existem alguma restrição de negócio, técnico ou de produto que possa dificultar a construção ou que precisa ser discutido com áreas ou stakeholders.]
-
-[Escreva aqui as principais suposições e hipóteses sobre esse projeto. Utilize informações fornecidas pelo usuário, caso contrário, pergunte para ele nessa etapa.]
-
-### Restrições de Negócio
-[Bullet points com as restrições de negócio mapeadas e fornecidas pelo usuário. Se não tiver essa informação, pergunte para o usuário.]
-
-### Restrições técnicas
-[Bullet points com as restrições técnicas mapeadas e fornecidas pelo usuário. Se não tiver essa informação, pergunte para o usuário.]
-
-### Riscos e mitigações
-[Seções o título do tópico e sua detalhes expandidos sobre os riscos que podem existir sobre essa iniciativa e como elas são mitigadas.]