jarvis-ai-framework 2.0.0 → 2.1.1

package/taxonomy.md

@@ -58,63 +58,63 @@ Desenvolvedor Júnior (0-2 anos de experiência)
 - Aprendendo tecnologias e processos
 - Pede ajuda quando precisar — sem gate obrigatório de TL/PM
 - Foco em desenvolver habilidades técnicas
-- No fluxo downstream: dono ponta-a-ponta do card que assumiu (puxar, implementar, MR, validar, deploy)
+- No card: dono ponta-a-ponta do card que assumiu (puxar, implementar, MR, validar, deploy)
 
 ### PLENO
 Desenvolvedor Pleno (2-4 anos de experiência)
 - Autonomia em tarefas individuais
 - Contribui para decisões técnicas
 - Mentoría desenvolvedores júnior
-- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+- No card: dono ponta-a-ponta do card que assumiu
 
 ### SENIOR
 Desenvolvedor Sênior (4+ anos de experiência)
 - Alta autonomia técnica
 - Toma decisões arquiteturais
 - Mentoria e liderança técnica
-- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+- No card: dono ponta-a-ponta do card que assumiu
 
 ### TECH LEAD
 Líder técnico de time ou squad
 - Responsável por direção técnica do time
 - Coordena desenvolvimento e arquitetura
 - Interface entre time e stakeholders
-- No fluxo downstream: apoia o time. Não é gate — o profissional que assumiu o card conduz ponta-a-ponta. TL desbloqueia e cobre quando pedido.
+- No card: apoia o time. Não é gate — o profissional que assumiu o card conduz ponta-a-ponta. TL desbloqueia e cobre quando pedido.
 
 ### SPECIALIST
 Especialista em área técnica ou disciplina específica
 - Expert em domínio particular (segurança, performance, etc.)
 - Consultoria técnica para times
 - Define padrões e melhores práticas
-- No fluxo downstream: dono ponta-a-ponta do card que assumiu
+- No card: dono ponta-a-ponta do card que assumiu
 
 ### QA-ENGINEER
 Engenheiro de Quality Assurance
 - Planejamento e execução de testes (manuais e automatizados)
 - Reporte e rastreamento de bugs
 - Validação técnica de entregas antes da aprovação de produto
-- No fluxo downstream: apoia o DEV na validação — não move cards, apenas executa e reporta
+- No card: apoia o DEV na validação — não move cards, apenas executa e reporta
 
 ### PM
 Product Manager
 - Gestão de produto e roadmap
 - Define prioridades e features
 - Interface com stakeholders de negócio
-- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+- No card: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
 
 ### TPM
 Technical Product Manager
 - Product Manager com foco técnico
 - Ponte entre produto e engenharia
 - Decisões de produto com viés técnico
-- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+- No card: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
 
 ### GPM
 Group Product Manager
 - Gerencia múltiplos PMs
 - Visão estratégica de produto
 - Coordenação entre diferentes áreas
-- No fluxo downstream: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
+- No card: pode priorizar, aceitar e também assumir/conduzir um card ponta-a-ponta. Aceite apoia — não trava o owner.
 
 ### QUALITY_CHAMPION
 Designação secundária para devs com função parcial de qualidade dentro do squad.
@@ -124,7 +124,7 @@ Registrado no campo Posição do `members.md` junto com o cargo principal.
 - Executa quality gates e orienta outros devs via eng-qa-dev-guide
 - NÃO substitui QA em features críticas, decisões de bloqueio ou sign-off de release
 - Dedicação típica: ~30% do tempo em atividades de qualidade
-- No fluxo downstream: apoia o QA-ENGINEER na cobertura — não toma decisões de bloqueio
+- No card: apoia o QA-ENGINEER na cobertura — não toma decisões de bloqueio
 
 ### CTO
 Chief Technology Officer
@@ -137,7 +137,7 @@ Profissional que acumula funções de outras posições (SPECIALIST, PM, dev, QA
 - Cargo principal (como SPECIALIST), não designação secundária (diferente de QUALITY_CHAMPION)
 - Transita entre ENGINEERING e PRODUCT — não fica restrito a uma única área
 - Em qualquer verificação de POSITION ou AREA, é tratado como coringa/superusuário: satisfaz qualquer valor exigido
-- No fluxo downstream: dono ponta-a-ponta do card que assumiu, com autonomia equivalente a TECH LEAD/staff (ver eng-rules.md)
+- No card: dono ponta-a-ponta do card que assumiu, com autonomia equivalente a TECH LEAD/staff (ver eng-rules.md)
 
 ---
 
@@ -215,7 +215,7 @@ prefix: design
 Área de Design, UX e pesquisa com usuários
 ```
 
-> Use `/taxonomy-manager add` para adicionar opções com validação automática.
+> Use `/taxonomy add` para adicionar opções com validação automática.
 
 ---
 

package/templates/AGENTS.md

@@ -20,6 +20,7 @@ templates/
 │   ├── RFC-template.md             # Request For Comments
 │   ├── RFC-Playbook@1.0.0.md       # Playbook para RFCs
 │   ├── tech-spec-template.md       # Especificacao tecnica
+│   ├── tech-spec-delivery-template.md # Formatos de entrega da tech spec (Jira, mensagem final, fluxo)
 │   ├── plan-template.md            # Plano de execucao
 │   ├── work-progress-template.md   # Progresso de trabalho
 │   ├── PR-template.md              # Pull Request
@@ -107,6 +108,7 @@ Use chaves `{...}` para indicar campos a serem preenchidos:
 | `ARD-template.md` | Revisao de arquitetura | `/eng.create-ard` |
 | `RFC-template.md` | Proposta de mudanca | `/eng.create-rfc` |
 | `tech-spec-template.md` | Especificacao tecnica | `/eng.build-tech-spec` |
+| `tech-spec-delivery-template.md` | Formatos de entrega da tech spec | `/eng.build-tech-spec` |
 | `plan-template.md` | Plano de execucao | `/eng.plan` |
 | `PR-template.md` | Pull Request | `/eng.pr` |
 

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,7 @@ 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-quality-gate-validation.md
 ```
 
 ---
@@ -112,6 +112,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 +139,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 +231,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,14 @@ 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-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
 ```
 
 ---
@@ -74,6 +75,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 +106,14 @@ 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-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 |
 
 ---
 

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-onboard` | 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

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-bug-report create` | Para cada problema P0 e P1 encontrado no audit |
+
 ---
 
 ## Fase 0 – Análise de Contexto (CDD)
@@ -456,12 +463,12 @@ 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
+### 5.1 Usar Skill eng-qa-bug-report
 
 Para cada problema P0 e P1:
 
 ```bash
-/bug-report create \
+/eng-qa-bug-report create \
   --title="{título do bug}" \
   --category="{categoria}" \
   --severity="{P0|P1|P2|P3}" \