jarvis-ai-framework 1.0.0

package/skills/prod-specs/templates/prod-frd-template.md

@@ -0,0 +1,172 @@
+---
+id: {FRD-001}
+name: {nome desse frd}
+version: {X.Y.Z - atualizar sempre que houver alteração}
+status: {$ITEM_STATUS}
+last_editor: {nome de quem editou por último}
+updated_at: {YYYY-MM-DD}
+related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+created_at: {YYYY-MM-DD}
+created_by: {nome de quem criou esse doc}
+---
+
+# {id}: {name}
+
+## TL;DR
+
+- **O que** resolver: 
+  - {Declaração do problema 1: Qual é a questão central?}
+  - {Declaração do problema 2: Quais são as dores existentes?}
+  - {Declaração do problema 3: Qual oportunidade estamos abordando?}
+- **Por que** resolver: 
+  - {Impacto no negócio 1: Como isso beneficia o negócio?}
+  - {Benefício do usuário 1: Como isso ajuda os usuários?}
+  - {Valor estratégico: Por que isso é importante agora?}
+- **Como** resolver: 
+  - {Abordagem da solução 1: Conceito de alto nível da solução}
+  - {Abordagem da solução 2: Principais funcionalidades/componentes}
+  - {Diferencial: O que torna esta solução única?}
+
+## Introdução e contexto
+{Este FRD descreve as especificações de requisitos de funcionamento para a funcionalidade {Nome da Funcionalidade}. Tem como objetivo orientar as equipes de desenvolvimento no processo de criação de um recurso que atenda aos padrões planejados para a entrega e às expectativas dos usuários.}
+
+{Forneça 2-3 parágrafos (máx. 350 palavras) cobrindo:
+1. Situação atual e pontos de dor
+2. Perspectiva e necessidades do usuário
+3. Impacto esperado e métricas de sucesso relacionado a essa funcionalidade
+
+Lembre-se de que esse FRD será utilizada tanto por humanos quanto para formação de contexto de agentes de IA que irão programar ou auxiliar na criação do código.}
+
+## Jornada do Usuário
+
+{Usuário interage com o sistema através de uma sequência de ações que levam à conclusão da tarefa principal. Descreva aqui os passos principais da jornada do usuário, incluindo pontos de entrada, interações e pontos de decisão. Faça isso se baseando no fluxo desenhado aos artefatos do design, utilizando os arquivos necessários, ou pelos inputs do usuário. Se ele não fornecer, não assuma, pergunte ao usuário para que possamos criar uma jornada completa e precisa.}
+
+## Features dessa FRD
+
+{Liste no padrão da tabela abaixo, as features que compõem essa FRD. Cada feature deve ser uma funcionalidade específica que será implementada.}
+
+| ID | Status | Título | Descrição |
+|----|--------|--------|-----------|
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+| [feat-{id}](<path/to/feat/file.md>) | {$ITEM_STATUS} | {Nome da feature} | {Descrição da feature} |
+
+## Requisitos e critérios
+
+{Lembre-se que os critérios e requisitos escritos em um FRD e PRD são diferentes. Na FRD devemos ter decrições muito mais detalhadas levando em consideração o comportamento do usuário, com detalhes do fluxo e ações. Na PRD, devemos ter requisitos mais gerais e abstratos. 
+
+Os requisitos, critérios de aceite e ações em um FRD são compostos pelo resultado que teremos a partir do uso das suas features do ponto de vista do usuário e também o comportamento esperado do sistema. Eles servem como base para validar se a implementação está alinhada com as expectativas do negócio e do usuário final, além de servir como contexto para criação de épicos, histórias e tasks:
+
+- Agrupe critérios em blocos claros, relacionados com títulos e subtítulos
+- Inclua todos os cenários possíveis e casos extremos
+- Seja específico sobre elementos de UI e comportamento, trazendo detalhes do fluxo e ações
+- Inclua estados de erro e validações
+- Inclua os critérios técnicos junto dos requisitos, como tecnologias, endpoints, tabelas, etc. Se você não tiver essa informação, pergunte para o usuário:
+  - Você quer colocar informações de critérios técnicos agora, ou prefere fazer posteriormente?
+  - Se a resposta do usuário for fazer depois, continue inserindo apenas informações de requisitos e critérios de aceite, comportamentos do usuário e fluxos de produto.
+  - Se o usuário inserir informações de critérios técnicos, utilize-as, colocando-os junto ao bullet point do requisito.
+
+Siga a estrutura abaixo para descrever os requisitos e critérios de aceite na estrutura abaixo:}
+
+### RQT-1: Fluxo de autenticação
+- Quando o usuário clica no botão "Login" na página inicial, o sistema exibe o modal de login
+- Quando o usuário insere o email no campo email, o sistema valida o formato em tempo real
+  - Quando o usuário insere um formato de e-mail inválido, o sistema exibe o erro "Insira um e-mail válido" abaixo do campo
+- Quando o usuário insere a senha e clica em "Entrar", o sistema tenta a autenticação
+  - As informações devem ser verificadas utilizando o endpoint XYZ, que busca na tabela ABC do banco de dados Nome do Banco
+- Quando a autenticação é bem-sucedida, o sistema fecha o modal e redireciona para o painel
+- Quando a autenticação falha, o sistema exibe o erro "Credenciais inválidas" acima do formulário
+- Devemos gravar no banco XYZ de auditoria, as informações de falha ou sucesso de login
+- Quando o usuário clica no link "Esqueci minha senha", o sistema exibe o modo de redefinição de senha
+
+### RQT-2: Fluxo de redefinição de senha
+- Quando o usuário insere o e-mail no formulário de redefinição e clica em "Enviar link de redefinição", o sistema envia o e-mail de redefinição
+- Quando o sistema envia um e-mail, o sistema exibe a confirmação "Verifique seu e-mail para obter o link de redefinição"
+- Quando o usuário não recebe o e-mail em 1 minuto, o sistema mostra o botão "Reenviar e-mail"
+
+## Dependências
+
+{Descreva as dependências que essa FRD tem para funcionar corretamente. Divida em blocos cobrindo:
+- Dependências de outras features do sistema
+- Dados
+- Serviços de API
+- Ferramentas, bibliotecas ou sistemas externos.
+
+Exemplos:
+- Integração com API de pagamento do {NOME DO GATEWAY} para processamento de pagamentos
+- [FRD-001 - Nome do Arquivo da FRD](<link>)
+- Biblioteca de gráficos (versão 3.0+)
+- Serviço de email (endpoint /api/email/send)
+- Feature de autenticação (requer login ativo)
+}
+
+## Requisitos técnicos
+
+{Esse bloco é dedicado a listar as decisões técnicas e arquiteturas que foram tomadas para a construção da funcionalidade. Liste todas as ARDs relacionadas a esse FRD. Se não souber, pergunte ao usuário.
+
+Se não houverem ou o usuário não fornecer, esse bloco não deve ser incluído.}
+
+```
+- {[ARD-001](<path/to/file.md>): Descreva claramente a decisão técnica}
+- {[ARD-002](<path/to/file.md>): Descreva uma segunda decisão técnica}
+- {[ARD-003](<path/to/file.md>): Descreva uma terceira decisão técnica}
+```
+
+## O que essa solução não é
+
+{Descreva em no máximo 150 palavras, o que essa iniciativa não é, o que nós não resolvemos por que isso faz parte de outro escopo de segmentos ou serviços que não nos propomos a trabalhar. Essa declaração é importante para evitar mal-entendidos e delimitar claramente o escopo. Valide com o usuário.
+
+Exemplo:
+Ele é um sistema de gestão de dados pessoais de saúde, que agrega informações de diferentes fontes e permite o usuário gerenciar e visualizar seus dados de saúde de forma centralizada.
+
+- Essa solução não é um sistema de adição de informação de saúde como Apple Health, Google Fit, Fitbit, Garmin e outros. 
+- Não é um sistema de diagnóstico médico
+- Não é um sistema de prescrição médica
+- Não é um sistema de tratamento médico
+- Não controla medicamentos ou tratamentos
+}
+
+#### Fora do escopo do conceito dessa solução
+{Faça essa lista baseada no bloco de O QUE ESSA SOLUÇÃO NÃO É}
+
+- {Exclusão específica}  
+- {Outra exclusão}  
+- {Exclusão adicional}
+
+## Especificações relacionadas
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no `$CENTRAL_DOCS_REPO`. Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+
+**PRDs relacionadas**:
+| ID | Título | Descrição |
+|----|--------|--------|-----------|
+| [PRD-{id}](<path/to/feat/file.md>) | {Nome da PRD} | {Por que é relacionado} |
+| [PRD-{id}](<path/to/feat/file.md>) | {Nome da PRD} | {Por que é relacionado} |
+
+**FRDs relacionadas**:
+| ID | Título | Descrição |
+| [FRD-{id}](<path/to/feat/file.md>) | {Nome da FRD} | {Por que é relacionado} |
+| [FRD-{id}](<path/to/feat/file.md>) | {Nome da FRD} | {Por que é relacionado} |
+
+**ARDs relacionadas**:
+| ID | Título | Descrição |
+| [ARD-{id}](<path/to/feat/file.md>) | {Nome da ARD} | {Por que é relacionado} |
+| [ARD-{id}](<path/to/feat/file.md>) | {Nome da ARD} | {Por que é relacionado} |
+
+
+### Histórias, tasks, Issues relacionadas
+{liste todos os épicos ou issues relacionados a este FRD}
+
+- [EPIC-001 - Nome do Épico](<link>)
+- [ISSUE-001 - Nome da Issue](<link>)
+
+
+## Histórico e Versionamento
+
+| Versão | Data       | Descrição                    | Autor         | 
+|--------|------------|------------------------------|---------------|
+| 1.0.0  | 2025-12-23 | Versão inicial do documento  | Health Team   |
+
+

package/skills/prod-specs/templates/prod-issue-template.md

@@ -0,0 +1,68 @@
+---
+id: {issue_type-001}
+name: {nome dessa issue}
+type: {Story, Task, Bug}
+related_prd: {path PRD relacionado, exemplo /master-docs/product/prd-001.md}
+related_epic: {nome do Epico relacionado, exemplo /master-docs/product/epics/epic-001.md. Se não existir, ignore essa linha}
+related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
+created_at: {YYYY-MM-DD}
+updated_at: {YYYY-MM-DD}
+task_link: {URL referêncial no $TASK_MANAGER - se existir. Se não, ignore essa linha}
+status: {icebox|in_review|in_progress|in_production|deprecated}
+created_by: {nome de quem criou esse doc}
+last_editor: {nome de quem editou por último}
+---
+
+# {id}: {name}
+
+## Contexto
+{Antecedentes: por que esta história é importante, como ela se encaixa no épico, qual é o problema e como isso o resolve, recursos relacionados}
+
+**Como** {tipo de usuário}
+**Eu quero** {capacidade}  
+**Então isso** {benefício/valor entregue}
+
+## Critérios de aceitação
+{Lembre-se da diferença de nível dos critérios de aceitação de um PRD/Epic e Stories/Tasks citados em `SKILL.md`. Abaixo segue o exemplo.}
+
+```
+#### Fluxo de autenticação
+- Quando o usuário clica no botão "Login" na página inicial, o sistema exibe o modal de login
+- Quando o usuário insere o email no campo email, o sistema valida o formato em tempo real
+- Quando o usuário insere um formato de e-mail inválido, o sistema exibe o erro "Insira um e-mail válido" abaixo do campo
+- Quando o usuário insere a senha e clica em "Enviar", o sistema tenta a autenticação
+- Quando a autenticação é bem-sucedida, o sistema fecha o modal e redireciona para o painel
+- Quando a autenticação falha, o sistema exibe o erro "Credenciais inválidas" acima do formulário
+- Quando o usuário clica no link "Esqueci minha senha", o sistema exibe o modo de redefinição de senha
+
+#### Fluxo de redefinição de senha
+- Quando o usuário insere o e-mail no formulário de redefinição e clica em "Enviar link de redefinição", o sistema envia o e-mail de redefinição
+- Quando o sistema envia um e-mail, o sistema exibe a confirmação "Verifique seu e-mail para obter o link de redefinição"
+- Quando o usuário não recebe o e-mail em 1 minuto, o sistema mostra o botão "Reenviar e-mail"
+```
+
+## Requisitos técnicos
+
+- **Orientação de implementação**: {Sugestões, não requisitos}
+- **Requisitos de desempenho**: {Se aplicável}
+- **Considerações de segurança**: {Se aplicável}
+- **Requisitos de dados**: {Se aplicável}
+
+
+## Casos extremos e tratamento de erros
+
+1. **{Caso extremo 1}**: {Como o sistema deve lidar}
+2. **{Caso extremo 2}**: {Como o sistema deve lidar}
+3. **{Cenário de erro}**: {Mensagem de erro e recuperação fáceis de usar}
+
+## Fora do escopo
+
+- {O que esta história NÃO inclui explicitamente}
+- {Recursos adiados para histórias futuras}
+
+
+### Ativos de design
+
+- {Link para modelos/wireframes}
+- {Link para protótipos}
+- {Link para especificações de design}

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

@@ -0,0 +1,159 @@
+---
+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.]

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

@@ -0,0 +1,173 @@
+---
+id: {PRD-001}
+name: {nome desse prd}
+version: {X.Y.Z - atualizar sempre que houver alteração}
+status: {$ITEM_STATUS}
+last_editor: {nome de quem editou por último}
+updated_at: {YYYY-MM-DD}
+related_repo: {URLs de repositórios relacionados, se forem vários, utilize sintaxe compatível com YAML}
+related_prd: {Lista de PRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+related_frd: {Lista de FRDs que são relacionadas a esse PRD, se forem vários, utilize sintaxe compatível com YAML}
+created_at: {YYYY-MM-DD}
+created_by: {nome de quem criou esse doc}
+---
+
+# {id}: {name}
+
+## TL;DR
+
+- **O que** resolver: 
+  - {Declaração do problema 1: Qual é a questão central?}
+  - {Declaração do problema 2: Quais são as dores existentes?}
+  - {Declaração do problema 3: Qual oportunidade estamos abordando?}
+- **Por que** resolver: 
+  - {Impacto no negócio 1: Como isso beneficia o negócio?}
+  - {Benefício do usuário 1: Como isso ajuda os usuários?}
+  - {Valor estratégico: Por que isso é importante agora?}
+- **Como** resolver: 
+  - {Abordagem da solução 1: Conceito de alto nível da solução}
+  - {Abordagem da solução 2: Principais funcionalidades/componentes}
+  - {Diferencial: O que torna esta solução única?}
+
+## Contexto
+
+{Forneça 2-3 parágrafos (total máximo de 200 palavras) cobrindo:
+1. Situação atual e pontos de dor
+2. Impacto comercial de não resolver
+3. Perspectiva e necessidades do usuário
+4. Importância estratégica}
+
+### Declaração do problema ou da oportunidade
+{Escreva 2-3 parágrafos resumindo o problema ou a oportunidade que estamos abordando, do ponto de vista de produto. Depois, liste os 3-6 principais problemas específicos que este PRD aborda. Foque nas dores do usuário e no impacto no negócio.}
+
+- {Questão específica e mensurável: Descreva claramente o problema ou oportunidade que impacta diretamente o usuário}
+- {Outra questão específica: Descreva um segundo problema ou oportunidade que afeta a experiência do usuário}
+- {Terceiro problema chave: Descreva um terceiro problema ou oportunidade que representa um bloqueio significativo}
+
+## Solução
+{Escreva uma frase curta, com impacto, mas sem jargões e outros exageros, de no máximo 280 caractéres, que resuma a solução. Ex.: Construíremos uma solução que [descreva a solução principal em uma frase clara e direta] para [descreva o público-alvo].}
+
+{Visão geral de 2-3 parágrafos com no máximo 200 palavras no total, respondendo: O que estamos construindo? Por quê? Para quem? Impacto esperado? 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.} 
+
+### Listagem das funcionalidades que compõem o escopo da solução
+{Utilize as informações do usuário para criar esse bloco. Se você não tiver informações suficientes, sugira para o usuário algumas funcionalidades a partir do que você conheceu até agora e também de benchmarks do mercado. Só coloque essas informações no output final se o usuário CONFIRMAR explicitamente. Alinhe essa tabela por status, colocando in_prodution em primeiro, depois in_progress, depois backlog, depois in_review. Utilize a variável $ITEM_STATUS para representar o status de cada item. Leia `$PROD_RULES` para saber o que significa status e como utilizá-los.}
+
+| ID | Status | Título | Descrição |
+|----|--------|--------|-----------|
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | {$ITEM_STATUS} | {Nome da FRD} | {Descrição da FRD} |
+
+
+#### Evoluções futuras
+{Coloque uma lista seguindo o formato abaixo, as evoluções que estiverem com o status ICEBOX. Se o usuário adicionar oportunidades de evoluções futuras, insira. Não assuma ou invente nada. Remova dessa lista os itens que não forem ICEBOX. Se não houver nada para listar coloque: __Nenhuma oportunidade de evolução futura identificada.__}
+
+| ID | Status | Título | Descrição |
+|----|--------|--------|-----------|
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | icebox | {Nome da FRD} | {Descrição da FRD} |
+
+
+
+{
+Evite:
+Esses dois pontos poderiam ser unificados, sendo parte de uma funcionalidade única:
+- [FRD-001]: O sistema DEVE permitir que usuários façam upload de documentos médicos (PDFs, imagens) de forma simples e segura
+- [FRD-002]: O sistema DEVE extrair automaticamente dados estruturados de documentos médicos (nome de exames, valores, datas, laboratórios)
+
+Melhor seria:
+- [FRD-001]: Permitir upload de arquivos e documentos médicos, permitindo extração automática de dados estruturados
+}
+
+Cancelados ou descontinuados:
+| ID | Status | Título | Descrição |
+|----|--------|--------|-----------|
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+| [FRD-{id}](<path/to/frd/file.md>) | cancelled | {Nome da FRD} | {Descrição da FRD} |
+
+
+### Resumo de solução técnica
+
+{Use a codebase, README e outras documentações técnicas do projeto para entender as principais decisões técnicas e de arquitetura. Se já houver especificações técnicas no projeto, leia e crie um resumo de 2-3 parágrafos, com no máximo 100 palavras no total. E liste as principais decisões técnicas e de arquitetura no formato abaixo. Se não houver, esse bloco não deve ser incluído.}
+
+- **[ARD-{id}](<path/to/file.md>)**: Descreva claramente a decisão técnica
+- **[ARD-{id}](<path/to/file.md>)**: Descreva uma segunda decisão técnica
+- **[ARD-{id}](<path/to/file.md>)**: Descreva uma terceira decisão técnica
+
+## O que essa solução não é
+
+{Descreva em no máximo 150 palavras, o que essa iniciativa não é, o que nós não resolvemos por que isso faz parte de outro escopo de segmentos ou serviços que não nos propomos a trabalhar. Essa declaração é importante para evitar mal-entendidos e delimitar claramente o escopo. Valide com o usuário.
+
+Exemplo:
+Ele é um sistema de gestão de dados pessoais de saúde, que agrega informações de diferentes fontes e permite o usuário gerenciar e visualizar seus dados de saúde de forma centralizada.
+
+- Essa solução não é um sistema de adição de informação de saúde como Apple Health, Google Fit, Fitbit, Garmin e outros. 
+- Não é um sistema de diagnóstico médico
+- Não é um sistema de prescrição médica
+- Não é um sistema de tratamento médico
+- Não controla medicamentos ou tratamentos
+}
+
+#### Fora do escopo do conceito dessa solução
+{Faça essa lista baseada no bloco de O QUE ESSA SOLUÇÃO NÃO É}
+
+- {Exclusão específica}  
+- {Outra exclusão}  
+- {Exclusão adicional}
+
+
+## Indicadores de Sucesso
+Estes são indicadores que podem ser usados para medir o sucesso dessa solução.
+
+{Se não fornecidos, sugira quais indicadores e métricas de negócio e/ou produto devem ser monitorados para entender o sucesso, e valide com o usuário. Siga o formato abaixo:}
+
+- {Indicador 1: Descreva claramente o indicador de sucesso}
+- {Indicador 2: Descreva um segundo indicador de sucesso}
+- {Indicador 3: Descreva um terceiro indicador de sucesso}
+
+
+## Artefatos e Documentação
+- {Documento 1: Link ou referência ao documento de suporte}
+- {Documento 2: Material de referência adicional}
+
+## Repositórios relacionados
+- {Repositório 1: Link ou referência ao repositório}
+- {Repositório 2: Link ou referência ao repositório}
+
+
+## Especificações relacionadas
+{liste todos os PRDs, FRDs ou outros documentos relacionados a este FRD fazendo uma análise prévia do projeto e das especificações existentes no `$CENTRAL_DOCS_REPO`. Pergunte para o usuário se existe outras relações que ele conheça. Antes de adicionar as sugestões, confirme com o usuário se elas estão corretas.}
+
+**PRDs relacionadas**:
+| ID | Título | Descrição |
+|----|--------|--------|-----------|
+| [PRD-{id}](<path/to/feat/file.md>) | {Nome da PRD} | {Por que é relacionado} |
+| [PRD-{id}](<path/to/feat/file.md>) | {Nome da PRD} | {Por que é relacionado} |
+
+**FRDs relacionadas**:
+| ID | Título | Descrição |
+| [FRD-{id}](<path/to/feat/file.md>) | {Nome da FRD} | {Por que é relacionado} |
+| [FRD-{id}](<path/to/feat/file.md>) | {Nome da FRD} | {Por que é relacionado} |
+
+**ARDs relacionadas**:
+| ID | Título | Descrição |
+| [ARD-{id}](<path/to/feat/file.md>) | {Nome da ARD} | {Por que é relacionado} |
+| [ARD-{id}](<path/to/feat/file.md>) | {Nome da ARD} | {Por que é relacionado} |
+
+
+### Histórias, tasks, Issues relacionadas
+{liste todos os épicos ou issues relacionados a este FRD}
+
+- [EPIC-001 - Nome do Épico](<link>)
+- [ISSUE-001 - Nome da Issue](<link>)