jarvis-ai-framework 2.1.0 → 3.0.0

package/templates/engineering/tech-spec-delivery-template.md

@@ -0,0 +1,179 @@
+# Tech Spec — Formatos de Entrega
+
+> Template com os formatos usados no fim do `eng.build-tech-spec`: descrição da subtarefa no Jira, comentário na história original, mensagem de entrega e um exemplo preenchido, além do diagrama do fluxo. Substitua os placeholders `{...}`.
+
+## Descrição da subtarefa no Jira
+
+Fase 7.2 do workflow. Use este formato na descrição de cada subtarefa criada no Jira (ou entregue ao usuário para copiar e colar).
+
+```markdown
+## Descrição
+
+{Descrição técnica detalhada}
+
+## Arquivos a Modificar/Criar
+
+- `path/to/file1.py` - [Modificação] - {Descrição}
+- `path/to/file2.tsx` - [Criação] - {Descrição}
+
+## Critérios de Aceitação
+
+- [ ] {Critério 1}
+- [ ] {Critério 2}
+
+## Testes Requeridos
+
+- [ ] Teste unitário: {descrição}
+- [ ] Teste de integração: {descrição}
+
+## Dependências
+
+{SUBTASK-XXX / Nenhuma}
+
+## Referência
+
+Tech Spec: [Link para tech-spec.md]
+```
+
+## Comentário na história original
+
+Fase 7.4 do workflow. Comentário a registrar na história (STORY-XXX) depois de criar as subtarefas.
+
+```
+Tech Spec criada: [Link para tech-spec.md]
+
+Subtarefas criadas:
+- SUBTASK-001: {Nome}
+- SUBTASK-002: {Nome}
+- SUBTASK-003: {Nome}
+...
+
+Total de subtarefas: {X}
+Estimativa total: {Y horas}
+```
+
+## Mensagem de entrega
+
+Fase 8.2 do workflow. O que entregar ao usuário ao final.
+
+```
+✅ Tech Spec criada com sucesso!
+
+📄 Documento Local: $SESSIONS_DIR/eng/{feature-name}/tech-spec.md
+📎 Anexada no Jira: {STORY-XXX}
+
+📋 Resumo:
+- História: {STORY-XXX} - {Título}
+- Fases: {X fases}
+- Subtarefas: {Y subtarefas}
+- Estimativa total: {Z horas}
+
+🔗 Subtarefas criadas no Jira:
+- SUBTASK-001: {Nome} (P0, 6h)
+- SUBTASK-002: {Nome} (P1, 4h)
+- SUBTASK-003: {Nome} (P1, 8h)
+...
+
+⚠️ Riscos Principais:
+- {Risco 1}
+- {Risco 2}
+
+📌 Próximos Passos Sugeridos:
+1. Revisar e aprovar a Tech Spec
+2. Atribuir subtarefas ao time
+3. Iniciar desenvolvimento pela Fase 1
+4. Monitorar progresso e atualizar plan.md
+```
+
+## Exemplo de output final
+
+Exemplo preenchido da mensagem de entrega (fictício).
+
+```markdown
+✅ Tech Spec para STORY-456 criada com sucesso!
+
+📄 **Documento Local**: $SESSIONS_DIR/eng/story-456/tech-spec.md
+📎 **Anexado no Jira**: STORY-456
+
+📊 **Resumo**:
+
+- **História**: STORY-456 - Implementar autenticação de usuários
+- **Fases**: 3 fases (Backend, Frontend, Testes)
+- **Subtarefas**: 5 subtarefas
+- **Estimativa total**: 26 horas
+
+🔗 **Subtarefas criadas no Jira**:
+
+- SUBTASK-101: [BACKEND] Criar endpoint POST /api/auth/register (P0, 6h)
+- SUBTASK-102: [BACKEND] Criar endpoint POST /api/auth/login (P0, 6h)
+- SUBTASK-103: [BACKEND] Criar endpoint POST /api/auth/logout (P1, 4h)
+- SUBTASK-104: [FRONTEND] Criar tela de login integrada à API (P1, 6h)
+- SUBTASK-105: [QA] Testes E2E do fluxo de autenticação (P2, 4h)
+
+⚠️ **Riscos Principais**:
+
+- JWT secret precisa estar em variável de ambiente
+- Performance de bcrypt pode impactar tempo de login (mitigado com salt rounds = 10)
+
+📐 **Decisões Arquiteturais**:
+
+- Escolhido JWT em vez de sessões (stateless, escalável)
+- Bcrypt para hash de senhas (padrão da indústria)
+- Rate limiting em login (proteção contra brute force)
+
+📌 **Próximos Passos**:
+
+1. ✅ Revisar tech spec (aguardando sua aprovação)
+2. Atribuir SUBTASK-101 a 103 para desenvolvedor backend
+3. Atribuir SUBTASK-104 para desenvolvedor frontend
+4. Iniciar pelo backend - SUBTASK-101 e 102
+5. Configurar variáveis de ambiente em staging/prod
+
+🎯 **Pronto para iniciar desenvolvimento!**
+```
+
+## Fluxo resumido
+
+Visão geral do fluxo do workflow, do tipo de documento (épico ou história) até a entrega.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ 0. DETECÇÃO DO TIPO                                     │
+│    └─ Épico ou História? (inferir ou perguntar)        │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+┌─────────────────────────────────────────────────────────┐
+│ 1. ENTENDIMENTO                                         │
+│    └─ Ler card, fazer perguntas, validar contexto      │
+└─────────────────────────────────────────────────────────┘
+                          ↓
+           ┌──────────────┴──────────────┐
+           ▼                             ▼
+   ┌───────────────┐             ┌───────────────┐
+   │    ÉPICO      │             │   HISTÓRIA    │
+   ├───────────────┤             ├───────────────┤
+   │ 2A. Investig. │             │ 2B. Investig. │
+   │    arquit.    │             │    codebase   │
+   ├───────────────┤             ├───────────────┤
+   │ 3A. Proposta  │             │ 2.5B. Compl.  │
+   │    arquit.    │             ├───────────────┤
+   ├───────────────┤             │ 3B. Proposta  │
+   │ 4A. Doc       │             ├───────────────┤
+   │ tech-spec-    │             │ 4B. Subtaref. │
+   │ arch.md       │             ├───────────────┤
+   └───────────────┘             │ 5B. Riscos    │
+                                 ├───────────────┤
+                                 │ 6B. Doc       │
+                                 │ tech-spec.md  │
+                                 ├───────────────┤
+                                 │ 7B. $TASK_MGR │
+                                 ├───────────────┤
+                                 │ 8B. Entrega   │
+                                 └───────────────┘
+```
+
+---
+
+**Notas para o agente**:
+- Este arquivo só traz formatos: o passo a passo continua em `workflows/engineering/eng.build-tech-spec.md`.
+- Mantenha os placeholders `{...}` até ter os dados reais; não invente links, estimativas nem ids.

package/workflows/AGENTS.md

@@ -56,7 +56,9 @@ workflows/
     │   ├── eng.frontend-review.md      # Revisão de PR frontend
     │   └── eng.frontend-perf-audit.md  # Auditoria de performance (Core Web Vitals)
     └── qa/
-        └── eng-qa-quality-gate-validation.md
+        ├── eng.qa-refinement-entry.md
+        ├── eng.qa-release-signoff.md
+        └── eng.qa-sprint-planning.md
 ```
 
 ---
@@ -112,6 +114,12 @@ O que este workflow faz.
 - Validar ENV.md
 - Outros requisitos
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Fase 1 | `/nome-da-skill` | Condição real do texto do workflow |
+
 ## Entrada
 - `$ARGUMENTS` - Descricao
 - Outros inputs
@@ -133,6 +141,10 @@ Artefatos gerados.
 Feedback ao usuario.
 ```
 
+A tabela `### Skills invocados durante o workflow` lista o que o workflow dispara no proprio fluxo: skills, outros workflows, agentes e MCP/CLI citados pelo nome (nao vale ferramenta interna como `Read`/`Grep`, nem "proximos passos" ou pre-requisito pedido ao usuario). Uma linha por referencia, com a condicao real. Fica logo depois da secao de recursos/dependencias (ou, sem ela, depois do titulo e da descricao). Sem chamadas: uma linha `Nenhuma — workflow autocontido`. Modelo: `engineering/eng.debug.md`.
+
+O `jarvis map` e a verificação do `npm run test:comandos` leem **só** a tabela (e, nos agentes, as seções `## Skills Disponíveis` e `## Workflows e Agentes Relacionados`): uma chamada que existir apenas no texto corrido não aparece no mapa, e um nome citado na tabela que não existir faz o teste falhar. Mantenha a tabela em dia ao alterar o artefato.
+
 ---
 
 ## Fases de Desenvolvimento
@@ -221,7 +233,7 @@ Workflows de engenharia seguem fases restritas:
 
 1. Identificar necessidade (verificar existentes)
 2. Criar command em `commands/`
-3. Criar workflow seguindo estrutura padrao
+3. Criar workflow seguindo estrutura padrao, incluindo a tabela `Skills invocados durante o workflow`
 4. Definir restricoes de fase (se engenharia)
 5. Vincular a templates (se aplicavel)
 6. Atualizar README.md

package/workflows/README.md

@@ -17,6 +17,7 @@ workflows/
 │   ├── 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.ard.md          # ARD a partir do produto
 │   ├── prod.spec.breakdown.md    # Quebra em versões / épicos / histórias
 │   ├── prod.spec.epic.md         # Épicos
 │   ├── prod.spec.issue.md        # Issues (stories, tasks, bugs)
@@ -44,14 +45,9 @@ workflows/
     │   ├── eng.frontend-review.md        # Revisão de PR frontend (TS, tokens, a11y, MFE)
     │   └── eng.frontend-perf-audit.md    # Auditoria Core Web Vitals e bundle
     └── qa/
-        ├── eng-qa-quality-gate-validation.md
-        ├── eng-qa-e2e-test-generation.md
-        ├── eng-qa-exploratory-session.md
-        ├── eng-qa-dev-quality-guide.md
-        ├── eng-qa-quality-report.md
-        ├── eng-qa-refinement-entry.md
-        ├── eng-qa-release-signoff.md
-        └── eng-qa-sprint-planning.md
+        ├── eng.qa-refinement-entry.md
+        ├── eng.qa-release-signoff.md
+        └── eng.qa-sprint-planning.md
 ```
 
 ---
@@ -74,6 +70,7 @@ workflows/
 | `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.ard.md` | Levantar requisitos arquiteturais com o PM e conduzir o ARD |
 | `prod.spec.breakdown.md` | Quebrar spec grande em versões, épicos e histórias |
 | `prod.spec.epic.md` | Criar/editar épicos |
 | `prod.spec.issue.md` | Criar/editar issues (stories, tasks, bugs) |
@@ -104,14 +101,9 @@ workflows/
 | `eng.frontend-component.md` | Criar ou refatorar componente frontend com qualidade (design system vs remote, a11y, testes) |
 | `eng.frontend-review.md` | Revisão de código específica para PRs frontend (TypeScript, tokens, a11y, MFE) |
 | `eng.frontend-perf-audit.md` | Auditoria de performance frontend (Core Web Vitals, bundle, diagnóstico por métrica) |
-| `eng-qa-quality-gate-validation.md` | Validação de quality gate de um ticket |
-| `eng-qa-e2e-test-generation.md` | Geração de testes E2E Cypress para uma feature |
-| `eng-qa-exploratory-session.md` | Conduzir sessão de teste exploratório |
-| `eng-qa-dev-quality-guide.md` | Orientar dev a escrever seus próprios testes Cypress |
-| `eng-qa-quality-report.md` | Relatório de qualidade consolidado por sprint/release |
-| `eng-qa-refinement-entry.md` | Entrada do QA no refinement de tickets |
-| `eng-qa-release-signoff.md` | Sign-off QA pré-deploy (GO/NO-GO) |
-| `eng-qa-sprint-planning.md` | Planejamento de capacidade QA por sprint |
+| `eng.qa-refinement-entry.md` | Entrada do QA no refinement de tickets |
+| `eng.qa-release-signoff.md` | Sign-off QA pré-deploy (GO/NO-GO) |
+| `eng.qa-sprint-planning.md` | Planejamento de capacidade QA por sprint |
 
 ---
 

package/workflows/all-tools.md

@@ -8,4 +8,10 @@ model_justification: Listagem simples de ferramentas, não requer raciocínio co
 
 # all-tools
 
-Liste todas as ferramentas disponíveis detalhadas em seu prompt da plataforma. Exiba-as em marcadores. Mostre-as em formato de assinatura de função TypeScript e inclua o propósito da ferramenta como sufixo.
+Liste todas as ferramentas disponíveis detalhadas em seu prompt da plataforma. Exiba-as em marcadores. Mostre-as em formato de assinatura de função TypeScript e inclua o propósito da ferramenta como sufixo.
+
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |

package/workflows/engineering/data/data.contract.md

@@ -37,6 +37,14 @@ seguindo as convenções definidas em `$IDE/rules/engineering/data/data-rules.md
   - Arquivo: `$IDE/agents/engineering/eng.docs-writer.md`
   - Quando usar: contratos de domínios com muitos termos de negócio (financeiro, operacional, BI).
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Agentes recomendados | `eng.data-engineer.agent` (agente) | Sempre — agente primário que conduz todo o workflow |
+| Agentes recomendados | `prod.pm-checker` (agente) | Se o caso de uso vier de uma solicitação de produto (analytics/BI) ou houver ambiguidade sobre o que a squad precisa |
+| Agentes recomendados | `eng.docs-writer` (agente) | Se o contrato for de domínio com muitos termos de negócio (financeiro, operacional, BI) |
+
 ---
 
 ## Entrada

package/workflows/engineering/data/data.new-pipeline.md

@@ -38,6 +38,16 @@ seguindo as convenções definidas em `$IDE/rules/engineering/data/data-rules.md
   - Arquivo: `$IDE/agents/engineering/eng.docs-writer.md`
   - Quando usar: pipelines de alta criticidade ou que precisam de documentação de suporte além do template padrão.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Agentes recomendados | `eng.data-engineer.agent` (agente) | Sempre — agente primário que conduz todo o workflow |
+| Pré-verificação — Fonte nova ou existente? | `/eng-data` | Se a fonte nunca foi ingerida antes (pipeline totalmente novo); depois volta a este workflow |
+| Agentes recomendados | `eng.dev-code-reviewer` (agente) | Se o pipeline tiver lógica de transformação complexa ou antes de qualquer push ao repositório de pipelines |
+| Agentes recomendados | `eng.qa.test-planner` (agente) | Se o pipeline for gold com múltiplos casos de uso, dados sensíveis ou SLA rigoroso (apoio à Expectation Suite) |
+| Agentes recomendados | `eng.docs-writer` (agente) | Se o pipeline for de alta criticidade ou precisar de documentação além do template (diagramas, runbook, troubleshooting) |
+
 ---
 
 ## Entrada
@@ -61,10 +71,11 @@ seguindo as convenções definidas em `$IDE/rules/engineering/data/data-rules.md
 
 > Antes de iniciar, verificar se já há dados desta fonte em bronze.
 
-**Se a fonte nunca foi ingerida antes** (pipeline totalmente novo):
-→ Executar `eng-data-onboard` primeiro para fazer schema discovery, amostragem e criar a camada bronze.
-→ Arquivo: `$IDE/skills/eng-data-onboard/SKILL.md`
-→ Voltar para este workflow após o bronze estar validado (Fases 3–5 do onboard concluídas).
+**Se a fonte nunca foi ingerida antes** (pipeline totalmente novo), usar a base [eng-data]($IDE/skills/eng-data/SKILL.md) (tema 1 — Fundamentos, tema 5 — Pipelines e Integração) para:
+1. Entender a fonte (nome, tipo, frequência, volume, owner, campos disponíveis e sensíveis, SLA)
+2. Fazer schema discovery e amostragem
+3. Criar a camada bronze e uma Expectation Suite mínima (tema 6 — Qualidade de Dados)
+→ Voltar para este workflow (Fase 1 abaixo) depois do bronze estar validado.
 
 **Se a fonte já existe em bronze** → continuar diretamente com a Fase 1 abaixo.
 

package/workflows/engineering/eng.breakdown-subtasks.md

@@ -4,6 +4,7 @@ auto_execution_mode: 0
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
 model_justification: Decomposição de tarefas requer análise detalhada, geração de código de exemplo e estruturação de subtarefas executáveis
+rules_file: "$IDE/rules-on-demand/engineering/eng.breakdown-subtasks-rules.md"
 ---
 # Breakdown Subtasks - Gerador de Subtarefas Mastigadas
 
@@ -11,10 +12,18 @@ Você receberá uma Tech Spec completa e deve quebrá-la em subtarefas **EXTREMA
 
 > ⚠️ **PRINCÍPIO FUNDAMENTAL**: Cada subtarefa deve ser tão detalhada que um desenvolvedor júnior possa executá-la SEM precisar perguntar nada. A subtarefa deve ser um "tutorial passo-a-passo" completo.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.breakdown-subtasks-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 <input>
 #$ARGUMENTS
 </input>
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
 ---
 
 ## Fase 1: Análise Profunda da Tech Spec

package/workflows/engineering/eng.bug-audit.md

@@ -57,6 +57,13 @@ Onde [escopo] pode ser:
 - Por tecnologia: --tech=react
 ```
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Fase 0 – Análise de Contexto (CDD) | `/jarvis-context-detect` | Se existir uma sessão ativa (e `ENABLE_CDD=true` no ENV.md) |
+| Fase 5 – Ticketing › 5.1 | `/eng-qa` + `QA_SPECIALIZATIONS` | Para estruturar cada problema P0 e P1 encontrado no audit antes de abrir o card |
+
 ---
 
 ## Fase 0 – Análise de Contexto (CDD)
@@ -456,19 +463,9 @@ echo "✅ Relatório gerado em: $SESSIONS_DIR/eng/bug-audit-$(date +%Y%m%d-%H%M%
 
 ## Fase 5 – Ticketing (Criação de Cards no Task Manager)
 
-### 5.1 Usar Skill bug-report
-
-Para cada problema P0 e P1:
+### 5.1 Estruturar e abrir o card
 
-```bash
-/bug-report create \
-  --title="{título do bug}" \
-  --category="{categoria}" \
-  --severity="{P0|P1|P2|P3}" \
-  --location="{arquivo:linha}" \
-  --description="{descrição}" \
-  --suggestion="{sugestão de correção}"
-```
+Para cada problema P0 e P1, use a base [eng-qa](../../skills/eng-qa/SKILL.md) + a especialização registrada em `QA_SPECIALIZATIONS` (se houver uma) — tema 14, Gestão de Testes e de Defeitos — para estruturar o achado, e abra o card no `$TASK_MANAGER` do projeto com a estrutura da seção 5.2.
 
 ### 5.2 Estrutura dos Cards Criados
 
@@ -569,7 +566,7 @@ Cada card deve conter:
 - **eng.debug**: Para investigar bugs específicos encontrados no audit
 - **eng.work**: Para implementar correções
 - **eng.pr**: Para submeter correções
-- **eng-qa-gate**: Para validar correções antes de merge
+- **eng.pre-pr**: Para validar correções antes de merge
 
 ---
 

package/workflows/engineering/eng.build-tech-spec.md

@@ -2,7 +2,7 @@
 description: Criação de Tech Spec a partir de história do Jira
 auto_execution_mode: 3
 recommended_model: claude-sonnet-4-20250514
-rules_file: $IDE/rules/engineering/eng.tech-spec-rules.md
+rules_file: $IDE/rules-on-demand/engineering/eng.tech-spec-rules.md
 template_file: $IDE/templates/engineering/tech-spec-template.md
 model_tier: very_high
 model_justification: Tech Spec requer análise profunda de requisitos, decisões arquiteturais, decomposição de tarefas e documentação técnica detalhada
@@ -33,6 +33,8 @@ Para criar Tech Specs, entre em contato com seu Tech Lead.
 
 **Somente se `POSITION=TECH LEAD`**, prossiga com o workflow abaixo.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.tech-spec-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 ---
 
 Você é um **arquiteto de software especializado** em transformar histórias do Jira em especificações técnicas detalhadas, quebradas em subtarefas executáveis e prontas para implementação.
@@ -47,6 +49,14 @@ Transformar uma história de usuário (user story) do Jira em uma **Tech Spec co
 4. Define critérios de validação técnica
 5. Identifica riscos e dependências
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Processo de Criação › verificação de necessidade de RFC | `/eng.create-rfc` | Se a Tech Spec atender aos critérios que exigem RFC e o usuário escolher "A: Criar uma RFC agora" |
+| Caminho A › 2A.2 Análise de Documentação de Produto | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado (buscar PRD/FRD relacionados do épico) |
+| FASE 7 › 7.3 Criação no Jira | `ferramenta MCP/API do Jira` (referência a confirmar) | Se o projeto usar Jira e houver ferramenta MCP ou API disponível; senão fornecer template para criação manual (o texto não nomeia a ferramenta) |
+
 ---
 
 ## Input
@@ -789,34 +799,7 @@ Para cada subtarefa no plano:
 
 #### 7.2 Estrutura da Descrição no Jira
 
-```markdown
-## Descrição
-
-{Descrição técnica detalhada}
-
-## Arquivos a Modificar/Criar
-
-- `path/to/file1.py` - [Modificação] - {Descrição}
-- `path/to/file2.tsx` - [Criação] - {Descrição}
-
-## Critérios de Aceitação
-
-- [ ] {Critério 1}
-- [ ] {Critério 2}
-
-## Testes Requeridos
-
-- [ ] Teste unitário: {descrição}
-- [ ] Teste de integração: {descrição}
-
-## Dependências
-
-{SUBTASK-XXX / Nenhuma}
-
-## Referência
-
-Tech Spec: [Link para tech-spec.md]
-```
+Use o formato **Descrição da subtarefa no Jira** de `$IDE/templates/engineering/tech-spec-delivery-template.md` (seções: Descrição, Arquivos a Modificar/Criar, Critérios de Aceitação, Testes Requeridos, Dependências, Referência).
 
 #### 7.3 Criação no Jira
 
@@ -835,18 +818,7 @@ Tech Spec: [Link para tech-spec.md]
 
 Adicione comentário na história original (STORY-XXX) com:
 
-```
-Tech Spec criada: [Link para tech-spec.md]
-
-Subtarefas criadas:
-- SUBTASK-001: {Nome}
-- SUBTASK-002: {Nome}
-- SUBTASK-003: {Nome}
-...
-
-Total de subtarefas: {X}
-Estimativa total: {Y horas}
-```
+Use o formato **Comentário na história original** de `$IDE/templates/engineering/tech-spec-delivery-template.md`.
 
 ---
 
@@ -875,34 +847,7 @@ Valide que:
 
 Forneça ao usuário:
 
-```
-✅ Tech Spec criada com sucesso!
-
-📄 Documento Local: $SESSIONS_DIR/eng/{feature-name}/tech-spec.md
-📎 Anexada no Jira: {STORY-XXX}
-
-📋 Resumo:
-- História: {STORY-XXX} - {Título}
-- Fases: {X fases}
-- Subtarefas: {Y subtarefas}
-- Estimativa total: {Z horas}
-
-🔗 Subtarefas criadas no Jira:
-- SUBTASK-001: {Nome} (P0, 6h)
-- SUBTASK-002: {Nome} (P1, 4h)
-- SUBTASK-003: {Nome} (P1, 8h)
-...
-
-⚠️ Riscos Principais:
-- {Risco 1}
-- {Risco 2}
-
-📌 Próximos Passos Sugeridos:
-1. Revisar e aprovar a Tech Spec
-2. Atribuir subtarefas ao time
-3. Iniciar desenvolvimento pela Fase 1
-4. Monitorar progresso e atualizar plan.md
-```
+Use o formato **Mensagem de entrega** de `$IDE/templates/engineering/tech-spec-delivery-template.md`; um exemplo preenchido está na seção **Exemplo de output final** do mesmo arquivo.
 
 ---
 
@@ -968,46 +913,13 @@ Forneça ao usuário:
 ### Templates
 
 - `templates/engineering/tech-spec-template.md` - Template de Tech Spec
+- `templates/engineering/tech-spec-delivery-template.md` - Formatos de entrega (descrição da subtarefa no Jira, comentário na história, mensagem de entrega, exemplo e fluxo resumido)
 
 ---
 
 ## Fluxo Resumido
 
-```
-┌─────────────────────────────────────────────────────────┐
-│ 0. DETECÇÃO DO TIPO                                     │
-│    └─ Épico ou História? (inferir ou perguntar)        │
-└─────────────────────────────────────────────────────────┘
-                          ↓
-┌─────────────────────────────────────────────────────────┐
-│ 1. ENTENDIMENTO                                         │
-│    └─ Ler card, fazer perguntas, validar contexto      │
-└─────────────────────────────────────────────────────────┘
-                          ↓
-           ┌──────────────┴──────────────┐
-           ▼                             ▼
-   ┌───────────────┐             ┌───────────────┐
-   │    ÉPICO      │             │   HISTÓRIA    │
-   ├───────────────┤             ├───────────────┤
-   │ 2A. Investig. │             │ 2B. Investig. │
-   │    arquit.    │             │    codebase   │
-   ├───────────────┤             ├───────────────┤
-   │ 3A. Proposta  │             │ 2.5B. Compl.  │
-   │    arquit.    │             ├───────────────┤
-   ├───────────────┤             │ 3B. Proposta  │
-   │ 4A. Doc       │             ├───────────────┤
-   │ tech-spec-    │             │ 4B. Subtaref. │
-   │ arch.md       │             ├───────────────┤
-   └───────────────┘             │ 5B. Riscos    │
-                                 ├───────────────┤
-                                 │ 6B. Doc       │
-                                 │ tech-spec.md  │
-                                 ├───────────────┤
-                                 │ 7B. $TASK_MGR │
-                                 ├───────────────┤
-                                 │ 8B. Entrega   │
-                                 └───────────────┘
-```
+O diagrama do fluxo (épico x história, fases 0 a 8) está na seção **Fluxo resumido** de `$IDE/templates/engineering/tech-spec-delivery-template.md`.
 
 ---
 
@@ -1057,48 +969,7 @@ Forneça ao usuário:
 
 ## Exemplo de Output Final
 
-```markdown
-✅ Tech Spec para STORY-456 criada com sucesso!
-
-📄 **Documento Local**: $SESSIONS_DIR/eng/story-456/tech-spec.md
-📎 **Anexado no Jira**: STORY-456
-
-📊 **Resumo**:
-
-- **História**: STORY-456 - Implementar autenticação de usuários
-- **Fases**: 3 fases (Backend, Frontend, Testes)
-- **Subtarefas**: 5 subtarefas
-- **Estimativa total**: 26 horas
-
-🔗 **Subtarefas criadas no Jira**:
-
-- SUBTASK-101: [BACKEND] Criar endpoint POST /api/auth/register (P0, 6h)
-- SUBTASK-102: [BACKEND] Criar endpoint POST /api/auth/login (P0, 6h)
-- SUBTASK-103: [BACKEND] Criar endpoint POST /api/auth/logout (P1, 4h)
-- SUBTASK-104: [FRONTEND] Criar tela de login integrada à API (P1, 6h)
-- SUBTASK-105: [QA] Testes E2E do fluxo de autenticação (P2, 4h)
-
-⚠️ **Riscos Principais**:
-
-- JWT secret precisa estar em variável de ambiente
-- Performance de bcrypt pode impactar tempo de login (mitigado com salt rounds = 10)
-
-📐 **Decisões Arquiteturais**:
-
-- Escolhido JWT em vez de sessões (stateless, escalável)
-- Bcrypt para hash de senhas (padrão da indústria)
-- Rate limiting em login (proteção contra brute force)
-
-📌 **Próximos Passos**:
-
-1. ✅ Revisar tech spec (aguardando sua aprovação)
-2. Atribuir SUBTASK-101 a 103 para desenvolvedor backend
-3. Atribuir SUBTASK-104 para desenvolvedor frontend
-4. Iniciar pelo backend - SUBTASK-101 e 102
-5. Configurar variáveis de ambiente em staging/prod
-
-🎯 **Pronto para iniciar desenvolvimento!**
-```
+Veja o exemplo preenchido na seção **Exemplo de output final** de `$IDE/templates/engineering/tech-spec-delivery-template.md`.
 
 ---
 

package/workflows/engineering/eng.create-ard-from-code.md

@@ -17,6 +17,14 @@ priorizando a **arquitetura observada no código do repositório**, usando o tem
 - regras de engenharia em `$IDE/rules/engineering/eng-rules.md`
 - identidade em `$IDE/agents/engineering/eng.agent.md`
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Objetivo | `eng.agent` (agente) | Sempre — identidade do workflow (alinhamento com `eng.agent.md`) |
+| Passo 1 – Verificar PRD | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
+| Passo 7 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
+
 ---
 
 ## Passo 0 – Definir se é novo ARD ou iteração

package/workflows/engineering/eng.create-ard.md

@@ -20,6 +20,14 @@ usando o template `$IDE/templates/engineering/ARD-template.md`, sempre alinhado
 - regras de versionamento em `$IDE/rules/engineering/eng.bump-rules.md`
 - identidade em `$IDE/agents/engineering/eng.agent.md`
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Objetivo | `eng.agent` (agente) | Sempre — identidade do workflow (alinhamento com `eng.agent.md`) |
+| Passo 1.1.1 – Buscar PRD no Central Docs | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_REPO` estiver definido no ENV.md |
+| Passo 8 – Publicar no Central Docs | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver definido, o ARD estiver aprovado e o usuário aceitar publicar |
+
 ---
 
 ## Passo 0 – Definir se é novo ARD ou iteração