jarvis-ai-framework 1.0.2 → 1.1.0

package/rules/engineering/eng.work-rules.md

@@ -8,7 +8,7 @@ trigger: always_on
 
 ## Propósito
 
-O workflow `work` tem como **único objetivo** implementar código seguindo o plano de execução (`plan.md`). É uma etapa de **codificação pura**, sem commits ou PRs.
+O workflow `work` tem como **único objetivo** implementar código seguindo o plano de execução (`plan.md`). É uma etapa de **codificação**: commita ao final de cada fase validada, mas nunca faz push nem abre PR.
 
 ---
 
@@ -67,19 +67,23 @@ Confirmar que está na branch certa? (s/n)
 
 ## Princípios Fundamentais
 
-### 1. Somente Codificação - NUNCA Commits ou PRs
+### 1. Codificação com commit por fase - NUNCA push ou PR
 
 O `work` é **estritamente proibido** de:
 
 
-| ❌ Proibido                                 | ✅ Permitido                        |
-| ------------------------------------------- | ----------------------------------- |
-| Fazer commits                               | Escrever código                    |
-| Criar Pull Requests                         | Criar/modificar arquivos de código |
-| Executar`git add`, `git commit`, `git push` | Ler arquivos da sessão             |
-| Mover cards no Jira                         | Executar testes locais              |
-| Fazer merge de branches                     | Atualizar`plan.md` com progresso    |
-| Sugerir "vamos fazer o PR agora"            | Validar código com o usuário      |
+| ❌ Proibido                                        | ✅ Permitido                                              |
+| -------------------------------------------------- | --------------------------------------------------------- |
+| Fazer `git push`                                   | Escrever código                                           |
+| Criar Pull Requests                                | Criar/modificar arquivos de código                        |
+| Usar `git add .`                                   | `git add` de arquivos específicos da fase                 |
+| Commitar sem aprovação do usuário na fase          | Commitar ao final da fase validada, com testes passando   |
+| Commitar com testes falhando                       | Executar testes locais                                    |
+| Mover cards no Jira                                | Ler arquivos da sessão                                    |
+| Fazer merge de branches                            | Atualizar `plan.md` com progresso                         |
+| Sugerir "vamos fazer o PR agora"                   | Validar código com o usuário                              |
+
+O commit segue o formato do workflow (`{TASK_MANAGER_KEY} {tipo}({escopo}): {descrição}`, com `Refs:`). Push e PR são responsabilidade do `eng.pr`.
 
 ### 2. Escopo de Atuação
 
@@ -187,7 +191,7 @@ O workflow segue um ciclo rígido:
 
     - Informar que a fase foi concluída
     - Perguntar se deseja iniciar próxima fase
-    - ⚠️ **NUNCA sugerir PR ou commit**
+    - ⚠️ **NUNCA sugerir push ou PR** (são do `eng.pr`)
 
 ---
 
@@ -243,9 +247,9 @@ O workflow **DEVE pausar e aguardar confirmação**:
 
 1. **Escapar para Git**
 
-   - "Vou fazer o commit dessas mudanças..."
    - "Agora podemos criar o PR..."
    - "Deixa eu dar push das alterações..."
+   - `git add .` ou commit com testes falhando
 2. **Pular validação**
 
    - Implementar várias fases sem pausar
@@ -291,7 +295,7 @@ Ao finalizar **TODAS as fases** do `plan.md`, informe:
 2. Execute os testes completos
 3. Quando estiver pronto, use `eng.pr` para criar o Pull Request
 
-⚠️ Este workflow NÃO faz commits ou PRs.
+⚠️ Este workflow commita por fase, mas NÃO faz push nem PR.
    Use `eng.pr` quando estiver pronto para submeter.
 ```
 
@@ -307,6 +311,7 @@ Antes de considerar uma fase completa:
 - [ ]  Usuário validou o código
 - [ ]  `plan.md` atualizado com status
 - [ ]  Comentários adicionados no plan.md
-- [ ]  NENHUM commit foi feito
+- [ ]  Commit da fase feito (arquivos adicionados um a um, testes passando)
+- [ ]  NENHUM push foi feito
 - [ ]  NENHUM PR foi criado
 - [ ]  Próximos passos comunicados

package/rules/product/README.md

@@ -12,6 +12,7 @@ Documentação didática (termos por extenso, exemplos, quando usar cada comando
 |---------|--------|
 | Guia de decisão (qual spec?) | [prod.spec.guide.md](../../docs/produto/prod.spec.guide.md) |
 | `/prod.spec` | [prod.spec.md](../../docs/produto/prod.spec.md) |
+| `/prod.spec.discovery` | [prod.spec.discovery.md](../../docs/produto/prod.spec.discovery.md) |
 | `/prod.spec.prd` | [prod.spec.prd.md](../../docs/produto/prod.spec.prd.md) |
 | `/prod.spec.frd` | [prod.spec.frd.md](../../docs/produto/prod.spec.frd.md) |
 | `/prod.spec.breakdown` | [prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md) |
@@ -22,3 +23,4 @@ Documentação didática (termos por extenso, exemplos, quando usar cada comando
 ## Arquivo normativo (agentes)
 
 - [`prod-rules.md`](./prod-rules.md) — ENV, pastas, status, convenção de nomes, formato de perguntas
+- [`prod.spec-rules.md`](./prod.spec-rules.md) — princípios de escrita de spec: critérios de aceitação por tipo de documento, contexto completo e terminologia consistente

package/rules/product/prod-rules.md

@@ -42,7 +42,7 @@ Se o arquivo não existir ou no caso de recusa, crie o `$IDE/ENV.md` incluindo a
 RULES_FOLDER=.$IDE/rules
 PROD_FOLDER_NAME=product
 PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
-PROD_FLOWS=.$IDE/$FLOWS_FOLDER/$PROD_FOLDER_NAME
+PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
 CENTRAL_DOCS_REPO=[USER:LOCAL_CENTRAL_DOCS_REPO]
@@ -95,6 +95,7 @@ Abaixo, segue uma descrição de algumas das variáveis mais importantes para as
 Sempre siga as instruções de acordo com as relações abaixo.  
 **Guia para humanos (desenvolvedores aprendendo produto):** `docs/produto/` — uma página por comando, termos por extenso.
 
+- `$PROD_FLOWS/prod.spec.discovery.md` — Investigação inicial de uma ideia (rascunho estruturado; não define tarefas) → [docs/produto/prod.spec.discovery.md](../../docs/produto/prod.spec.discovery.md)
 - `$PROD_FLOWS/prod.spec.prd.md` — Documento de Requisitos de Produto (*Product Requirements Document*) → [docs/produto/prod.spec.prd.md](../../docs/produto/prod.spec.prd.md)
 - `$PROD_FLOWS/prod.spec.frd.md` — Documento de Requisitos Funcionais (*Functional Requirements Document*) → [docs/produto/prod.spec.frd.md](../../docs/produto/prod.spec.frd.md)
 - `$PROD_FLOWS/prod.spec.breakdown.md` — Quebra de especificação grande em fatias → [docs/produto/prod.spec.breakdown.md](../../docs/produto/prod.spec.breakdown.md)
@@ -129,6 +130,7 @@ Dentro das pastas do projeto, os caminhos de pastas e o nome dos arquivos finais
 - Documento de Requisitos Funcionais: `$PROD_DOCS/prd-{id}-{nome-do-pai}/frd-{id}-{nome}.md`
 - Épico: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/epic-{id}-{nome}.md`
 - História / tarefa: `$PROD_DOCS/prd-{id}-{nome-do-pai}/issues/{story|task}-{id}-{nome}.md`
+- Discovery (rascunho de uma ideia, anterior ao PRD): `$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`. Usa `status` (`in_review` enquanto o rascunho existe; `cancelled` se o veredito for não seguir) e `verdict` (vazio durante a entrevista, `proceed`, `investigate_more` ou `do_not_proceed`). O veredito é uma recomendação; um PRD, FRD, épico ou issue criado depois prevalece como fonte da verdade.
 
 O ID deve ser iterado nos novos arquivos seguindo a sequência existente.
 

package/{skills/prod-specs/rules/prod-spec-rules.md → rules/product/prod.spec-rules.md}

@@ -2,75 +2,39 @@
 trigger: always_on
 ---
 
-## Principais Regras
-- O idioma padrão é o português do Brasil. Mas mude caso o usuário solicite outro idioma.
-- Sempre procure por arquivos de configuração e documentação do projeto antes de executar qualquer comando ou workflow.
-- Leia o `README.md` do projeto para saber contexto e detalhes importantes.
-- Nunca invente ou presuma dados ou informações. Se não souber, pergunte, valide e confirme com o usuário.
-- Entenda se o projeto é novo ou existente, para criar ou modificar especificações de produto ou técnicas.
-- Identifique se o produto é versionado com git e leia o histórico de commits para entender as últimas atualizações.
+> **Applies to:** HUB: all | POSITION: all | AREA: PRODUCT | SQUAD: all
 
+# Regras de Escrita de Especificação de Produto
 
-## Diretórios e Variáveis dessa Skill
+## Objetivo
 
-Utilize essas variáveis para interpretar corretamente o contexto as instruções dessa skill. Os endereços são relativos ao diretório raiz desse plugin:
+Definir os princípios que todo documento de especificação de produto (PRD, FRD, épico, história, tarefa e bug) deve seguir: o nível certo de critérios de aceitação em cada tipo de documento, contexto completo, terminologia consistente e o uso opcional de um discovery como insumo.
 
-**Diretório da skill:** `${CLAUDE_SKILL_DIR}`
+## Escopo
 
-- `$SKILL_TEMPLATE_FOLDER`: `${CLAUDE_SKILL_DIR}/templates/`
-- `$SKILL_REFERENCES_FOLDER`: `${CLAUDE_SKILL_DIR}/references/`
+Aplica-se a todos os comandos `prod.spec.*` que escrevem ou alteram um documento. Complementa o `prod-rules.md` (variáveis de ambiente, comandos, nomes de arquivos, status e perguntas ao usuário), que continua sendo a regra geral de produto.
 
+## Regras
 
-## Perguntas para guiar o usuário
+### Princípio: Critérios de aceitação e requisitos
 
-Para fazer perguntas ao usuário:
-1. Tente usar o tool `AskUserQuestion` se ele estiver disponível no seu ambiente (ex: Claude Desktop, Claude Cowork, Claude Code CLI).
-2. Se não estiver disponível, use **obrigatoriamente** (se possível) o formato de tabela abaixo. Caso não possível no formato de tabela, faça perguntas em texto corrido.
-3. Nunca avance sem coletar as respostas necessárias.
+#### Critérios de aceitação específicos do documento
 
-```
-|     | {Aqui fica a pergunta que você deve fazer para o usuário. Seja objetivo e direto ao ponto:} |
-| --- | ----------------------------------------------------------------------------------------- |
-| A   | {Resposta 1}                                                                                |
-| B   | {Resposta 2}                                                                                |
-| C   | {Resposta 3}                                                                                |
-| D   | {Resposta 4}                                                                                |
-```
-
-**NUNCA** pergunte tudo de uma vez, sempre faça perguntas separadas e aguarde a resposta antes de prosseguir.
-
-
-## Descrição dos Status
-
-Em itens e especificações, utilizamos status para identificar quais etapas do desenvolvimento cada item está. Isso é representado pela variável `$ITEM_STATUS`. 
-
-- icebox: Lista de ideias, necessidades e desejos. Item que está aguardando priorização ou definição de escopo.
-- in_review: Item que está sendo estudado, descoberto, revisado ou analisado.
-- backlog: Item já foi estudado, sabemos o que fazer e está aguardando priorização de implementação.
-- in_progress: Item que está em desenvolvimento.
-- in_production: Item que está em produção.
-- cancelled: Item que foi descontinuado ou cancelado.
-
-
-## Princípio: Critérios de aceitação e requisitos
-
-### Critérios de aceitação específicos do documento
-
-#### Para PRDs (nível macro)
+##### Para PRDs (nível macro)
 Concentre-se no "o quê" e no "porquê":
 - Definir capacidades gerais do produto
 - Definir regras e restrições de negócios
 - Estabelecer métricas de sucesso
 - Descrições sempre levando em consideração as soluções macro do Projeto, baseando-se nas FRDs
 
-#### Para FRDs (nível médio)
+##### Para FRDs (nível médio)
 Retrata as soluções macro do produto. É ponte entre estratégia e implementação:
 - Definir requisitos de nível de recurso
 - Definir limites para histórias relacionadas
 - Incluir pontos de integração
 - Definir requisitos não funcionais
 
-### Para histórias (detalhadas, funcionais)
+#### Para histórias (detalhadas, funcionais)
 
 Concentre-se em comportamentos específicos e testáveis com base em designs:
 
@@ -104,7 +68,7 @@ Concentre-se em comportamentos específicos e testáveis com base em designs:
 - **Épico**: escopo em nível de recurso e abordagem técnica
 - **Issues (História/Tarefa)**: detalhes específicos de implementação e comportamento da UI
 
-## Princípio: Contexto completo
+### Princípio: Contexto completo
 
 **Princípio**: Cada documento deve ser compreensível por si só, sem exigir conhecimento tribal.
 
@@ -147,7 +111,7 @@ As pessoas juntam-se em equipas, o contexto perde-se, as memórias desaparecem.
 - **Bugs rápidos**: ambiente do documento, etapas, comportamento esperado
 - **Tarefas rápidas**: explique por que esse trabalho é importante
 
-## Princípio: Terminologia Consistente
+### Princípio: Terminologia Consistente
 
 **Princípio**: Use os mesmos termos para os mesmos conceitos em toda a documentação.
 
@@ -184,3 +148,44 @@ A terminologia inconsistente cria confusão. "Cliente" vs "Usuário" vs "Cliente
 - **Planos**: use os termos exatos do PRD
 - **Histórias**: Combine a terminologia do PRD e do Plano
 - **Questões rápidas**: use terminologia estabelecida ou defina novos termos
+
+### Princípio: Discovery como insumo
+
+**Princípio**: O discovery (`$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`) é um rascunho de suposições. Ele pode servir de contexto para um PRD, FRD, épico ou issue, mas nunca é obrigatório e nunca é tratado como verdade.
+
+**O discovery é opcional**:
+- Sem discovery apontado, siga o fluxo do comando normalmente, sem procurar na pasta `discoveries/` e sem perguntar nada sobre discovery. Ter arquivos nessa pasta não tem relação com o comando.
+- Exemplos: `/prod.spec.prd já sei o que quero` segue o fluxo de sempre; `/prod.spec.prd discovery-002` carrega o discovery.
+
+**Como apontar e achar o discovery**:
+- O usuário aponta por caminho, nome ou id (como `discovery-002`); procure em `$PROD_DOCS/discoveries/`.
+- Se o arquivo não existir: informe, liste os discoveries da pasta e pergunte qual usar, ou se o usuário prefere seguir sem discovery.
+- Se a pasta `discoveries/` não existir: siga sem discovery e não crie a pasta.
+- Se mais de um arquivo casar com o que o usuário apontou: pergunte qual usar, sem escolher sozinho.
+
+**Como usar o discovery**:
+- Leia o discovery como **contexto, não como resposta**: é um rascunho e pode estar defasado.
+- **Questione e repasse tudo com o usuário**, seção por seção: mostre o que está registrado e pergunte se ainda vale ou se mudou.
+- Hipóteses e perguntas em aberto do discovery são perguntadas como tais; o que o comando exige e o discovery não cobre é perguntado normalmente.
+- Nada do discovery entra no documento novo como fato sem o usuário ter passado por aquilo. O que ficar sem validação continua marcado como suposição.
+
+**Avisos conforme a situação do discovery**:
+- `verdict: do_not_proceed` (ou `status: cancelled`): avise que a recomendação foi não seguir, mostre o motivo registrado e só continue com confirmação explícita do usuário.
+- `verdict: investigate_more`, `verdict` vazio ou `status: in_review` (discovery ainda em entrevista): avise que há lacunas críticas, liste as perguntas em aberto e pergunte se o usuário quer retomar o discovery antes ou seguir assumindo o risco.
+- `verdict: proceed`: siga normalmente.
+
+**O documento novo é o oficial**:
+- O PRD, FRD, épico ou issue é a fonte da verdade. O discovery **nunca é alterado** por estes comandos: ele permanece como o registro do momento da investigação.
+- O documento novo referencia o discovery de origem no campo `related_discovery` do frontmatter.
+- Quando a informação do documento novo divergir do discovery, **avise o usuário na conversa** e crie no documento novo a seção **"Divergências"** (somente quando houver), com o que mudou e por quê, em poucas linhas.
+
+## Exceções
+
+Quando o usuário pedir explicitamente outro formato ou nível de detalhe para um documento, registre a decisão no próprio documento e siga o pedido.
+
+## Referências
+
+- `prod-rules.md`: regras gerais de produto (ambiente, comandos, nomes de arquivos, status e perguntas ao usuário)
+- `../../templates/product/`: templates dos documentos
+- `../../workflows/product/`: os comandos `prod.spec.*`
+- `prod.spec.discovery.md` (workflow) e `prod-discovery-template.md`: o comando e o formato do discovery, o rascunho que os comandos acima podem usar como insumo

package/skills/SKILLS-ROADMAP.md

@@ -194,8 +194,8 @@ Skills existentes e planejadas do framework Jarvis.
 ## Skills Criadas — Produto
 
 ### `prod-specs` ✅
-- **Trigger**: criação de PRD/FRD
-- **Escopo**: especificação de produto, requisitos
+- **Trigger**: pedido de especificação de produto (PRD, FRD, épico, história, discovery), inclusive em linguagem natural
+- **Escopo**: skill fina, só porta de entrada: aponta para os workflows `prod.spec.*`, que são a fonte única de cada comando
 - **Status**: `criado`
 
 ### `prod-specs-update` ✅
@@ -203,10 +203,6 @@ Skills existentes e planejadas do framework Jarvis.
 - **Escopo**: revisão e evolução de requisitos
 - **Status**: `criado`
 
-### `product-specs` ✅
-- **Trigger**: especificação de produto (alias)
-- **Status**: `criado`
-
 ### `prod-roadmap-report` ✅
 - **Trigger**: relatório de roadmap de produto
 - **Status**: `criado`

package/skills/init-jarvis/SKILL.md

@@ -719,7 +719,7 @@ ENABLE_CDD=true
 
 PROD_FOLDER_NAME=product
 PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
-PROD_FLOWS=.$IDE/$FLOWS_FOLDER/$PROD_FOLDER_NAME
+PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
 ```

package/skills/prod-specs/SKILL.md

@@ -12,97 +12,33 @@ metadata:
 
 # Product Specs
 
-Antes de iniciar:
-- Leia o arquivo de regras invioláveis em `rules/prod-spec-rules.md`.
+Esta skill é só a **porta de entrada** das especificações de produto: ela **não guarda conteúdo próprio**. Quando o pedido for um dos abaixo, siga o workflow indicado (os arquivos ficam em `$IDE/$FLOWS_FOLDER/`, e os templates em `$PROD_TEMPLATES`).
 
-## Diretórios e Variáveis dessa Skill
+| Pedido | Comando | Workflow |
+|---|---|---|
+| Não sei qual documento criar | `/prod.spec` | `$IDE/$FLOWS_FOLDER/prod.spec.md` |
+| Investigar uma ideia inicial | `/prod.spec.discovery` | `$IDE/$FLOWS_FOLDER/prod.spec.discovery.md` |
+| PRD (Documento de Requisitos de Produto) | `/prod.spec.prd` | `$IDE/$FLOWS_FOLDER/prod.spec.prd.md` |
+| FRD (Documento de Requisitos Funcionais) | `/prod.spec.frd` | `$IDE/$FLOWS_FOLDER/prod.spec.frd.md` |
+| Épico | `/prod.spec.epic` | `$IDE/$FLOWS_FOLDER/prod.spec.epic.md` |
+| História, tarefa ou bug | `/prod.spec.issue` | `$IDE/$FLOWS_FOLDER/prod.spec.issue.md` |
+| Esclarecer uma especificação | `/prod.spec.clarify` | `$IDE/$FLOWS_FOLDER/prod.spec.clarify.md` |
+| Quebrar uma especificação grande | `/prod.spec.breakdown` | `$IDE/$FLOWS_FOLDER/prod.spec.breakdown.md` |
 
-Utilize essas variáveis para interpretar corretamente o contexto as instruções dessa skill. Os endereços são relativos ao diretório raiz desse plugin:
+Antes de executar, leia as regras de produto em `$PROD_RULES` (`prod-rules.md` e `prod.spec-rules.md`).
 
-**Diretório da skill:** `${CLAUDE_SKILL_DIR}`
+Para outras necessidades de produto sem workflow próprio, aplique as boas práticas comumente utilizadas por gerentes de produto.
 
-- `$SKILL_TEMPLATE_FOLDER`: `${CLAUDE_SKILL_DIR}/templates/`
-- `$SKILL_REFERENCES_FOLDER`: `${CLAUDE_SKILL_DIR}/references/`
+## Frases que acionam esta skill
 
+**PRD:** "criar um PRD sobre..." · "novo PRD para..." · "editar o PRD..."
 
-## Objetivo
+**FRD:** "criar um FRD sobre..." · "novo FRD para..."
 
-Esta é uma habilidade para ajudar gestores e líderes de produto a executarem suas tarefas e entregarem um trabalho de gestão de alta qualidade, facilitando decisões e análises.
+**Épico:** "crie um épico sobre..." · "novo épico para..."
 
-## Quando usar
-- Analisar mercado, concorrentes, outros produtos
-- Analisar o próprio produto para fornecer mais insights e identificar lacunas e oportunidades
-- Criar apresentações estratégicas e táticas 
-- Quando o usuário precisar analisar dados, indicadores e métricas de qualquer tipo
-- quando o usuário precisa criar especificações como:
-    - PRD: Documento de Requisitos do Produto
-    - FRD: Documento de requisitos de recursos
-    - Escreva épicos, histórias e tarefas técnicas
-- Planeje, analise e escreva itens como épicos, histórias, tarefas
-- Priorizar roadmaps, backlogs e planejamento de curto, médio e longo prazo
-- Escrever relatórios de status sobre projetos, obras em andamento
-- Compilar, organizar e escrever informações em documentos bem formatados e estruturados que serão compartilhados
-- apoiar e auxiliar o PM ou líder de produto em qualquer outra tarefa que possa ser necessária em sua função como gerente
+**História, tarefa ou bug:** "criar uma história sobre..." · "nova tarefa para..." · "criar um bug..."
 
-## Quando invocar
-
-Essa habilidade deve ser invocada quando o usuário pede para **fazer trabalho real com o produto**, como:
-
-- “Criar/aperfeiçoar um PRD/especificação/caso de negócios/1 página”
-- “Transforme esta ideia em um roteiro” / “Roteiro de resultados para X”
-- “Desenhar um plano de descoberta/roteiro de entrevista/plano de experiência”
-- “Definir métricas de sucesso/OKRs/árvore de métricas”
-- “Posicione este produto em relação aos concorrentes”
-- “Projetar um recurso alimentado por IA / agente GenAI / ciclo de vida AI PM”
-- “Executar uma conversa / feedback / 1:1 / negociação difícil”
-- “Planejar uma estratégia de produto/visão/avaliação de oportunidade”
-
-## Instruções e Referências
-
-SEMPRE utilize as instruções na íntegra contidas nessas referências de acordo com o contexto e pedido:
-
-- Crie, modifique ou esclareça um PRD seguindo as instruções em `references/prod.spec.prd.md`
-- Crie, modifique ou esclareça um FRD seguindo as instruções em `references/prod.spec.frd.md`
-- Avalie, clarifique, detalhe e identifique gaps e possíveis melhorias na especificação seguindo as instruções em `references/prod.spec.clarify.md`
-
-Para outras necessidades não especificadas ou que não possuam instruções ou templates, aplique as boas práticas comumente utilizadas pelos Gerentes de Produto no mercado.
-
-Se o usuário solicitar para ver o que pode ser feito com essa habilidade, cite todas as referências disponíveis com uma descrição concisa.
-
-Cenário A: "Criar um PRD para um aplicativo de tarefas" → Fluxo de trabalho completo de perguntas
-Cenário B: "Crie um PRD com base neste documento: [...]" → Fluxo de trabalho de validação  
-Cenário C: "Editar este PRD: [...]" → Fluxo de trabalho de melhoria focado
-
-Esteja atento quando o usuário conversar em linguagem natural, para acionar comandos usando instruções corretas:
-
-## Templates Disponíveis
-
-Os templates ficam na pasta `templates` dessa skill. Elas devem ser usadas para gerar o output final para o usuário. Suas perguntas devem ser baseadas nesses templates para que eles fiquem completos, detalhados e com qualidade.
-
-- [Template para PRD](templates/prod-prd-template.md)
-- [Template para FRD](templates/prod-frd-template.md) 
-- [Template para épicos](templates/prod-epic-template.md) 
-- [Template para itens (história/tarefa/bug)](templates/prod-issue-template.md) 
-
-**Para PRDs:**
-- "criar um PRD sobre..."
-- "novo PRD para..."
-- "editar o PRD..."
-
-**Para problemas (histórias/tarefas/bugs):**
-- "criar uma história sobre..."
-- "nova tarefa para..."
-- "criar um bug..."
-
-**Para épicos:**
-- "crie um épico sobre..."
-- "novo épico para..."
-
-**Para FRDs:**
-- "criar um FRD sobre..."
-- "novo FRD para..."
-
-**Para esclarecimentos:**
-- "esclarecer a especificação..."
-- "esclarecer o PRD..."
+**Discovery:** "investigar uma ideia..." · "fazer discovery de..." · "tenho uma ideia, vale a pena?"
 
+**Esclarecimento:** "esclarecer a especificação..." · "esclarecer o PRD..."

package/templates/AGENTS.md

@@ -29,12 +29,13 @@ templates/
 │   └── qa/                         # Templates de QA
 │       ├── test-plan-template.md
 │       └── quality-gate-template.md
-└── product/                        # Templates de produto
-    ├── PRD-template.md             # Product Requirements Document
-    ├── FRD-template.md             # Feature Requirements Document
-    ├── epic-template.md            # Epicos
-    ├── story-template.md           # User Stories
-    └── issue-template.md           # Issues/Tasks
+└── product/                        # Templates de produto ($PROD_TEMPLATES)
+    ├── prod-prd-template.md        # Product Requirements Document
+    ├── prod-frd-template.md        # Functional Requirements Document
+    ├── prod-epic-template.md       # Épicos
+    ├── prod-issue-template.md      # Histórias, tarefas e bugs
+    ├── prod-breakdown-template.md  # Quebra de especificação
+    └── prod-discovery-template.md  # Discovery (investigação inicial de uma ideia)
 ```
 
 ---

package/templates/ENV-template.md

@@ -60,7 +60,7 @@ SESSIONS_DIR=.jarvis/sessions
 # Pastas de produto (derivadas das de cima — em geral não precisa mexer)
 PROD_FOLDER_NAME=product
 PROD_RULES=$RULES_FOLDER/$PROD_FOLDER_NAME
-PROD_FLOWS=.$IDE/$FLOWS_FOLDER/$PROD_FOLDER_NAME
+PROD_FLOWS=.$IDE/$FLOWS_FOLDER
 PROD_TEMPLATES=.$IDE/$TEMPLATES_FOLDER/$PROD_FOLDER_NAME
 PROD_DOCS=$DOCS_FOLDER/$PROD_FOLDER_NAME
 

package/templates/product/prod-discovery-template.md

@@ -0,0 +1,98 @@
+---
+id: {discovery-001}
+name: {nome dessa ideia}
+status: {in_review enquanto o rascunho existe | cancelled se o veredito for do_not_proceed}
+verdict: {vazio durante a entrevista | proceed | investigate_more | do_not_proceed}
+created_at: {YYYY-MM-DD}
+updated_at: {YYYY-MM-DD}
+created_by: {nome de quem criou esse doc}
+last_editor: {nome de quem editou por último}
+---
+
+# {id}: {name}
+
+> **Este documento é um rascunho.** Ele registra o que se sabe, o que é hipótese e o que ainda é lacuna sobre uma ideia. Não define tarefas, histórias, critérios de aceitação, estimativas nem escopo fechado, e nada aqui é verdade absoluta. Quando um PRD, FRD, épico ou issue for criado a partir dele, o documento novo é a fonte da verdade.
+>
+> Nunca registre credenciais, tokens nem dados pessoais de clientes neste arquivo: ele é versionado.
+
+## Ideia
+
+{O que é a ideia, em poucas frases, e para quem ela é. Use as palavras do usuário; não acrescente o que ele não disse.}
+
+## Problema
+
+{Declare o problema, não a solução. Responda, sempre que souber:}
+
+- **Qual é o problema?** {a dor, o que não funciona hoje}
+- **Quem sofre com ele?** {quem e em que situação}
+- **Qual a evidência de que ele existe?** {dado, relato ou observação; se não houver, diga "sem evidência"}
+- **Como se resolve hoje?** {a alternativa atual, mesmo que seja uma gambiarra}
+- **Por que agora?** {o que torna isto relevante neste momento}
+- **Como saberemos que funcionou?** {sinais de sucesso, sem metas fechadas}
+
+## Hipóteses
+
+{Uma tabela única com tudo o que precisaria ser verdade para a ideia funcionar: requisitos iniciais e suposições. Requisitos são hipóteses de alto nível, sem critério de aceitação. Destaque as de importância alta e certeza baixa: são as primeiras a validar e alimentam as perguntas em aberto.}
+
+| Hipótese | Tipo | Importância | Certeza | Origem | Como validar |
+|---|---|---|---|---|---|
+| {o que precisaria ser verdade} | {problema, requisito, usuário, técnica ou negócio} | {alta, média ou baixa} | {alta, média ou baixa} | {dado, observação ou suposição} | {como confirmar ou descartar} |
+
+## Viabilidade
+
+{Um sinal indicativo por lente, com a justificativa e as lacunas que o sustentam. É uma leitura inicial, não um desenho técnico nem uma estimativa. Um rascunho de abordagem técnica pode aparecer, sempre como hipótese a validar e nunca como decisão de arquitetura.}
+
+| Lente | Sinal | Justificativa e lacunas |
+|---|---|---|
+| **Valor:** alguém vai querer e usar? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
+| **Usabilidade:** as pessoas conseguem usar? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
+| **Técnica:** dá para construir com o que temos? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
+| **Negócio:** funciona para o negócio (custo, prazo, risco)? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
+
+## Alternativas e riscos
+
+{Inclua sempre "não fazer nada" e "usar algo que já existe", além das opções levantadas.}
+
+| Alternativa | Prós | Contras |
+|---|---|---|
+| {não fazer nada} | {prós resumidos} | {contras resumidos} |
+| {usar algo existente} | {prós resumidos} | {contras resumidos} |
+| {outra opção} | {prós resumidos} | {contras resumidos} |
+
+**Riscos e dependências:**
+
+- {risco ou dependência, com quem pode confirmar}
+
+## Perguntas em aberto
+
+{O que ainda precisa ser validado, com quem e como. Comece pelas hipóteses de importância alta e certeza baixa.}
+
+- [ ] {pergunta} — quem responde: {pessoa ou área}
+
+## Veredito
+
+{Uma recomendação, não uma aprovação. Escolha uma e justifique em poucas linhas:}
+
+- **proceed** (seguir): vale especificar. O problema parece real e não há lacuna crítica aberta
+- **investigate_more** (investigar mais): há lacuna crítica; liste o que falta. Uma lacuna crítica nunca dá `proceed`
+- **do_not_proceed** (não seguir): informe o motivo; o `status` passa a `cancelled` e o arquivo fica como registro da decisão
+
+**Veredito:** {proceed | investigate_more | do_not_proceed}
+
+**Motivo:** {justificativa}
+
+## Próximo passo sugerido
+
+{Sempre preencha, qualquer que seja o veredito. É só uma sugestão: o agente oferece usar este documento como insumo, mas nunca executa o comando sozinho, e você pode escolher outro caminho ou parar aqui.}
+
+- **Comando recomendado:** {/prod.spec.prd (e depois /prod.spec.breakdown), /prod.spec.frd, /prod.spec.issue, retomar este discovery ou arquivar a ideia}
+- **Motivo:** {por que esse caminho}
+- **Alternativa:** {outro caminho possível, se houver}
+
+## Histórico das sessões
+
+{Um registro por sessão de entrevista, em ordem cronológica.}
+
+| Data | O que foi coberto | Observações |
+|---|---|---|
+| {YYYY-MM-DD} | {temas cobertos nesta sessão} | {o que ficou pendente} |

package/{skills/prod-specs/templates → templates/product}/prod-epic-template.md

@@ -6,6 +6,7 @@ status: {icebox|in_review|in_progress|in_production|deprecated}
 task_link: {URL referêncial no $TASK_MANAGER - se existir. Se não, ignore essa linha}
 related_prd: {path PRD relacionado, exemplo /master-docs/product/prd-001.md}
 related_frd: {path FRD relacionado, exemplo /master-docs/product/frds/frd-001.md}
+related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
 created_at: {YYYY-MM-DD}
 updated_at: {YYYY-MM-DD}
 created_by: {nome de quem criou esse doc}

package/{skills/prod-specs/templates → templates/product}/prod-frd-template.md

@@ -6,6 +6,7 @@ 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}
+related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
 created_at: {YYYY-MM-DD}
 created_by: {nome de quem criou esse doc}
 ---

package/{skills/prod-specs/templates → templates/product}/prod-issue-template.md

@@ -5,6 +5,7 @@ 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}
+related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
 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}

package/{skills/prod-specs/templates → templates/product}/prod-prd-template.md

@@ -8,6 +8,7 @@ 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}
+related_discovery: {path do discovery de origem, exemplo $PROD_DOCS/discoveries/discovery-001-nome.md. Se não existir, ignore essa linha}
 created_at: {YYYY-MM-DD}
 created_by: {nome de quem criou esse doc}
 ---

package/workflows/AGENTS.md

@@ -28,6 +28,7 @@ workflows/
 │
 ├── product/                        # Workflows de produto
 │   ├── prod.spec.md               # Entrypoint de specs
+│   ├── prod.spec.discovery.md     # Investigacao inicial de uma ideia
 │   ├── prod.spec.prd.md           # Documento de Requisitos de Produto
 │   ├── prod.spec.frd.md           # Documento de Requisitos Funcionais
 │   ├── prod.spec.breakdown.md     # Quebra em versões / épicos / histórias
@@ -80,6 +81,7 @@ Utilize o arquivo `../../workflows/[dominio]/nome-do-workflow.md` como template.
 | `/eng.frontend-component` | `engineering/frontend/eng.frontend-component.md` |
 | `/eng.frontend-review` | `engineering/frontend/eng.frontend-review.md` |
 | `/eng.frontend-perf-audit` | `engineering/frontend/eng.frontend-perf-audit.md` |
+| `/prod.spec.discovery` | `product/prod.spec.discovery.md` |
 | `/prod.spec.prd` | `product/prod.spec.prd.md` |
 
 ---
@@ -140,7 +142,7 @@ Workflows de engenharia seguem fases restritas:
 | Fase | Workflows | Restricao |
 |------|-----------|-----------|
 | Planejamento | `eng.start`, `eng.plan` | Somente analise, SEM codigo |
-| Implementacao | `eng.work` | Codigo e testes, SEM commits |
+| Implementacao | `eng.work` | Codigo e testes, commit por fase, SEM push nem PR |
 | Entrega | `eng.pr` | Branch, commit e PR |
 
 **IMPORTANTE**: Respeitar estritamente as restricoes de cada fase.

package/workflows/README.md

@@ -14,6 +14,7 @@ workflows/
 │
 ├── product/                      # Gestão de Produto & Requisitos
 │   ├── prod.spec.md              # Entrypoint de especificações
+│   ├── prod.spec.discovery.md    # Investigação inicial de uma ideia (rascunho)
 │   ├── prod.spec.prd.md          # Documento de Requisitos de Produto
 │   ├── prod.spec.frd.md          # Documento de Requisitos Funcionais
 │   ├── prod.spec.breakdown.md    # Quebra em versões / épicos / histórias
@@ -70,6 +71,7 @@ workflows/
 | Workflow | Propósito |
 |----------|-----------|
 | `prod.spec.md` | Entrypoint unificado para especificações |
+| `prod.spec.discovery.md` | Investigar uma ideia inicial (problema, requisitos e viabilidade) e gerar um rascunho |
 | `prod.spec.prd.md` | Criar/editar Documento de Requisitos de Produto |
 | `prod.spec.frd.md` | Criar/editar Documento de Requisitos Funcionais |
 | `prod.spec.breakdown.md` | Quebrar spec grande em versões, épicos e histórias |