jarvis-ai-framework 2.0.0 → 2.1.1

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

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

@@ -23,6 +23,13 @@ Além disso, quando houver campo `Versão` no RFC, aplicar obrigatoriamente:
 
 - `$IDE/rules/engineering/eng.bump-rules.md`
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Passo 0.6 – Buscar Documentação Relacionada no Central Docs | `/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 rfc`) | Se `CENTRAL_DOCS_REPO` estiver definido **e** o usuário aprovar o RFC e responder "Sim, publicar agora" |
+
 ---
 
 ## Passo 0 – Definir se é novo RFC ou iteração

package/workflows/engineering/eng.debug.md

@@ -27,7 +27,7 @@ sempre respeitando `$IDE/rules/engineering/eng-rules.md`.
 
 ### Rules
 - **`$IDE/rules/engineering/eng-rules.md`** — regras obrigatórias de engenharia
-  - Inclui: Correlation ID obrigatório, fluxo downstream de cards, rigor por contexto (CDD)
+  - Inclui: Correlation ID obrigatório, autonomia no card, rigor por contexto (CDD)
 
 ### Skills invocados durante o workflow
 
@@ -38,7 +38,7 @@ sempre respeitando `$IDE/rules/engineering/eng-rules.md`.
 | Passo 1.5 | `Read` / `Grep` / `Glob` (leitura do repo) | **Sempre** — obrigatório antes de formular hipóteses |
 | Passo 2.5 | `/eng-backend-microservices-trace` | Se bug suspeito de cruzar serviços **e** a especialização estiver registrada em `BACKEND_SPECIALIZATIONS` |
 | Passo 6 | `/eng-qa-unit-test` | Para criar teste de regressão da correção |
-| Passo 7 | `/bug-report create` | Para cada débito técnico ou melhoria identificada |
+| Passo 7 | `/eng-qa-bug-report create` | Para cada débito técnico ou melhoria identificada |
 | Conclusão | `mcp__claude_ai_Atlassian__addCommentToJiraIssue` | Sempre — atualizar o card com findings |
 
 ### Próximos workflows (pós-debug)
@@ -427,7 +427,7 @@ Quando fizer sentido, recomendar:
 Para cada melhoria estrutural identificada, criar um card de débito técnico:
 
 ```
-/bug-report create \
+/eng-qa-bug-report create \
   --title="[{serviço}] {descrição da melhoria}" \
   --category="DÉBITO-TÉCNICO" \
   --location="{arquivo:linha relevante}" \

package/workflows/engineering/eng.docs.md

@@ -17,6 +17,15 @@ Quando a solicitação for diretamente sobre escrita/atualização de documenta
 
 Quando a solicitação for sobre organização/índice de documentação, use o skill `$IDE/skills/jarvis-docs-index/SKILL.md`.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Skills recomendados | `/eng-global-docs-write` | Se a solicitação for diretamente sobre escrita ou atualização de documentação |
+| Skills recomendados | `/jarvis-docs-index` | Se a solicitação for sobre organização ou índice de documentação |
+| Passo 1 — Ativar o contexto de Engenharia | `eng.agent` (agente) | Sempre |
+| Passo 2 — Ativar o agente de documentação | `eng.docs-writer` (agente) | Sempre |
+
 O assistente deve:
 
 1. Ativar o contexto de Engenharia:

package/workflows/engineering/eng.light-arch.md

@@ -11,6 +11,13 @@ model_justification: Design arquitetural requer análise de codebase, padrões e
 
 Este é o comando para disparar o início do desenho de estrutura arquitetural para uma feature.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Arquitetura (dicas) e Pesquisa | `context7` (MCP) | Se for necessário consultar melhores práticas ou a documentação de uma biblioteca; não adivinhar |
+| Pesquisa | `Perplexity` (MCP) | Se não houver certeza de como uma biblioteca específica funciona |
+
 ## Exame
 
 1. Passe pelos cards, pais e filhos se necessário, e construa um entendimento inicial do que precisa ser construído. Pense cuidadosamente sobre o que é solicitado, certifique-se de que entende exatamente:

package/workflows/engineering/eng.plan.md

@@ -2,7 +2,7 @@
 description: Planejamento de execução faseada para a feature
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.plan-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.plan-rules.md"
 template_file: "$IDE/templates/engineering/plan-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
@@ -13,6 +13,8 @@ model_justification: Planejamento detalhado requer decomposição de tarefas com
 
 Este workflow cria um **plano de execução detalhado e faseado** para implementar a feature de forma incremental.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.plan-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 ---
 
 ## Argumentos
@@ -34,6 +36,17 @@ Antes de executar este workflow:
 
 > 📁 **Padrão de pasta**: `{TASK_MANAGER_KEY}` é o ID do card em **lowercase** (ex: `TASK-123` → `task-123`)
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Fase 0 › 0.1 Herdar Contexto da Sessão | `/jarvis-context-detect` | Se `ENABLE_CDD=true` e o `context.md` não existir |
+| Fase 2: Pesquisa no Codebase | `repoprompt` (MCP: `search`, `read_selected_files`) | Para buscar e ler arquivos relevantes do codebase |
+| Fase 2: Pesquisa no Codebase (se necessário) | `context7` (MCP) | Se for preciso consultar a documentação de bibliotecas |
+| Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, após validar o plano com o usuário (freelance pula) |
+
 ---
 
 ## Fase 0.5: Comentário no card — Início
@@ -207,7 +220,7 @@ Após a validação do plano com o humano, informar:
 
 ## Regras Importantes
 
-- ⚠️ **Consulte** as regras completas em `$IDE/rules/engineering/eng.plan-rules.md`
+- ⚠️ **Consulte** as regras completas em `$IDE/rules-on-demand/engineering/eng.plan-rules.md`
 - ⏱️ **Fases de ~1 hora** - Não criar fases maiores
 - 🔄 **Incremental** - Cada fase deve entregar valor testável
 - 🗣️ **Validar** - Sempre confirmar o plano com o humano antes de prosseguir

package/workflows/engineering/eng.pr.md

@@ -2,7 +2,7 @@
 description: Criação de branch, commit e merge request (MR)
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.pr-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.pr-rules.md"
 template_file: "$IDE/templates/engineering/PR-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: medium
@@ -13,7 +13,7 @@ model_justification: Operações Git e preenchimento de templates são tarefas e
 
 Este comando cria a **branch, commita as alterações e abre um Merge Request**.
 
-> 📋 **Rules**: `$IDE/rules/engineering/eng.pr-rules.md`
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/PR-template.md`
 
 ## Skills recomendados
@@ -37,6 +37,22 @@ Este comando cria a **branch, commita as alterações e abre um Merge Request**.
   - Arquivo: `$IDE/agents/engineering/qa/eng.qa.test-planner.md`
   - Quando usar: Se houver dúvidas sobre cobertura de testes ou mudanças significativas.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
+| Skills recomendados | `/eng-global-pr` | Sempre — seguir o playbook do skill para padronizar branch, commits e MR |
+| Skills recomendados | `/eng-qa-test-plan` | Se for preciso validar lacunas de testes antes de abrir o MR |
+| Fase 1 › 1.4 Executar Testes Automatizados (Opcional) | `/eng-qa-testsprite` | Se o projeto estiver rodando localmente (`/eng-qa-testsprite diff`); passo opcional, recomendado em mudanças significativas |
+| Skills recomendados | `/eng-qa-e2e` | Se for preciso validar fluxos de usuário críticos com testes E2E em linguagem natural antes de abrir o MR |
+| Skills recomendados | `/eng-global-docs-write` | Se houver necessidade de atualizar documentação junto do PR |
+| Skills recomendados | `/eng-security-cybersecurity` | Se o PR tocar em auth, inputs, APIs públicas ou permissões (adicionar label `security` ao MR) |
+| Agentes recomendados (opcional) | `eng.qa.test-planner` (agente) | Se houver dúvidas sobre cobertura de testes ou mudanças significativas |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Fase 4 › 4.2 Criar MR/PR via adapter | `node bin/lib/vcs/create-merge.js` (CLI do Jarvis) | Sempre — abre o MR/PR conforme `VERSION_CONTROL` ou o host do `origin` |
+| Fase 5: Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, depois de o MR ser criado (freelance pula) |
+
 ---
 
 ## Entrada
@@ -266,13 +282,9 @@ Após MR criado com sucesso, registrar:
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).
 
-> Consultar `$IDE/rules/engineering/eng.downstream-flow-rules.md` para regras completas de transição.
-
 ### 6.1 Mover Card
 
-De acordo com o fluxo downstream, após abertura do MR o **DEV** (`JUNIOR` / `PLENO` / `SENIOR` / `SPECIALIST`) move o card para **"Review de código"**.
-
-> O próximo passo (**Pronto para QA**) é responsabilidade do **TECH LEAD**, após merge ou revisão do MR.
+Mova o card para a etapa equivalente a "em revisão" no seu board. Quem assumiu o card o move; não é preciso esperar o TECH LEAD ou o PM.
 
 ### 6.2 Adicionar Comentário
 

package/workflows/engineering/eng.pre-pr.md

@@ -2,7 +2,7 @@
 description: Validação de segurança para realizar um pull request ou merge request
 auto_execution_mode: 3
 env_file: "@/ENV.md"
-rules_file: "$IDE/rules/engineering/eng.pre-pr-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
 model_justification: Revisão multi-agente requer coordenação, análise de código, validação de testes e verificação de conformidade
@@ -12,6 +12,8 @@ model_justification: Revisão multi-agente requer coordenação, análise de có
 
 Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para um solicitação de integração. Agora, é hora de fazer verificações finais e limpezas para assegurar que estamos alinhados com nossos convenções e objetivos.
 
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.pre-pr-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
+
 ## Skills recomendados
 
 - **eng-qa-test-plan**: para avaliar cobertura de testes e identificar gaps antes do PR.
@@ -33,6 +35,30 @@ Estamos nos aproximando de finalizar o trabalho nesta branch e nos preparar para
 #$ARGUMENTS
 </arguments>
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Skills recomendados | `/eng-qa-test-plan` | Para avaliar cobertura de testes e identificar gaps antes do PR |
+| Skills recomendados | `/eng-global-docs-write` | Para atualizar a documentação com base nas mudanças da branch |
+| Skills recomendados | `/jarvis-docs-index` | Se for necessário atualizar o índice de documentação |
+| Skills recomendados | `/eng-devops-performance-engineer` | Se a feature tiver requisitos não-funcionais de latência, throughput ou escalabilidade |
+| Skills recomendados | `/eng-backend` e `/eng-frontend` (via `eng.specializations-rules.md`) | Para validar código de backend (endpoints, autenticação, workers) ou de frontend (componentes, performance de UI, WCAG 2.1 AA); a regra também carrega as especializações registradas no ENV.md |
+| Skills recomendados | `/eng-security-cybersecurity` | Se a branch tocar em auth, sessions, inputs, CORS, CSP, permissões ou adicionar dependências novas |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Gate 0: Verificar Documentação Central | `/jarvis-docs-central` (via `jarvis docs publish --tipo ard`) | Se `CENTRAL_DOCS_REPO` estiver configurado, houver mudança arquitetural, o ARD estiver desatualizado ou novo e o usuário aceitar publicar |
+| Gates › item 1 | `prod.pm-checker` (agente) | Sempre — verificar alinhamento da branch com os docs de produto e engenharia |
+| Gates › item 2 | `eng.dev-code-reviewer` (agente) | Sempre — revisar o código antes de lançar |
+| Gates › item 3 | `eng.qa.test-planner` (agente) | Sempre — identificar gaps de cobertura de testes na branch |
+| Gates › item 4 | `eng.qa.testing-engineer` (agente) | Se o test-planner identificar gaps críticos (escrever os testes faltantes) |
+| Gates › item 5 | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos não-funcionais (no `architecture.md` ou explícitos na task) |
+| Gates › item 6 | `/eng-qa-testsprite` | Sempre — `testScope=diff`, com `type=frontend` e/ou `type=backend` conforme o projeto |
+| Gates › item 7 | `eng.frontend.agent` (agente) | Se a branch tiver mudanças de interface (componentes, estilos, estado) |
+| Gates › item 8 | `eng.ux-designer.agent` (agente) | Se a branch introduzir nova feature de UI ou alterar fluxo de usuário |
+| Gates › item 9 | `eng.docs-writer` (agente) | Sempre — atualizar a documentação do projeto |
+| Gates › item 10 | `/eng.security-review` | Se a branch tocar em auth, sessions, inputs de usuário, CORS, CSP, permissões ou adicionar endpoints públicos |
+| Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, com o status final (freelance pula) |
+
 ## Fase 0.5: Comentário no card — Início
 
 Pular se `TASK_MANAGER` estiver vazio (freelance).

package/workflows/engineering/eng.review.md

@@ -36,6 +36,19 @@ apontando riscos, gaps e melhorias, sempre respeitando `$IDE/rules/engineering/e
   - Arquivo: `$IDE/agents/engineering/eng.ux-designer.agent.md`
   - Quando usar: PR que introduz nova feature de UI ou altera fluxo de usuário existente.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Skills recomendados | `/eng-qa-test-plan` | Se a revisão envolver mudanças de código (revisar cobertura de testes da branch e gaps) |
+| Skills recomendados | `/eng-backend` (via `eng.specializations-rules.md`) | Se a revisão envolver código de backend (endpoints, autenticação, workers, banco de dados); a regra também carrega as especializações de `BACKEND_SPECIALIZATIONS` |
+| Skills recomendados | `/eng-frontend` (via `eng.specializations-rules.md`) | Se a revisão envolver código de frontend (componentes, estado, estilos, performance de UI, acessibilidade); a regra também carrega as especializações de `FRONTEND_SPECIALIZATIONS` |
+| Skills recomendados | `especialização de arquitetura registrada em BACKEND_SPECIALIZATIONS` | Se houver mudança arquitetural relevante que exija atualizar diagramas e existir essa especialização registrada; sem ela, descrever a mudança no documento de arquitetura |
+| Passo 6 › Validação com TestSprite (opcional) | `/eng-qa-testsprite` | Se o projeto estiver rodando localmente (`/eng-qa-testsprite diff`) |
+| Passo 6 › Análise de Cobertura (opcional) | `eng.qa.test-planner` (agente) | Se a revisão identificar problemas de cobertura que exijam análise mais profunda |
+| Agentes recomendados | `eng.frontend.agent` (agente) | Se o PR tiver mudanças significativas de interface ou componentes |
+| Agentes recomendados | `eng.ux-designer.agent` (agente) | Se o PR introduzir nova feature de UI ou alterar fluxo de usuário existente |
+
 ---
 
 ## Passo 1 – Entender o objetivo da mudança

package/workflows/engineering/eng.rpa.robot.md

@@ -16,6 +16,22 @@ Workflow unificado para criação (`new`) ou manutenção (`update`) de robôs d
 > 📋 **Docs**: `$IDE/rules/engineering/eng.docs-scraping-rules.md`
 > 🤖 **Agente**: ARACHNE (`$IDE/agents/engineering/eng.rpa.agent.md`)
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.rpa.agent` (agente) | Sempre — agente ARACHNE do workflow |
+| Fase 0 — Setup | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md |
+| Modo `new` › Exploração do sistema-alvo | `Playwright MCP` | Se o MCP Playwright estiver disponível na sessão (com `MAX_AI_EXECUTION_PERCENTAGE=100`, escolhido automaticamente; senão o dev escolhe a ferramenta) |
+| Modo `new` › Exploração do sistema-alvo | `/eng-scraper-robot-builder` | Se o fluxo for descrito em linguagem natural com seletores desconhecidos (com MAX=100: só se o MCP estiver indisponível) |
+| Modo `new` › Fase N1 — escolha da ferramenta do robô | `/eng-scraper-robot-builder` | Se o fluxo for descrito em linguagem natural e os seletores forem desconhecidos (Stagehand) |
+| Modo `new` › Fase N2 — Plano de Execução | `/eng.plan` | Sempre no modo `new`, depois de o `architecture.md` ser aprovado |
+| Modo `new` › Fase N3 — Implementação | `/eng.work` | Sempre no modo `new`, depois do plano |
+| Modo `new` › Fase N4 — Documentação | `/jarvis-docs-index` | Sempre, após criar o `{robot-tag}-robot.md` |
+| Modo `new` › Fase N5 — Pre-PR e PR | `/eng.pre-pr` | Sempre no modo `new`, ao final da implementação |
+| Modo `new` › Fase N5 — Pre-PR e PR | `/eng.pr` | Sempre no modo `new`, depois do pre-PR |
+| Modo `update` › Fase U2 (se a mudança envolve o sistema-alvo) | `Playwright MCP` | Se o MCP Playwright estiver disponível na sessão |
+
 ---
 
 ## Entrada

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

@@ -55,6 +55,13 @@ Onde [escopo] pode ser:
 - Foco especifico: --focus=owasp|secrets|supply-chain|headers|compliance
 ```
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Fase 0 – Analise de Contexto (CDD) | `/jarvis-context-detect` | Se existir uma sessão ativa (e `ENABLE_CDD=true` no ENV.md) |
+| Fase 3 – Analysis (OWASP Top 10) | `/eng-security-cybersecurity` | Sempre — como referência de padrões para cada vetor relevante |
+
 ---
 
 ## Fase 0 – Analise de Contexto (CDD)

package/workflows/engineering/eng.security-incident.md

@@ -48,6 +48,12 @@ Onde [referencia] pode ser:
 - Card do $TASK_MANAGER: TASK-1234
 ```
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Fase 4 – Remediation › 4.1 Implementar correcao | `/eng-security-cybersecurity` | Sempre — como referência de padrões seguros ao implementar a correção |
+
 ---
 
 ## Fase 1 – Triage

package/workflows/engineering/eng.security-pipeline.md

@@ -22,6 +22,15 @@ Guiar o SENTINEL pelo pipeline defensivo completo de segurança, encadeando os 4
 - Onboarding de segurança em projeto sem histórico de audit
 - Quando o usuário pede "auditar segurança", "pipeline completo" ou "fechar o loop"
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Passo 2 › Estágio 1 — Threat Model | `/eng-security-threat-model` | Se o estágio 1 for selecionado no menu de entrada (modo bootstrap, interview ou bootstrap-then-interview, escolhido pelo usuário) |
+| Passo 2 › Estágio 2 — Security Audit | `/eng.security-audit` | Se o estágio 2 for selecionado no menu de entrada (usa o `THREAT_MODEL.md` como contexto, se existir) |
+| Passo 2 › Estágio 3 — Triage | `/eng-security-triage` | Se o estágio 3 for selecionado no menu de entrada (entrada: `security-findings.json`) |
+| Passo 2 › Estágio 4 — Patch | `/eng-security-patch` | Se o estágio 4 for selecionado no menu de entrada (entrada: `triage.json`) |
+
 ---
 
 ## Passo 0 — Detectar estado do pipeline

package/workflows/engineering/eng.security-review.md

@@ -41,6 +41,12 @@ Onde [referencia-do-pr] pode ser:
 - Branch: feature/nova-auth
 ```
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| — | Nenhuma — workflow autocontido | — |
+
 ---
 
 ## Fase 1 – Scope

package/workflows/engineering/eng.start.md

@@ -2,7 +2,7 @@
 description: Inicia o planejamento de uma tarefa criando o architecture.md
 auto_execution_mode: 3
 agent: "$IDE/agents/engineering/eng.agent.md"
-rules_file: "$IDE/rules/engineering/eng.start-rules.md"
+rules_file: "$IDE/rules-on-demand/engineering/eng.start-rules.md"
 template_file: "$IDE/templates/engineering/architecture-template.md"
 recommended_model: claude-sonnet-4-20250514
 model_tier: high
@@ -13,13 +13,31 @@ model_justification: Requer análise arquitetural profunda, investigação de co
 
 Este comando inicia o **planejamento** de uma nova feature.
 
-> 📋 **Rules**: `$IDE/rules/engineering/eng.start-rules.md`
+> 📋 **Rules**: `$IDE/rules-on-demand/engineering/eng.start-rules.md` — **antes de começar, leia esse arquivo e siga-o**: ele não é carregado automaticamente no início da sessão.
 > 📤 **Template**: `$IDE/templates/engineering/architecture-template.md`
 
 > ⚠️ **IMPORTANTE**: Este workflow é APENAS para planejamento e documentação.
 > **NÃO execute código, NÃO crie arquivos de código, NÃO faça commits.**
 > O único artefato a ser criado é o `architecture.md`.
 
+### Skills invocados durante o workflow
+
+| Passo | Skill | Condição |
+|-------|-------|----------|
+| Cabeçalho (agente) | `eng.agent` (agente) | Sempre — identidade do workflow |
+| Fase 0.1: Análise de Contexto (CDD) | `/jarvis-context-detect` | Se `ENABLE_CDD=true` no ENV.md (execução obrigatória antes da Fase 1); `ENABLE_CDD=false` pula |
+| Fase 0.5: Comentário no card — Início | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido (freelance pula) |
+| Fase 2.2: Buscar Documentação Central | `/jarvis-docs-central` | Se `CENTRAL_DOCS_REPO` estiver configurado no ENV.md (buscar PRD, ARD e RFCs relacionados) |
+| Fase 3.4: Estratégia de Testes | `eng.qa.test-architect` (agente) | Se a feature tiver requisitos de performance ou segurança (APIs públicas, dados sensíveis, alta carga ou requisitos não-funcionais explícitos) |
+| Fase 3.4: Estratégia de Testes | `/eng-devops-performance-engineer` | Se a feature tiver requisitos de performance (latência, throughput, escalabilidade) |
+| Fase 3.4: Estratégia de Testes | `/eng-ai-engineer` | Se a feature envolver IA (LLM, RAG, agentes, chatbots, embeddings) |
+| Fase 3.4: Estratégia de Testes | `/eng-frontend` (via `eng.specializations-rules.md`) | Se a feature envolver interface ou componentes frontend; a regra também carrega as especializações de `FRONTEND_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-backend` (via `eng.specializations-rules.md`) | Se a feature envolver APIs, autenticação ou workers backend; a regra também carrega as especializações de `BACKEND_SPECIALIZATIONS` |
+| Fase 3.4: Estratégia de Testes | `/eng-data-engineer` | Se a feature envolver engenharia de dados (pipelines ETL/ELT, Glue, Airflow, contratos de dados, camadas bronze/silver/gold) |
+| Fase 3.4: Estratégia de Testes | `/eng-scraper` | Se a feature envolver extração de dados ou scraping |
+| Fase 3.4: Estratégia de Testes | `/eng-security-cybersecurity` | Se a feature envolver autenticação, autorização, inputs de usuário, dados sensíveis ou endpoints públicos |
+| Fase 5.4: Comentário no card — Conclusão | `/eng-global-task-comment` | Se `TASK_MANAGER` estiver preenchido, após o usuário aprovar o `architecture.md` (freelance pula) |
+
 ---
 
 ## Entrada
@@ -382,11 +400,9 @@ Se o usuário tiver feedback:
 
 ### 5.3 Atualizar Board
 
-> Consultar `$IDE/rules/engineering/eng.downstream-flow-rules.md` para regras completas de transição.
-
-De acordo com o fluxo downstream, ao assumir este card o **DEV** (`JUNIOR` / `PLENO` / `SENIOR` / `SPECIALIST`) deve mover o card para **"Em progresso"**.
+Pular se `TASK_MANAGER` estiver vazio (freelance).
 
-> Este é o sinal de que a entrega está em andamento e o DEV assumiu a responsabilidade ponta-a-ponta.
+Se estiver preenchido, mova o card para a etapa equivalente a "em andamento" no seu board. Quem assumiu o card conduz a entrega; ninguém precisa liberar a transição.
 
 ### 5.4 Comentário no card — Conclusão