jarvis-ai-framework 7.0.0 → 8.2.0

package/skills/eng-global-tech-spec/references/delivery-spec.md

@@ -44,7 +44,7 @@ B: História / Task — implementação específica, pronta para desenvolvimento
 
 **Se recebeu URL/ID do $TASK_MANAGER:**
 
-- Busque o card usando a API ou ferramenta disponível
+- Leia o card pela CLI oficial do `$TASK_MANAGER` (ação `view` do catálogo, `eng.integrations-rules.md`), sem REST nem MCP; sem acesso, peça para colar o conteúdo
 - **Épico**: extraia título, descrição, objetivo de negócio, escopo e iniciativa relacionada
 - **História**: extraia título, descrição, critérios de aceitação, épico relacionado, comentários relevantes
 
@@ -322,8 +322,8 @@ Use as ferramentas de busca para identificar:
 
 Verifique se há documentação relevante:
 
-- **PRD relacionada**: `$DOCS_FOLDER/**/*prd*.md` ou anexos no Jira
-- **FRD relacionada**: `$DOCS_FOLDER/**/*frd*.md` ou anexos no Jira
+- **PRD relacionada**: `$DOCS_FOLDER/**/*prd*.md` ou anexos no card (lidos pela CLI ou colados pelo usuário)
+- **FRD relacionada**: `$DOCS_FOLDER/**/*frd*.md` ou anexos no card (lidos pela CLI ou colados pelo usuário)
 - **ADRs (Architecture Decision Records)**: `$DOCS_FOLDER/ARD/*.md` ou `./sessions/**/adr.md`
 - **README e documentação técnica**: `README.md`, `ARCHITECTURE.md`, `API.md`
 
@@ -671,7 +671,7 @@ Para cada caso extremo/erro:
 
 Exemplo: `$SESSIONS_DIR/eng/story-123/tech-spec.md`
 
-> **IMPORTANTE**: A tech spec é salva na sessão e anexada no Jira. O Jira é a fonte da verdade, não o repositório.
+> **IMPORTANTE**: A tech spec é salva na sessão. O anexo na issue é opcional e só sai na 6.4, depois da aprovação final e da pergunta.
 
 #### 6.2 Revisão de Qualidade
 
@@ -707,17 +707,23 @@ Apresente ao usuário:
 
 **Aguarde aprovação final do usuário.**
 
+#### 6.4 Anexo da tech spec na issue (opcional, com pergunta)
+
+Só com board configurado (no freelance não há issue: pule este passo). Só há pergunta quando o anexo vai sair: no Jira, com a `acli` logada que anexa arquivo (confira no `--help`) e `TASK_MANAGER_ACCESS=cli` (ou vazio). Nesse caso: para anexá-la na issue do board, depois da aprovação da 6.3, mostre o que vai e pergunte com `AskUserQuestion` (regra de ouro, `eng.integrations-rules.md`): **Sim, anexar** / **Não, manter só na sessão**; com o Sim, anexe pela `acli`; sem o Sim, a tech spec fica só na sessão. Nos demais casos (Jira sem a `acli` logada, `acli` que não anexa, acesso manual, GitHub ou GitLab, cuja CLI não anexa arquivo à issue) não há envio e, portanto, nenhuma pergunta: oriente a pessoa a anexar à mão. A mensagem da 8.2 diz o que aconteceu.
+
 ---
 
 ### ═══════════════════════════════════════════════
 
-### FASE 7: Criação de Subtarefas no Jira
+### FASE 7: Criação de Subtarefas (automática só no Jira)
 
 ### ═══════════════════════════════════════════════
 
+> **Escopo:** a criação automática de subtarefas é só no Jira, pela `acli`. Em GitHub ou GitLab, ou no Jira sem a `acli` logada ou com `TASK_MANAGER_ACCESS=manual`, esta fase entrega o template formatado e as instruções para a pessoa criar as subtarefas à mão; como não há envio, a 7.3 não faz a pergunta nesse caso. A generalização para `gh`/`glab` fica para uma issue à parte.
+
 #### 7.1 Preparação para Criação
 
-**Se o projeto usa Jira e a `acli` está logada (`acli jira workitem create`, conferindo os flags no `--help`), ou há uma ferramenta MCP do Jira configurada à mão:**
+**Se o projeto usa Jira, a `acli` está logada e `TASK_MANAGER_ACCESS=cli` ou vazio (vazio vale como `cli`, com o aviso do `/jarvis-init`), com `acli jira workitem create` (conferindo os flags no `--help`; a criação só sai na 7.3, depois da pergunta, regra de ouro):**
 
 Para cada subtarefa no plano:
 
@@ -729,26 +735,27 @@ Para cada subtarefa no plano:
 - Estimativa: {X horas}
 - Labels: `tech-spec`, `{área}` (ex: backend, frontend)
 
-#### 7.2 Estrutura da Descrição no Jira
+#### 7.2 Estrutura da Descrição no board
+
+Use o formato **Descrição da subtarefa no board** 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).
 
-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 (Jira pela `acli`; outros boards, template)
 
-#### 7.3 Criação no Jira
+Só há pergunta quando a criação vai sair: no Jira, com a `acli` logada e `TASK_MANAGER_ACCESS=cli` (ou vazio). Nos demais casos (fora do Jira, sem a `acli` ou com acesso manual) não há envio e, portanto, nenhuma pergunta: entregue o template formatado direto. Quando a criação vai sair, antes de criar as subtarefas, mostre o texto e pergunte com `AskUserQuestion` (**Sim, publicar** / **Não, manter só na sessão**), regra de ouro de `eng.integrations-rules.md`; sem o Sim, entregue só o template formatado e deixe o texto na sessão. O comentário da 7.4 tem a sua própria pergunta, feita pelo `/eng-global-task-comment`.
 
-**Se houver API/ferramenta disponível:**
+**No Jira, com a `acli` logada, `TASK_MANAGER_ACCESS=cli` (ou vazio) e o Sim:**
 
-- Use para criar subtarefas automaticamente
-- Vincule à história pai
-- Configure dependências entre subtarefas
+- Crie as subtarefas com `acli jira workitem create` (flags no `--help`)
+- Vincule à história pai e configure as dependências entre subtarefas no que a `acli` permitir (com o Sim acima); o resto vai no template manual abaixo
 
-**Se não houver ferramenta:**
+**Em GitHub/GitLab, sem a `acli` logada (ou com `TASK_MANAGER_ACCESS=manual`), ou sem o Sim:**
 
-- Forneça ao usuário **template formatado** para copiar/colar no Jira
+- Forneça ao usuário **template formatado** para copiar/colar no board (Jira, GitHub ou GitLab)
 - Forneça **instruções passo-a-passo** para criação manual
 
 #### 7.4 Atualização da História Original
 
-Adicione comentário na história original (STORY-XXX) com:
+Publique o comentário na história original (STORY-XXX) com o `/eng-global-task-comment`, que mostra o texto e pergunta (regra de ouro). O comentário segue este formato:
 
 Use o formato **Comentário na história original** de `$IDE/templates/engineering/tech-spec-delivery-template.md`.
 
@@ -766,10 +773,10 @@ Valide que:
 
 - [ ] Tech Spec completa e aprovada pelo usuário
 - [ ] Arquivo salvo na sessão: `$SESSIONS_DIR/eng/{feature-name}/tech-spec.md`
-- [ ] Tech Spec anexada na issue do Jira
+- [ ] Tech Spec anexada na issue (com o Sim), a anexar pela pessoa (orientado) ou deixada na sessão
 - [ ] Subtarefas documentadas com critérios claros
-- [ ] Subtarefas criadas no Jira (ou template fornecido)
-- [ ] História original atualizada com link para tech spec
+- [ ] Subtarefas criadas no Jira pela `acli`, ou template fornecido (outros boards, sem a CLI, com acesso manual, sem o Sim ou sem board)
+- [ ] História original atualizada com link para tech spec (com o Sim do comentário da 7.4) ou texto deixado na sessão
 - [ ] Decisões arquiteturais documentadas
 - [ ] Riscos identificados e mitigados
 - [ ] Dependências mapeadas
@@ -800,7 +807,7 @@ Use o formato **Mensagem de entrega** de `$IDE/templates/engineering/tech-spec-d
 - `$SESSIONS_DIR/eng/**/*.md` - Tech specs e ADRs de sessões anteriores
 - `README.md` - Visão geral do projeto
 - `ARCHITECTURE.md` - Arquitetura do sistema (se existir)
-- Anexos no Jira - PRD, FRD, ARD, RFC
+- Anexos no card (lidos pela CLI ou colados) - PRD, FRD, ARD, RFC
 
 ### Templates
 
@@ -821,7 +828,7 @@ O diagrama do fluxo (épico x história, fases 0 a 8) está na seção **Fluxo r
 
 → Liste o que falta e peça ao usuário para completar
 
-### Se não conseguir acessar o Jira:
+### Se não conseguir acessar o card no board:
 
 → Peça ao usuário para copiar/colar o conteúdo da história
 

package/skills/jarvis-docs-central/README.md

@@ -5,7 +5,7 @@ Integração com o **Central docs**: o registro do que **foi implementado** em c
 ## Visão Geral
 
 - **Buscar** o que já foi implementado (`jarvis docs sync`, `jarvis docs fetch`)
-- **Publicar** a consolidação de cada entrega (`jarvis docs publish`, pelo `/eng.spec-consolidate`)
+- **Publicar** a consolidação de cada entrega (`jarvis docs publish`, pelo `/eng.spec-consolidate`, depois da pergunta)
 - **Índice** regenerado a cada publicação (`{SQUAD}/index.md`)
 
 O Central docs funciona por **adaptador de armazenamento**: hoje uma pasta do disco (`filesystem`). Se essa pasta for um clone de um repositório de documentação (tem `.git`), a publicação vira branch + commit + push + Pull/Merge Request. S3 e Google Drive são as issues #144 e #145.
@@ -27,7 +27,7 @@ WORKSPACE=loja                           # vira a pasta do produto
 
 A pasta padrão é `docs/jarvis/central-docs` nos dois modos de trabalho, junto dos documentos de trabalho. No projeto único, `docs/jarvis/` no `.gitignore` a deixa fora do versionamento; no workspace (vários repositórios) a raiz não é versionada. Quem já usa `./central-docs` continua funcionando, e o Upgrade do `/jarvis-init` oferece mover a pasta.
 
-> Com `.git`, o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela (`gh auth login`, `glab auth login`). Sem a CLI, ou com `VERSION_CONTROL_ACCESS` `manual`/inválido no `ENV.md` do projeto, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. Nenhum token vai no chat nem no `ENV.md`.
+> Com `.git` (e só depois da pergunta do `/eng.spec-consolidate`, regra de ouro), o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela (`gh auth login`, `glab auth login`). Sem a CLI, ou com `VERSION_CONTROL_ACCESS` `manual`/inválido no `ENV.md` do projeto, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. Nenhum token vai no chat nem no `ENV.md`.
 
 **Vindo da versão anterior (Central docs como repositório remoto)?** Rode `/jarvis-init` → Upgrade (C). Ele propõe `CENTRAL_DOCS_STORAGE=filesystem`, a pasta padrão e o `git clone` do repositório antigo.
 
@@ -36,8 +36,8 @@ A pasta padrão é `docs/jarvis/central-docs` nos dois modos de trabalho, junto
 ```bash
 jarvis docs sync                                  # resumo: funcionalidades e entregas recentes
 jarvis docs fetch CORE/index.md                   # conteúdo de um arquivo (exit 2 se não existir)
-jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate
-jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery
+jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature            # pelo /eng.spec-consolidate, depois do Sim (regra de ouro)
+jarvis docs publish --file .../consolidation/delivery-2026-10-15-task-123.md --tipo delivery  # idem
 ```
 
 - **Tipos:** só `feature` (vai para `product/`) e `delivery` (vai para `engineering/`). PRD, ARD, SPEC e os outros documentos de trabalho são recusados, com a explicação de que ficam em `docs/jarvis/`.

package/skills/jarvis-docs-central/SKILL.md

@@ -24,7 +24,7 @@ Integrar os comandos do framework com o **Central docs**: o registro do que **de
 | Documentos de trabalho | PRD, FRD, épicos, histórias, ARD, RFC, SPEC, QA, swagger, robôs, C4: o que se pretende e se discute | `docs/jarvis/` (`$PROD_DOCS`, `$ENG_DOCS`), fora do versionamento |
 | **Central docs** | O que foi implementado: um documento **completo e autossuficiente** por funcionalidade (estado atual) e um **registro por entrega** (PR, commits, autores) | Pasta do Central docs (adaptador) |
 
-Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator`), depois do merge do PR. Os documentos de trabalho nunca são publicados lá.
+Quem escreve no Central docs é o **`/eng.spec-consolidate`** (agente `eng.docs-consolidator.agent`), depois do merge do PR. Os documentos de trabalho nunca são publicados lá.
 
 **Modos deste skill:**
 - buscar o que já foi implementado (Modo 1);
@@ -56,6 +56,8 @@ Ler do `$IDE/ENV.md`:
 - `CENTRAL_DOCS_REF`, `CENTRAL_DOCS_TARGET_BRANCH`, `CENTRAL_DOCS_REVIEWERS` (só com `.git`)
 - `SQUAD` (ALL-CAPS-COM-HIFEN) e `WORKSPACE` (vira a pasta do produto)
 
+O `jarvis docs publish` só roda depois da pergunta do `/eng.spec-consolidate` (regra de ouro, `rules/engineering/eng.integrations-rules.md`).
+
 Com `.git`, o PR é aberto pela CLI do host (`gh pr create` / `glab mr create`), com o login dela, respeitando o `VERSION_CONTROL_ACCESS` do `ENV.md` do projeto (não do repositório do Central docs). Sem a CLI, sem login, ou com `manual`/valor inválido/ENV.md ilegível, a branch fica no remote e a publicação mostra o link para abrir o MR à mão. ❌ **Nunca** colar token no chat nem gravar no `ENV.md`.
 
 ---
@@ -157,12 +159,12 @@ jarvis docs publish --file .../consolidation/feature-checkout.md --tipo feature
 1. Validar o frontmatter.
 2. Calcular o destino.
 3. Sem `.git`: copiar e regenerar o índice.
-4. Com `.git`: branch, cópia, índice, commit, push e PR.
+4. Com `.git`: branch, cópia, índice, commit, push e PR (só depois da pergunta, regra de ouro).
 
 ### Modo 3: Reparar o índice
 
 - **Sem `.git`:** a próxima publicação regenera o índice.
-- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}`.
+- **Com `.git`:** no clone, rodar `bash scripts/build-index.sh` (se existir) e abrir um PR `repair/index-{SQUAD}-{data}` (só depois de mostrar o que será enviado e perguntar, regra de ouro).
 
 ### Skills invocados durante a execução do skill
 

package/skills/jarvis-evolution-architect/references/exemplos.md

@@ -152,7 +152,7 @@ Consolidar skills **não é a resposta**. Problema é **organização e document
 **O Que Eu Mudaria:**
 1. Criar um **INDEX.md** principal que agrupa skills por contexto
 2. Adicionar tags em metadatas das skills
-3. Criar uma skill `/jarvis-find-skill` que busca
+3. Criar uma skill de busca de skills (hipotética; não existe no framework)
 4. Melhorar `metadata.area` e `metadata.tags`
 
 **O Que Eu Não Faria:**
@@ -263,7 +263,7 @@ Quando você invoca a skill:
 ```
 "Qual skill devo usar para X?"
 ```
-❌ Isso não é pergunta arquitetural. Use `/jarvis-find-skill` em vez disso.
+❌ Isso não é pergunta arquitetural. Consulte o mapeamento comando → skill em `skills/AGENTS.md` em vez disso.
 
 ### ✅ Fazer isso:
 ```
@@ -286,7 +286,7 @@ Quando você invoca a skill:
 | "Devo criar um novo agent?" | ✅ SIM |
 | "Essa feature deveria ser skill ou workflow?" | ✅ SIM |
 | "Acho que essa feature está complexa demais" | ✅ SIM |
-| "Qual skill usa para X?" | ❌ NÃO (use `/jarvis-find-skill`) |
+| "Qual skill usa para X?" | ❌ NÃO (consulte `skills/AGENTS.md`) |
 | "Como implement feature X?" | ❌ NÃO (use skill específica) |
 | "Devemos adotar X tendência?" | ✅ SIM |
 | "Qual a diferença entre SDD e CDD?" | ✅ SIM |

package/skills/jarvis-init/SKILL.md

@@ -29,6 +29,7 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 8. **Autonomia** — qualquer `POSITION` (JUNIOR…CTO / PM) pode rodar o card ponta a ponta (`/eng.start` → `/eng.pr`). Sem gate obrigatório de TL/PM no init.
 9. **Fonte do ENV** — só `templates/ENV-template.md`. Não inventar variáveis. `JARVIS_PROJECT` default: `https://github.com/phelipperibeiro/jarvis-framework` (sempre a URL completa; trocar só para um fork interno).
 10. **IDEs** — windsurf, claude, cursor, codex, opencode, gemini/antigravity, kiro.
+11. **Instalação só global** — `npm install -g jarvis-ai-framework`. O `jarvis init` roda dentro do projeto e copia os assets do Jarvis global; cópia local no projeto (`node_modules` ou dependência no `package.json`) é ignorada. Antes de tudo, confira a versão (Passo 0).
 
 ## Objetivo
 
@@ -59,6 +60,8 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 ```
 ┌─────────────────────────────────────────────────────────────┐
 │                                                             │
+│  0. CONFERIR VERSÃO → jarvis-lock.json × jarvis --version   │
+│        ↓                                                    │
 │  1. DETECTAR IDE → Identificar ambiente                     │
 │        ↓                                                    │
 │  2. VERIFICAR → Se ENV.md já existe                         │
@@ -79,6 +82,8 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 │        ↓                                                    │
 │  9. STACKS → Adicionar as stacks (opcional, pulável)        │
 │        ↓                                                    │
+│  9.5 VALIDAR ENV.md → Arquivo inteiro × template (sempre)   │
+│        ↓                                                    │
 │  10. CONFIRMAR → Com usuário                                │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘
@@ -88,6 +93,21 @@ Regras que **substituem** qualquer trecho legado deste skill ou dos assets:
 
 ## Fluxo de Trabalho Detalhado
 
+### 0. Conferir a versão (antes de tudo)
+
+O texto deste skill e dos assets em `$IDE/` é o da versão que fez o último sync (`jarvis-lock.json`). Se ela estiver atrás do Jarvis global, você estaria seguindo regras antigas.
+
+1. Leia o `version` do `jarvis-lock.json` da pasta do workspace. Sem o arquivo, o projeto é novo: siga para o Passo 1.
+2. Rode `jarvis --version` (o Jarvis global). Sem o `jarvis` no PATH, explique que o Jarvis é instalado só global (`npm install -g jarvis-ai-framework`) e pergunte com `AskUserQuestion` se segue mesmo assim (**Instalar antes** | **Seguir assim mesmo**).
+3. Compare as duas versões (`x.y.z`):
+   - **Lock mais antigo que o global:** explique em uma frase ("os assets deste projeto são da {lock}; o seu Jarvis global é a {global}") e pergunte com `AskUserQuestion`: **Atualizar os assets agora (Recomendada)** | **Seguir assim mesmo**. Para atualizar, na pasta do workspace:
+     - com `$IDE/ENV.md`: `jarvis init --upgrade --ide {ide}`;
+     - sem `$IDE/ENV.md` (o projeto passou pelo `jarvis init` e ainda não pelo `/jarvis-init`): `jarvis init --ide {ide} --force`, porque o `--upgrade` exige o `ENV.md`.
+
+     Depois, recomece este skill pelo Passo 0, porque o texto dele pode ter mudado.
+   - **Lock mais novo que o global:** avise que o Jarvis global está desatualizado (`npm install -g jarvis-ai-framework`) e siga. Não rode o `jarvis init` com esse global: ele rebaixaria os assets.
+   - **Iguais:** siga.
+
 ### 1. Resolver identidade local (sem login)
 
 Não existe OAuth. `USER` vem do ambiente local.
@@ -186,14 +206,15 @@ Identificar qual IDE o usuário está utilizando:
    ⚠️ O arquivo ENV.md já existe. O que deseja fazer?
    A: Sobrescrever completamente
    B: Atualizar apenas variáveis específicas
-   C: Upgrade — adicionar variáveis novas do template (não toca nos valores existentes)
+   C: Upgrade — adicionar variáveis novas do template (não troca valor existente sem a sua resposta)
    D: Cancelar
    ```
+   A (que segue o fluxo completo), B e C terminam pelo **passo 9.5 (validar o ENV.md)**; D não toca no arquivo.
 
 **Se opção C (Upgrade):**
 
 > No terminal, rode antes `jarvis init --upgrade --ide {ide}`: ele atualiza os arquivos do framework, acrescenta as variáveis novas e move os documentos para as pastas novas (itens 1–8, 10 a 12). Aqui ficam o Central docs antigo (item 9), as pendências que ele listar e o passo das stacks.
-> **O upgrade só acrescenta chaves novas:** nenhuma chave já existente, preenchida ou não, é alterada, salvo as exceções declaradas no item 9 (`CENTRAL_DOCS_LOCATION` e `TOKEN_TASK_MANAGER`, com confirmação; `JARVIS_PROJECT` vazio, automático).
+> **O upgrade só acrescenta chaves novas:** nenhuma chave já existente, preenchida ou não, é alterada, salvo as exceções declaradas no item 9 (`CENTRAL_DOCS_LOCATION` e `TOKEN_TASK_MANAGER`, com confirmação; `JARVIS_PROJECT` vazio, automático). Depois, a validação final (passo 9.5) pode reorganizar o arquivo, mover chaves para o assunto delas e corrigir valores fora das opções, sempre perguntando: nenhum valor muda sem a resposta da pessoa.
 > Trocou o `ARTIFACT_STYLE` (ou HUB, POSITION, AREA, SQUAD) à mão? O Passo 8 copia ou remove as rules desse perfil.
 
 1. Ler todas as chaves do `templates/ENV-template.md`
@@ -205,14 +226,14 @@ Identificar qual IDE o usuário está utilizando:
    ```
    ✅ ENV.md já está atualizado. Nenhuma variável nova encontrada.
    ```
-   Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar.
+   Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, rodar o **passo 9.5 (validar o ENV.md)** e então encerrar.
 7. Se houver diff, exibir prévia:
    ```
    🔍 Variáveis novas encontradas no template:
      + NOVA_VAR_1=
      + NOVA_VAR_2=valor-padrão
 
-   Serão adicionadas ao final do ENV.md sem alterar os valores existentes.
+   Serão adicionadas no assunto de cada uma, na posição do template, sem alterar os valores existentes.
    ```
 8. **Exceção — documentos nos caminhos antigos:** procure documentos de trabalho em `$DOCS_FOLDER/product`, `$DOCS_FOLDER/engineering/{ARD,RFC,qa,swagger,openapi,robots,c4}`, `docs/engineering/{robots,swagger,openapi,c4}` e os discoveries em `$PROD_DOCS/discoveries/`.
    - Se houver, liste o que encontrou e pergunte com `AskUserQuestion` (uma pergunta para todos) se move para `docs/jarvis/…` (`$PROD_DOCS`, `$ENG_DOCS/…` e, para os discoveries, `$DISCOVERIES_DOCS`). Use `git mv` quando o arquivo for versionado e `mv` quando não for e, só se a raiz do workspace tiver `.git`, garanta `docs/jarvis/` no `.gitignore`.
@@ -228,18 +249,13 @@ Identificar qual IDE o usuário está utilizando:
 10. **Exceção — `PROD_MODE`:** se `PROD_MODE` estiver entre as chaves novas, grave pelo `AREA`: `ENGINEERING` → `developer-guided`, `PRODUCT` → `product-led`. Com outra `AREA` (ou vazia), faça a mesma pergunta do Passo 3 (Pergunta 8 — modo de condução) e grave a resposta. `PROD_MODE` que já existe, mesmo vazia, não muda. As demais chaves continuam sem pergunta.
     - **`WORKSPACE_MODE`:** o `jarvis init --upgrade` já grava o modo detectado (raiz sem `.git` e 1+ subpastas com `.git/` = `workspace`; raiz com `.git` = `project`). Se a chave existir vazia, detecte do mesmo jeito e grave; se existir preenchida, não muda.
     - **`.gitignore` numa raiz sem `.git` (ex.: `WORKSPACE_MODE=workspace`):** a raiz não é versionada, então esse arquivo não tem efeito. Não o apague; só avise: `ℹ️ O .gitignore da raiz do workspace não tem efeito (a raiz não é um repositório). Pode removê-lo se quiser.`
-11. Appender as novas variáveis ao final do `ENV.md` com comentário de data:
-   ```
-   # --- Upgrade YYYY-MM-DD ---
-   NOVA_VAR_1=
-   NOVA_VAR_2=valor-padrão
-   ```
+11. Acrescentar as novas variáveis no assunto de cada uma, na posição do template, junto das chaves do mesmo assunto (ex.: uma `DATA_*` nova vai para o bloco Data Engineering, ao lado das irmãs), com o comentário do template. Sem bloco datado no fim. O `jarvis init --upgrade` (terminal) acrescenta no fim, num bloco `# --- Upgrade ... ---`, por ser determinístico; o passo 9.5 põe essas chaves no lugar.
 12. Confirmar:
    ```
    ✅ ENV.md atualizado! N variável(is) nova(s) adicionada(s).
    ⚠️ Preencha os valores em branco antes de usar os novos recursos.
    ```
-13. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, e então encerrar (não continuar para o fluxo de onboarding completo).
+13. Oferecer o **passo 9 (adicionar as stacks)**, que a pessoa pode pular, rodar o **passo 9.5 (validar o ENV.md)** e então encerrar (não continuar para o fluxo de onboarding completo).
 
 **⚠️ OBRIGATÓRIO - Criação do ENV.md**:
 
@@ -632,7 +648,6 @@ Se **A** ou **B**, perguntar sobre cada variável opcional conforme seleção
 | `SMTP` | *(vazio)* | `google`, `ses`, `sendgrid` |
 | `CODE_QUALITY_TOOL` / `_URL` / `_TOKEN` | *(vazio)* | SonarQube etc. |
 | `TEST_FOLDER` | *(vazio)* | Pasta de testes |
-| `QA_SIGNOFF_BRANCHES` / `QA_SIGNOFF_MAX_AGE` | `main,release/*` / `24` | Sign-off QA |
 | `JARVIS_PROJECT` | `https://github.com/phelipperibeiro/jarvis-framework` | URL completa do repo do framework (`/jarvis-report-issue`); trocar só para um fork |
 | `CENTRAL_DOCS_STORAGE` / `_LOCATION` | `filesystem` / pasta padrão do modo de trabalho | Central docs (o que foi implementado), configurado no Passo 5.2; vazio = desligado |
 | `JARVIS_DOCS` / `ENG_DOCS` | `$DOCS_FOLDER/jarvis` / `$JARVIS_DOCS/engineering` | Documentos de trabalho (não perguntar; `docs/jarvis/` no `.gitignore` só se a raiz tiver `.git`) |
@@ -770,10 +785,12 @@ if (IDE === "claude") {
 }
 ```
 
-O arquivo `$IDE/ENV.md` deve seguir a **estrutura e ordem** de `templates/ENV-template.md` (não um dump reordenado). Blocos mínimos esperados após o init:
+O arquivo `$IDE/ENV.md` deve seguir a **estrutura e ordem** de `templates/ENV-template.md` (não um dump reordenado), com cada assunto na moldura de `# ====` do template; o passo 9.5 confere no fim. Blocos mínimos esperados após o init (os títulos são os do template; os comentários de cada bloco foram omitidos):
 
 ```markdown
-# --- Workspace e identidade ---
+# =============================================================================
+# Workspace e identidade
+# =============================================================================
 WORKSPACE=
 WORKSPACE_REPOS=
 WORKSPACE_MODE={workspace|project}
@@ -781,17 +798,17 @@ USER={resolvido}
 MAX_AI_EXECUTION_PERCENTAGE={60-100}
 ENABLE_CDD=true
 
-# --- Organização ---
+# =============================================================================
+# Organização (obrigatório — opções vêm do taxonomy.md)
+# =============================================================================
 SQUAD={valor}
 HUB={valor}
 AREA={valor}
 POSITION={valor}
 
-# --- Condução e estilo ---
-PROD_MODE={product-led|developer-guided}
-ARTIFACT_STYLE={ai-generated|human-generated}
-
-# --- IDE e pastas ---
+# =============================================================================
+# IDE e pastas
+# =============================================================================
 IDE={valor}
 DOCS_FOLDER=docs
 FLOWS_FOLDER={commands|workflows}
@@ -807,16 +824,22 @@ PROD_TEMPLATES=...
 PROD_DOCS=...
 DISCOVERIES_FOLDER_NAME=discoveries
 DISCOVERIES_DOCS=...
+PROD_MODE={product-led|developer-guided}
+ARTIFACT_STYLE={ai-generated|human-generated}
 
-# --- Task manager (opcional; vazio = freelance) ---
+# =============================================================================
+# Task manager (opcional)
+# =============================================================================
 TASK_MANAGER=
 TASK_MANAGER_ACCESS=
 TASK_MANAGER_URL_BASE=
 
-# --- Controle de versão / chat / demais opcionais do template ---
+# =============================================================================
+# Controle de versão (opcional)
+# =============================================================================
 VERSION_CONTROL=
 VERSION_CONTROL_ACCESS=
-# ... restante do template (MESSAGE_*, DATABASE, JARVIS_PROJECT, CENTRAL_DOCS_*, etc.)
+# ... restante do template, cada assunto na sua moldura (MESSAGE_*, DATABASE, JARVIS_PROJECT, CENTRAL_DOCS_*, etc.)
 JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework
 ```
 
@@ -1142,6 +1165,47 @@ O tempo de ~10 minutos é referência, não limite. Nunca leia `.env*`, chaves o
 
 ---
 
+### 9.5 Validar o ENV.md (sempre, no fim)
+
+Roda no fim de todo caminho que grava o `ENV.md`: criação (opção A ou ENV.md novo), atualização de variáveis (B) e Upgrade (C, inclusive "já atualizado"), depois do passo 9. Não roda ao cancelar (D). Objetivo: o arquivo fica **100% correto** e **separado por assunto**, na estrutura e na ordem de `templates/ENV-template.md`, com cada assunto na moldura de `# ====`:
+
+```
+# =============================================================================
+# Workspace e identidade
+# =============================================================================
+```
+
+**Nunca mostre valor de variável**: nas perguntas e na saída vão só o nome da chave e se a linha tem algo depois do `=`.
+
+**1. Conferir o arquivo inteiro contra o template.** Cada item que falhar é um problema:
+
+| Verificação | Exemplo | Correção sugerida (primeira opção, "(Recomendada)") |
+|---|---|---|
+| Chave do template ausente | falta `WORKSPACE_MODE` | Acrescentar no assunto dela, com o padrão do template. Não conta como ausente uma `DATA_*` (exceto `DATA_SPECIALIZATIONS`) quando o HUB não exige o bloco DATA (regra do bloco DATA, abaixo) |
+| Chave fora do template (saiu dele ou é do projeto) | `QA_SIGNOFF_BRANCHES`, `MINHA_VAR` | Mover para o bloco final "Variáveis fora do template", com `# (descontinuada)` numa linha própria logo acima da chave e o valor intacto |
+| Chave duplicada | `HUB=` duas vezes | Manter a preenchida (ou a última) |
+| Valor fora das opções | `HUB=BACKEN`, `MAX_AI_EXECUTION_PERCENTAGE=40`, `TASK_MANAGER_ACCESS=api` | Perguntar o valor, com as opções do template ou do `taxonomy.md` (as mesmas perguntas do passo 3) |
+| Obrigatória vazia | `SQUAD=` | A mesma pergunta do passo 3 |
+| Lista de exemplo não escolhida | `TASK_MANAGER=[jira, github, gitlab]` | Escolher uma ou esvaziar |
+| Fora da ordem ou do assunto | blocos `# --- Upgrade ... ---` no fim; uma `DATA_*` longe das irmãs | Regravar na ordem do template |
+| Comentários ou separadores diferentes dos do template | comentário antigo; `# --- Assunto ---` | Trocar pelos do template (a pergunta avisa que comentários próprios se perdem) |
+| Bloco DATA fora da regra do HUB | `DATA_*` com `HUB=BACKEND` | Regra do bloco DATA (sempre exceto `DATA_SPECIALIZATIONS`, obrigatória em qualquer HUB): `HUB=DATA` exige o bloco (as que faltarem contam como ausentes); `HUB=FULLCYCLE` o deixa opcional (nem ausente, nem a remover), como a criação (passo 5) e o Upgrade (item 4) já fazem; outro HUB: sugerir remover o bloco |
+
+Não pergunte de novo o que as exceções 9 a 9.3 do Upgrade já resolveram nesta execução.
+
+**2. Perguntar cada problema** com `AskUserQuestion`: **uma pergunta por problema**, em chamadas de até 4 abas, agrupadas por tipo de verificação. Cada pergunta tem a correção sugerida como primeira opção, marcada "(Recomendada)", e uma opção que mantém o arquivo como está (ex.: "Manter como está"). Nada é corrigido sem resposta. Sem problema nenhum, não pergunte: avise `✅ ENV.md conferido: nada a corrigir.`
+
+**3. Regravar (só o que foi aceito).**
+- **Reorganização aceita:** use a estrutura do template (ordem, comentários e molduras), mas só com as chaves que o arquivo já tem mais as acrescentadas por resposta: chave que a pessoa recusou acrescentar não entra, e um bloco inteiro que o arquivo não tem (como o DATA, fora da regra do HUB) não volta. Ponha o valor atual de cada chave no lugar dela, cada uma no seu assunto e junto das irmãs, e desfaça os blocos datados. As chaves fora do template vão para o último bloco, "Variáveis fora do template", cada uma com `# (descontinuada)` logo acima. **Nenhuma chave é apagada**, salvo as que a pessoa mandou remover numa resposta (como o bloco DATA). O comentário fica numa linha própria: na mesma linha da chave, o CLI o leria como parte do valor.
+- **Reorganização recusada:** grave só as correções de conteúdo aceitas, no lugar em que cada chave está, sem mover o resto.
+- **Conferência antes de gravar:** o **conjunto de chaves** depois é o de antes, mais as acrescentadas e menos as removidas por resposta; e o mapa chave → valor das chaves mantidas é igual (só mudam as corrigidas por resposta). Se não for, não grave e avise: `⚠️ A regravação mudaria chaves ou valores que não foram respondidos: nada gravado.`
+
+**4. Rules do perfil.** Se uma correção mudou `HUB`, `POSITION`, `AREA`, `SQUAD`, `ARTIFACT_STYLE` ou `RTK_ENABLED`, rode o **passo 8** de novo: ele já rodou com os valores antigos, e as rules em `$IDE/rules/` seriam de outro perfil.
+
+**5. Resumo.** Liste o que foi corrigido e o que ficou pendente (respostas "Manter como está"), só com nomes de chave, e se o passo 8 rodou de novo.
+
+---
+
 ### 10. Confirmar Criação
 
 ```
@@ -1425,7 +1489,8 @@ Bem-vindo! 🎉
 - [ ] Detectou IDE corretamente
 - [ ] Verificou se ENV.md já existe
 - [ ] Se ENV.md existe: ofereceu opção de Upgrade (C) além de Sobrescrever/Atualizar/Cancelar
-- [ ] Se Upgrade: calculou diff template vs ENV.md e appendou apenas variáveis faltantes
+- [ ] Se Upgrade: calculou diff template vs ENV.md e acrescentou apenas as variáveis faltantes, no assunto de cada uma (sem bloco datado)
+- [ ] **Validou o ENV.md inteiro no passo 9.5**: uma pergunta por problema, regravação na ordem do template com as molduras de `# ====`, chaves fora do template no fim com `# (descontinuada)`, nenhum valor exibido nem trocado sem resposta
 - [ ] Coletou todas as variáveis obrigatórias
 - [ ] USER gravado no ENV.md a partir da identidade local
 - [ ] Validou MAX_AI_EXECUTION_PERCENTAGE (60-100) - para campos livres

package/skills/jarvis-init/assets/setup-guide.md

@@ -339,7 +339,7 @@ Execute o checklist:
 - [ ] Framework JARVIS inicializado (`/jarvis-init`)
 - [ ] IDE detectada corretamente (Windsurf/Cursor/Claude/VS Code)
 - [ ] MCP Context7 instalado e respondendo (**obrigatório**)
-- [ ] MCP de task manager só se `TASK_MANAGER` estiver no ENV (não bloqueia)
+- [ ] Board e git pela CLI oficial (`gh`/`glab`/`acli`), sem MCP; a CLI logada só importa se `TASK_MANAGER` estiver no ENV (não bloqueia)
 - [ ] IDE reiniciada após configurar MCPs (se configurou)
 
  Problemas Comuns

package/skills/jarvis-report-issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: jarvis-report-issue
-description: Reporta um bug ou propõe uma melhoria no próprio framework Jarvis. Classifica o report (bug ou melhoria), monta o issue no formato do tipo e o abre no repo do Jarvis (o JARVIS_PROJECT, hoje no GitHub) pela CLI do host (gh issue create), com a label certa; sem a CLI, deixa o issue pronto em .jarvis/issues/.
+description: Reporta um bug ou propõe uma melhoria no próprio framework Jarvis. Classifica o report (bug ou melhoria), monta a issue no formato do tipo e a abre no repo do Jarvis (o JARVIS_PROJECT, hoje no GitHub) pela CLI do host (gh issue create), com a label certa, só depois de mostrar o texto e o usuário dizer Sim (regra de ouro); sem a CLI ou sem o Sim, deixa a issue pronta em .jarvis/issues/.
 argument-hint: "[descrição opcional do problema ou da melhoria]"
 disable-model-invocation: false
 allowed-tools: Read Bash Grep Glob
@@ -13,7 +13,7 @@ metadata:
 
 # jarvis-report-issue — Bug ou melhoria no Framework Jarvis
 
-Você abre um issue no repositório do Jarvis: um **bug** (uma instrução do Jarvis induziu um erro) ou uma **melhoria** (funcionalidade nova ou mudança de comportamento pedida pelo usuário).
+Você abre uma issue no repositório do Jarvis: um **bug** (uma instrução do Jarvis induziu um erro) ou uma **melhoria** (funcionalidade nova ou mudança de comportamento pedida pelo usuário).
 
 O usuário não precisa preencher nada — você é o autor do report.
 
@@ -55,13 +55,13 @@ Responda internamente às perguntas abaixo. Use o contexto da conversa atual:
 ```
 
 Se não houver contexto suficiente na conversa, pergunte ao usuário **uma** coisa antes de continuar:
-> "Para abrir o issue, preciso saber: qual skill ou workflow estava sendo executado?"
+> "Para abrir a issue, preciso saber: qual skill ou workflow estava sendo executado?"
 
 ---
 
-## Fase 2 — Montar o issue
+## Fase 2 — Montar a issue
 
-Com as respostas da Fase 1, monte o issue no formato abaixo.
+Com as respostas da Fase 1, monte a issue no formato abaixo.
 
 **Título:** `[BUG] {artefato}: {descrição curta do problema em até 80 chars}`
 
@@ -134,7 +134,7 @@ Com `ARTIFACT_STYLE=human-generated`, troque a linha por `- **Reportado por:** {
 - **Reportado por:** IA, a partir do pedido do usuário
 ```
 
-Antes de abrir, se o pedido tiver pontos em conflito com as regras atuais ou ambíguos, pergunte ao usuário (uma pergunta por ponto) e registre as respostas em "Decisões".
+Antes de abrir, se o pedido tiver pontos em conflito com as regras atuais ou ambíguos, pergunte ao usuário (uma pergunta por ponto) e registre as respostas em "Decisões". Além disso, a Fase 4 sempre mostra o texto e pergunta antes de abrir.
 
 ---
 
@@ -149,10 +149,10 @@ Se o projeto não estiver definido:
 
 > `🚫 BLOQUEADO: defina JARVIS_PROJECT=https://github.com/phelipperibeiro/jarvis-framework no ENV.md (URL completa).`
 
-Sem host (`grupo/repo`), o vendor não é adivinhado: o `jarvis vcs create-issue` sai com `3` e o issue vai para o fallback da Fase 4.
+Sem host (`grupo/repo`), o vendor não é adivinhado: o `jarvis vcs create-issue` sai com `3` e a issue vai para o fallback da Fase 4.
 > → PARAR
 
-Login: o da CLI do host (`gh auth login`; no GitLab, `glab auth login`). Nenhum token é lido ou pedido. O `VERSION_CONTROL_ACCESS` do projeto não se aplica aqui: o issue vai para o repositório do Jarvis.
+Login: o da CLI do host (`gh auth login`; no GitLab, `glab auth login`). Nenhum token é lido ou pedido. O `VERSION_CONTROL_ACCESS` do projeto não se aplica aqui: a issue vai para o repositório do Jarvis.
 
 Versão do Jarvis:
 
@@ -162,11 +162,13 @@ grep '"version"' package.json | head -1 | sed 's/.*"version": *"\([^"]*\)".*/\1/
 
 ---
 
-## Fase 4 — Abrir o issue
+## Fase 4 — Abrir a issue
+
+**Antes de abrir, mostre e pergunte (regra de ouro, `eng.integrations-rules.md`).** Mostre o título, a label e o corpo da issue e pergunte com `AskUserQuestion`: **"Abrir esta issue no repositório do Jarvis?"** → **Sim, abrir a issue** / **Não, manter só em `.jarvis/issues/`**. A pergunta vale mesmo quando o usuário pediu o report direto, porque ele ainda não viu o texto final. Com **Não**, grave o fallback abaixo (rode `unset STATUS` antes: indefinido conta como "não abriu") e não rode o `jarvis vcs create-issue`.
 
 ```bash
 BODY_FILE=$(mktemp)
-# gravar o corpo markdown do issue em $BODY_FILE
+# gravar o corpo markdown da issue em $BODY_FILE
 
 REPO=$(grep -E '^(JARVIS_PROJECT|JARVIS_GITLAB_PROJECT)=' $IDE/ENV.md | tail -1 | cut -d= -f2-)
 
@@ -178,25 +180,25 @@ jarvis vcs create-issue \
 STATUS=$?
 ```
 
-**Cadeia (`rules/engineering/eng.integrations-rules.md`).** `0` → aberto. `1` (uso: arquivo do corpo inexistente, título vazio) → corrija a chamada e rode de novo. `3` (indisponível: CLI ausente, sem login, `JARVIS_PROJECT` sem host; nada enviado) → rode a CLI direto, se ela estiver logada (`gh issue create --repo {host}/{dono}/{repo} --title "$ISSUE_TITLE" --body-file "$BODY_FILE" --label "$LABEL"`); se também não der, o fallback abaixo. `4` (enviado com erro) → **não** repita: grave o fallback e avise para conferir no repositório se o issue foi aberto.
+**Cadeia (`rules/engineering/eng.integrations-rules.md`).** `0` → aberta. `1` (uso: arquivo do corpo inexistente, título vazio) → corrija a chamada e rode de novo. `3` (indisponível: CLI ausente, sem login, `JARVIS_PROJECT` sem host; nada enviado) → rode a CLI direto, se ela estiver logada (`gh issue create --repo {host}/{dono}/{repo} --title "$ISSUE_TITLE" --body-file "$BODY_FILE" --label "$LABEL"`); se também não der, o fallback abaixo. `4` (enviado com erro) → **não** repita: grave o fallback e avise para conferir no repositório se a issue foi aberta.
 
-**Fallback — sem CLI ou sem conexão com o repositório.** Se a cadeia não abrir o issue, **não descarte o report**. Grave o issue montado em `.jarvis/issues/issue-{desc}.md`, na pasta do workspace (a que contém `$IDE/`), para a pessoa abrir manualmente:
+**Fallback — sem CLI ou sem conexão com o repositório.** Se a cadeia não abrir a issue, **não descarte o report**. Grave a issue montada em `.jarvis/issues/issue-{desc}.md`, na pasta do workspace (a que contém `$IDE/`), para a pessoa abrir manualmente:
 
 - `{desc}` é o slug do título, sem o prefixo de tipo: minúsculas, sem acentos, palavras separadas por `-`, até 60 caracteres (ex.: `[MELHORIA] jarvis-init: Central docs padrão` → `issue-jarvis-init-central-docs-padrao.md`). Se o arquivo já existir, acrescente `-2`, `-3`…
 - Conteúdo: um cabeçalho com o que vai nos campos do formulário e, depois, o corpo exatamente como seria enviado:
 
   ```markdown
-  <!-- Abrir em: {URL de novo issue} · Label: {LABEL} -->
-  # {título do issue}
+  <!-- Abrir em: {URL de nova issue} · Label: {LABEL} -->
+  # {título da issue}
 
-  {corpo do issue}
+  {corpo da issue}
   ```
 
-- `{URL de novo issue}` vem de `JARVIS_PROJECT` pelo vendor: GitHub `{repo}/issues/new`, GitLab `{repo}/-/issues/new`.
+- `{URL de nova issue}` vem de `JARVIS_PROJECT` pelo vendor: GitHub `{repo}/issues/new`, GitLab `{repo}/-/issues/new`.
 - `.jarvis/` já fica fora do versionamento, então o arquivo não vai para nenhum commit.
 
 ```bash
-if [ "$STATUS" -ne 0 ]; then
+if [ "${STATUS:-1}" -ne 0 ]; then   # STATUS indefinido = o usuário disse Não, ou o envio falhou
   mkdir -p .jarvis/issues
   # gravar cabeçalho + "# $ISSUE_TITLE" + corpo em .jarvis/issues/issue-{desc}.md
 fi
@@ -210,31 +212,42 @@ rm -f "$BODY_FILE"
 Sucesso (exit 0):
 
 ```
-✅ Issue aberto com sucesso!
+✅ Issue aberta com sucesso!
 
-  Título : {título do issue}
+  Título : {título da issue}
   Artefato: {caminho do arquivo com problema}
   URL     : {url retornada}
 
 O time do Jarvis vai revisar e corrigir o artefato.
 ```
 
+Sem o Sim (o usuário recusou; o fallback da Fase 4 gravou o arquivo):
+
+```
+ℹ️ Issue não aberta, como você pediu. O texto ficou em:
+  Arquivo : .jarvis/issues/issue-{desc}.md
+  Título  : {título da issue}
+  Label   : {LABEL}
+
+Quando quiser abrir, peça para abrir a issue a partir desse arquivo.
+```
+
 Erro (o fallback da Fase 4 gravou o arquivo):
 
 ```
-⚠️ Não consegui abrir o issue: {mensagem}
+⚠️ Não consegui abrir a issue: {mensagem}
 
-O issue ficou pronto para você abrir manualmente:
+A issue ficou pronta para você abrir manualmente:
   Arquivo : .jarvis/issues/issue-{desc}.md
-  Título  : {título do issue}
+  Título  : {título da issue}
   Label   : {LABEL}
-  Abrir em: {URL de novo issue}
+  Abrir em: {URL de nova issue}
 
 Cole o título no campo de título e o conteúdo abaixo do título no corpo.
 Para abrir direto da próxima vez, faça `gh auth login` (ou o login da CLI do host) e confira o JARVIS_PROJECT (URL completa).
 ```
 
-Com a CLI logada depois, a pessoa pode pedir para abrir o issue a partir desse arquivo, sem montar o report de novo. Depois que o issue for aberto, o arquivo pode ser apagado.
+Com a CLI logada depois, a pessoa pode pedir para abrir a issue a partir desse arquivo, sem montar o report de novo. Depois que a issue for aberta, o arquivo pode ser apagado.
 
 ### Skills invocados durante a execução do skill