jarvis-ai-framework 1.1.0 → 2.0.0

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

@@ -0,0 +1,60 @@
+---
+trigger: always_on
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Regras de Skills: área obrigatória e nome inexistente
+
+## Objetivo
+
+Garantir que todo skill instalado tenha uma área reconhecida e avisar a pessoa, na hora, quando algo pede um skill que não existe.
+
+## Escopo
+
+Vale para todo comando `eng.*` e seus agentes, **ao iniciar**. A pasta de skills considerada é `$IDE/skills/`.
+
+**Áreas reconhecidas:** `qa`, `data`, `ai`, `frontend`, `backend`, `security`, `scraper`, `devops`, `global`, `product`.
+
+## Regras
+
+### Obrigatório
+
+1. **Bloqueio, primeiro.** Leia só o frontmatter de cada `$IDE/skills/*/SKILL.md`:
+
+   ```bash
+   for f in $IDE/skills/*/SKILL.md; do
+     awk -v f="$f" 'BEGIN{fm=0} /^---[[:space:]]*$/{fm++; next}
+       fm==1 && /^name:/{n=$2}
+       fm==1 && /^[[:space:]]+area:/{a=$2}
+       END{printf "%s|area=%s\n", n, a}' "$f"
+   done
+   ```
+
+   Se algum skill tem `area` vazia ou fora das áreas reconhecidas, **interrompa o comando** e exiba:
+   `⛔ Skills instalados sem área (metadata.area): {lista}. Marque a área de cada um (ou remova o skill) e execute o comando de novo. O comando foi interrompido.`
+2. **Aviso de nome inexistente.** Quando o usuário, um workflow, um agente ou uma das listas (`BACKEND_SPECIALIZATIONS`, `FRONTEND_SPECIALIZATIONS`) pedir um skill cujo `$IDE/skills/{nome}/SKILL.md` não existe, exiba na hora:
+   `⚠️ O skill "{nome}" não existe em $IDE/skills/. Use /jarvis-list-specializations para ver os nomes atuais e corrija a referência. Seguindo sem ele.`
+   e **siga sem esse skill** (em backend e frontend, com o skill base e os demais itens).
+
+### Proibido
+
+- Pular o bloqueio ou seguir como se o skill sem área estivesse marcado
+- Corrigir sozinho o nome, a área ou a lista do `ENV.md`
+- Usar um skill que não existe, nem adivinhar um nome parecido
+
+### Recomendado
+
+- Na mensagem do bloqueio, listar cada skill pelo nome da pasta
+- No aviso, citar o nome exatamente como foi pedido
+
+## Exceções
+
+- Só Claude Code e Cursor são suportados. Em IDEs com outra pasta de skills (por exemplo, Kiro e Codex), o bloqueio e o aviso podem não funcionar.
+- O comando `/jarvis-init` e a consulta `/jarvis-list-specializations` não passam pelo bloqueio (são como a pessoa descobre e corrige o problema).
+
+## Referências
+
+- `eng.specializations-rules.md`: listas de especializações e carregamento por área
+- `skills/jarvis-list-specializations/SKILL.md`: consulta do que está instalado e registrado
+- `skills/AGENTS.md`: áreas reconhecidas e padrão de nomes

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

@@ -0,0 +1,69 @@
+---
+trigger: always_on
+---
+
+> **Applies to:** HUB: all | POSITION: all | AREA: ENGINEERING | SQUAD: all
+
+# Regras de Especializações por Stack
+
+## Objetivo
+
+Fazer todo comando `eng.*` carregar o **skill base** da área mais as **especializações** que o projeto registrou no `ENV.md`, e avisar a pessoa quando algo falta.
+
+## Escopo
+
+Vale para qualquer comando `eng.*` e seus agentes, **ao iniciar um trabalho de backend** (APIs, autenticação, workers, banco de dados, servidor) **ou de frontend** (componentes, interface, estilos, estado). Se o trabalho envolve as duas áreas, aplique a regra a cada uma. Se não é de nenhuma das duas, não carregue nada.
+
+| Área | Variável no `ENV.md` | Skill base |
+|------|----------------------|------------|
+| backend | `BACKEND_SPECIALIZATIONS` | `eng-backend` |
+| frontend | `FRONTEND_SPECIALIZATIONS` | `eng-frontend` |
+
+## Regras
+
+### Obrigatório
+
+1. **Leia a variável** da área no `$IDE/ENV.md`.
+2. **Variável ausente** (a chave não existe, diferente de vazia): **interrompa o comando** e exiba:
+   `⚠️ A variável {VAR} não existe no ENV.md. Execute /jarvis-init e escolha Upgrade (C) para acrescentá-la. O comando foi interrompido.`
+3. **Lista vazia:** siga só com o skill base e exiba:
+   `ℹ️ Sem especialização registrada para {área}. Usando só a skill base ({base}).`
+4. **Lista com itens:** carregue o skill base e, para **cada item**:
+   - nome fora de `^[a-z0-9][a-z0-9-]*$` (inclui `/`, `..` e maiúsculas): ignore o item e exiba
+     `⚠️ O item "{item}" de {VAR} tem caracteres inválidos (use letras minúsculas, números e hífen). Item ignorado.`
+   - `$IDE/skills/{item}/SKILL.md` não existe: exiba
+     `⚠️ O item "{item}" de {VAR} não corresponde a um skill instalado em $IDE/skills/. Instale o skill ou corrija a lista. Seguindo com o neutro e os demais itens.`
+   - existe: leia o `SKILL.md` e aplique-o junto com o skill base.
+5. **Informe** o que foi carregado: `✅ Skills carregados ({área}): {base} (base), {itens carregados}`.
+6. As especializações **somam-se** ao skill base; nenhuma o substitui.
+
+### Formato da lista
+
+- Itens **separados por vírgula**: `eng-backend-golang,eng-backend-nestjs`.
+- **Leia** com ou sem colchetes, espaços e aspas (`a,b`, `[a,b]`, `[ a , b ]`, `["a","b"]`).
+- Ao **gravar**, escreva sempre separado por vírgula, sem colchetes.
+
+### Proibido
+
+- Criar ou alterar a variável por conta própria.
+- Seguir só com o skill base quando a variável está **ausente**.
+- Carregar skills que não estão na lista.
+- Aceitar item com caminho (`/`, `..`) ou fora do padrão de nome.
+
+### Recomendado
+
+- Citar na mensagem o nome da variável e do item.
+- Com vários itens, carregar todos.
+
+## Exceções
+
+- Áreas além de backend e frontend não têm lista (evolução futura).
+- Skills de outras áreas não passam por esta regra.
+
+## Referências
+
+- `eng-rules.md`: validação do `ENV.md` (lista presente, mesmo vazia).
+- `eng.skills-rules.md`: área obrigatória nos skills e aviso de skill inexistente (o nome citado em uma lista que não existe também segue o aviso de lá).
+- `skills/jarvis-create-specialization/SKILL.md`: criação de uma especialização a partir do código do projeto e registro na lista.
+- `skills/jarvis-list-specializations/SKILL.md`: consulta das especializações instaladas e registradas.
+- `templates/ENV-template.md`: seção "Especializações de stack".

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

@@ -1,47 +1,50 @@
 ---
 name: eng.frontend-rules
 description: >
-  Padrões obrigatórios para devs com HUB: FRONTEND — componentes, TypeScript,
-  acessibilidade, performance, micro frontend e design system.
+  Padrões obrigatórios para devs com HUB: FRONTEND, neutros de stack — componentes,
+  tipagem, acessibilidade, performance, testes, arquiteturas distribuídas e tokens de design.
+  O que depende da stack vem das especializações registradas em FRONTEND_SPECIALIZATIONS.
 author: jarvis-team
-version: "1.0"
+version: "1.1"
 ---
 
 > **Applies to:** HUB: FRONTEND | POSITION: all | AREA: ENGINEERING | SQUAD: all
 
 # Regras de Engenharia Frontend
 
+> **Neutras de stack.** Estas regras valem para qualquer framework ou linguagem de frontend. Onde uma regra depende da stack (como se busca dados, como se organiza um módulo, qual ferramenta de teste usar), siga a **especialização registrada** em `FRONTEND_SPECIALIZATIONS` no `ENV.md` e o código existente do projeto. Sem especialização registrada, **pergunte** em vez de presumir uma stack. Ver `eng.specializations-rules.md`.
+
 ---
 
 ## 1. Componentes
 
 ### Estrutura obrigatória
-- Todo componente deve ter props tipadas com TypeScript — `any` é proibido sem justificativa documentada
-- Props obrigatórias devem ser declaradas sem `?`; opcionais com `?` e valor default explícito
+- Toda entrada de um componente (props, parâmetros ou atributos) é **tipada ou documentada**; tipo genérico solto (`any` ou equivalente) é proibido sem justificativa documentada
+- Entradas obrigatórias são declaradas como obrigatórias; opcionais têm valor default explícito
 - Componentes com mais de uma responsabilidade devem ser divididos (Single Responsibility)
-- Lógica de negócio não pertence ao componente de UI — usar hooks ou camada de serviço
+- Lógica de negócio não pertence ao componente de UI — usar a camada de lógica ou de serviço que o projeto adota
 
 ### Nomenclatura
-- Componentes: `PascalCase` (`UserCard`, `ProductTable`)
-- Hooks: `use` + `PascalCase` (`useUserData`, `useProductFilters`)
-- Arquivos de componente: `PascalCase.tsx` (`UserCard.tsx`)
-- Arquivos de hook: `camelCase.ts` (`useUserData.ts`)
+- Seguir a convenção de nomes **do projeto** (e da especialização registrada) para componentes, funções de lógica reutilizável e arquivos
+- Manter o padrão consistente: um mesmo tipo de arquivo, um mesmo estilo de nome
 
 ### Checklist mínimo por componente
-- [ ] Props tipadas (TypeScript)
+- [ ] Entradas tipadas ou documentadas
 - [ ] Estados visuais: normal, hover, focus, disabled, loading, erro, vazio
-- [ ] Semântica HTML correta (não usar `<div>` para botões, links ou listas)
-- [ ] Responsivo (mobile-first com breakpoints do design system)
-- [ ] Testável sem DOM real (lógica isolada em hooks)
+- [ ] Semântica HTML correta (não usar um contêiner genérico para botões, links ou listas)
+- [ ] Responsivo (mobile-first, nos tamanhos de tela do projeto)
+- [ ] Testável sem depender de um navegador real (lógica isolada da apresentação)
 
 ---
 
-## 2. TypeScript
+## 2. Tipagem e contratos
+
+Aplica-se quando a linguagem do projeto tem tipagem estática ou contratos explícitos.
 
-- `strict: true` obrigatório em `tsconfig.json`
-- Proibido: `as any`, `@ts-ignore` sem comentário explicativo, `!` (non-null assertion) sem verificação prévia
-- Types vs Interfaces: usar `interface` para objetos de domínio, `type` para uniões e utilitários
-- Exportar tipos públicos de componentes (`export type { ButtonProps }`)
+- O **modo estrito** de verificação do projeto fica ligado e não é relaxado
+- Proibido: tipo genérico solto, supressão de verificação de tipos sem comentário explicativo e asserção de "não nulo" sem verificação prévia
+- Modelar objetos de domínio de forma explícita e unir ou derivar tipos com os recursos da linguagem
+- Exportar o contrato público dos componentes, quando a linguagem permite
 
 ---
 
@@ -49,12 +52,12 @@ version: "1.0"
 
 - Semântica HTML nativa antes de ARIA (`<button>`, `<nav>`, `<main>`, `<article>`)
 - Todos os elementos interativos são navegáveis por teclado
-- Contraste mínimo: 4.5:1 para texto normal, 3:1 para texto grande e elementos UI
-- Imagens informativas têm `alt` descritivo; decorativas têm `alt=""`
-- Modais usam `role="dialog"`, `aria-modal="true"`, `aria-labelledby` e focus trap
-- Formulários: todo `<input>` tem `<label>` associado via `htmlFor` ou `aria-label`
+- Contraste mínimo: 4.5:1 para texto normal, 3:1 para texto grande e elementos de interface
+- Imagens informativas têm texto alternativo descritivo; decorativas têm texto alternativo vazio
+- Modais usam `role="dialog"`, `aria-modal="true"`, `aria-labelledby` e prendem o foco
+- Formulários: todo campo tem rótulo associado
 - Erros de formulário: exibidos com `role="alert"` ou `aria-live="polite"`
-- Screen reader: testar com VoiceOver (Mac) ou NVDA (Windows) em features críticas
+- Leitor de tela: testar com VoiceOver (Mac) ou NVDA (Windows) em features críticas
 
 ---
 
@@ -66,59 +69,56 @@ version: "1.0"
 - INP (Interaction to Next Paint): < 200ms
 
 ### Práticas obrigatórias
-- Imagens sempre com `width` e `height` definidos para evitar CLS
-- Componentes pesados com `lazy()` + `<Suspense fallback>`
-- Dependências novas: avaliar impacto no bundle antes de instalar (`bundlephobia.com`)
-- Sem `useEffect` para buscar dados — usar React Query / TanStack Query ou Server Components
-- Memoização apenas quando necessário e comprovado com profiler (não premature optimization)
+- Imagens sempre com largura e altura definidas, para evitar CLS
+- Carregamento tardio de componentes pesados, com o recurso que a stack oferece, e um substituto visual com o mesmo tamanho enquanto carrega
+- Dependências novas: avaliar o impacto no tamanho do pacote final antes de instalar
+- Busca de dados pela camada que o projeto adota para isso (conforme a especialização), e não por efeitos soltos no componente de apresentação
+- Otimização de renderização apenas quando necessária e **comprovada com medição** (não otimização prematura)
 
 ---
 
 ## 5. Testes
 
-- **Testing Library**: queries por acessibilidade primeiro (`getByRole`, `getByLabelText`)
-- **Proibido**: `getByTestId` como primeira opção (usar só quando sem alternativa acessível)
-- **Cobertura mínima**: fluxos críticos de usuário (happy path + estado de erro)
-- **Vitest**: unitários para lógica pura, hooks e utilitários
-- **Playwright / Cypress**: E2E para fluxos de usuário completos (login, checkout, etc.)
-- Mocks de módulos externos devem estar em `__mocks__/` ou `*.mock.ts`
+- **Consultas por acessibilidade primeiro** (por papel e por rótulo): focar no que o usuário vê e faz, não em detalhes de implementação
+- **Proibido** usar identificador de teste como primeira opção (só quando não houver alternativa acessível)
+- **Cobertura mínima:** fluxos críticos de usuário (caminho feliz e estado de erro)
+- **Testes unitários** para lógica pura e utilitários, com a ferramenta que o projeto já usa
+- **Testes de ponta a ponta** para fluxos completos de usuário (login, checkout etc.), com a ferramenta que o projeto já usa
+- Substitutos de módulos externos ficam num lugar previsível do projeto (por exemplo, uma pasta de mocks)
 
 ### Ferramentas disponíveis no framework
 
-- **TestSprite** (`/eng-qa-testsprite`): se o TestSprite estiver instalado no projeto, usá-lo para geração
-  e execução de testes de componente e E2E — ele gera planos de teste e código automaticamente.
+- **TestSprite** (`/eng-qa-testsprite`): se estiver instalado no projeto, usá-lo para gerar e executar testes de componente e de ponta a ponta — ele gera planos de teste e código automaticamente.
   Verificar: `ls node_modules/@testsprite 2>/dev/null || cat package.json | grep testsprite`
-
-- **Stagehand** (`/eng-scraper-robot-builder`, `/eng-qa-e2e`): para testes E2E em linguagem natural
-  ou automação de fluxos de usuário complexos, o Stagehand permite descrever o fluxo em português
-  e gera os steps Playwright automaticamente.
+- **Stagehand** (`/eng-scraper-robot-builder`, `/eng-qa-e2e`): para testes de ponta a ponta em linguagem natural ou automação de fluxos complexos, descrevendo o fluxo em português.
   Verificar: `cat package.json | grep stagehand`
 
-> Quando qualquer dessas ferramentas estiver disponível no projeto, **preferir sobre a implementação
-> manual** — reduz custo de manutenção e aumenta cobertura mais rapidamente.
+> Quando qualquer dessas ferramentas estiver disponível no projeto, **preferir sobre a implementação manual** — reduz o custo de manutenção e aumenta a cobertura mais rápido.
 
 ---
 
-## 6. Micro Frontend
+## 6. Arquiteturas distribuídas (se o projeto divide o frontend em partes)
+
+Aplica-se somente se o projeto divide o frontend em partes carregadas separadamente (por exemplo, uma aplicação principal que carrega módulos independentes). O detalhe da arquitetura em uso vem da especialização registrada. Princípios que valem em qualquer variante:
 
-- Todo remote deve ser versionado e publicado com URL de fallback definida
-- Contratos de interface entre shell e remotes são declarados em tipos TypeScript compartilhados
-- Nenhum remote depende diretamente de outro remote — comunicação via shell ou event bus
-- Shared dependencies declaradas explicitamente no `ModuleFederationPlugin` com `singleton: true`
-- Cada remote deve funcionar em modo standalone (sem shell) para desenvolvimento local
-- Testes de integração entre shell e remote são obrigatórios para cada ponto de montagem
-- Versionamento: breaking changes no contrato de um remote exigem bump de versão major
+- Cada módulo é **versionado e publicado** com uma alternativa definida quando não carrega
+- Os contratos de interface entre a aplicação principal e os módulos são declarados de forma explícita e compartilhada
+- Nenhum módulo depende diretamente de outro: a comunicação passa pela aplicação principal ou por um barramento de eventos
+- Dependências compartilhadas são declaradas explicitamente, para não serem carregadas em duplicidade
+- Cada módulo deve funcionar de forma isolada, para desenvolvimento local
+- Testes de integração entre a aplicação principal e cada módulo são obrigatórios em cada ponto de montagem
+- Mudança que quebra o contrato de um módulo exige aumento de versão **major**
 
 ---
 
-## 7. Design System
+## 7. Tokens de design e componentes compartilhados
 
-- Cores, tipografia, espaçamentos e breakpoints vêm **exclusivamente** dos tokens do design system
-- Proibido hardcodar valores de cor, fonte ou espaçamento fora dos tokens
-- Novos componentes de UI são criados no design system antes de serem usados nos remotes
-- Variantes de componente usam `cva` (class-variance-authority) como padrão
-- Componentes públicos do design system têm story no Storybook antes de serem liberados
-- Alterações na API pública de um componente (props) seguem semver
+- Cores, tipografia, espaçamentos e tamanhos de tela vêm **exclusivamente** dos tokens de design do projeto (quando o projeto tem)
+- Proibido fixar valores de cor, fonte ou espaçamento fora dos tokens
+- Novos componentes reutilizáveis nascem na biblioteca de componentes compartilhados do projeto (se existir) antes de serem usados nos módulos
+- Variantes de componente seguem o padrão que o projeto já usa
+- Componentes públicos da biblioteca compartilhada têm documentação visual antes de serem liberados, quando o projeto usa um catálogo de componentes
+- Alterações na interface pública de um componente seguem o versionamento semântico
 
 ---
 
@@ -126,22 +126,23 @@ version: "1.0"
 
 Ao revisar PR de frontend, verificar:
 
-- [ ] TypeScript sem `any` ou `@ts-ignore` injustificado
+- [ ] Tipagem sem tipo genérico solto nem supressões injustificadas (quando a linguagem tem tipagem)
 - [ ] Nenhuma lógica de negócio em componente de UI
 - [ ] Acessibilidade: semântica HTML, ARIA correto, navegação por teclado
-- [ ] Performance: sem re-renders desnecessários, lazy loading aplicado quando cabível
-- [ ] Tokens do design system usados (sem valores hardcodados)
-- [ ] Testes cobrem happy path e estado de erro
-- [ ] Responsividade verificada em mobile e desktop
-- [ ] Se micro frontend: contrato de interface atualizado, remote funciona standalone
+- [ ] Performance: sem renderizações desnecessárias comprovadas, carregamento tardio aplicado quando cabível
+- [ ] Tokens de design do projeto usados (sem valores fixos)
+- [ ] Testes cobrem o caminho feliz e o estado de erro
+- [ ] Responsividade verificada em celular e desktop
+- [ ] Se arquitetura distribuída: contrato de interface atualizado e módulo funciona de forma isolada
+- [ ] Itens exigidos pelas especializações registradas atendidos
 
 ---
 
 ## 9. Proibições Absolutas
 
-- `document.querySelector` / manipulação direta do DOM em contexto React
+- Manipulação direta do DOM fora do mecanismo que o framework do projeto prevê para isso
 - `!important` em CSS sem comentário explicativo
-- Fetch direto em componente de UI (usar hooks, queries ou Server Actions)
-- Importar de outro remote diretamente (rompe o isolamento do micro frontend)
-- Hardcodar tokens de design (cores, espaçamentos, fontes) fora do sistema de tokens
-- `console.log` em código commitado (usar logger estruturado ou remover)
+- Busca de dados direto no componente de apresentação (usar a camada que o projeto adota)
+- Importar diretamente de outro módulo de uma arquitetura distribuída (rompe o isolamento)
+- Fixar tokens de design (cores, espaçamentos, fontes) fora do sistema de tokens
+- Log de depuração (`console.log` ou equivalente) em código commitado (usar logger estruturado ou remover)

package/rules/product/prod-rules.md

@@ -7,9 +7,9 @@ trigger: always_on
 ## Principais Regras
 - O idioma padrão é o português do Brasil. Mas mude caso o usuário solicite outro idioma.
 - Leia o `./$IDE/ENV.md` para entender as variáveis de ambiente do framework. Ele é importante para você saber caminhos de pastas e outras informações sobre projeto e usuário.
-  - Se não existir, use o skill `init-jarvis` para criar o `ENV.md`.
+  - Se não existir, use o skill `jarvis-init` para criar o `ENV.md`.
 - Procure `CLAUDE.md` ou `AGENTS.md` para entender informações sobre o contexto e objetivo do projeto.
-  - Se não existirem, use o skill `init-jarvis` para criar o `AGENTS.md` e após essa criação, copie o conteúdo do `AGENTS.md` para o `CLAUDE.md` (se não existir o CLAUDE.md, crie-o).
+  - Se não existirem, use o skill `jarvis-init` para criar o `AGENTS.md` e após essa criação, copie o conteúdo do `AGENTS.md` para o `CLAUDE.md` (se não existir o CLAUDE.md, crie-o).
 - Nunca invente ou presuma dados ou informações. Se não souber, pergunte, valide e confirme com o usuário.
 - Entenda se o projeto é novo ou existente, para criar ou modificar especificações de produto ou técnicas.
 
@@ -18,7 +18,7 @@ trigger: always_on
 IMPORTANTE: Para que você funcione como o previsto e tenha todas as informações necessárias, é importante que você leia e interprete o arquivo `./$IDE/ENV.md`. Esse é o arquivo que guardamos variáveis de informações importantes sobre o projeto, o usuário e estruturas de pastas e arquivos que você precisará para operar corretamente.
 
 - **Sempre no início de novas sessões ou interações, ANTES de executar qualquer comando ou workflow**, o agente **DEVE verificar** se o arquivo `$IDE/ENV.md` existe e está preenchido corretamente.
-- **Exceção**: O comando `/init-jarvis` é o único que pode ser executado sem o `ENV.md`, pois é ele que cria o arquivo.
+- **Exceção**: O comando `/jarvis-init` é o único que pode ser executado sem o `ENV.md`, pois é ele que cria o arquivo.
 - **Validação obrigatória**: O arquivo deve conter as seguintes variáveis preenchidas (não vazias):
   - `RULES_FOLDER`
   - `PROD_FOLDER_NAME`
@@ -30,7 +30,7 @@ IMPORTANTE: Para que você funcione como o previsto e tenha todas as informaçõ
 - **Se o ENV.md não existir ou estiver incompleto**, o agente deve:
   1. Interromper a execução do comando solicitado
   2. Informar ao usuário que não podemos avançar sem o ENV.md. Mensagem abaixo.
-  3. Após confirmação, executar via Skill tool o `init-jarvis`. No caso de negativa, o agente poderá avançar apenas para criar especificações de produto. E sempre que precisar salvar arquivos das especificações, deverá confirmar com o usuário. 
+  3. Após confirmação, executar via Skill tool o `jarvis-init`. No caso de negativa, o agente poderá avançar apenas para criar especificações de produto. E sempre que precisar salvar arquivos das especificações, deverá confirmar com o usuário. 
   ```
   ⚠️ O framework não foi inicializado.
 

package/skills/AGENTS.md

@@ -14,44 +14,75 @@ A pasta `skills/` contem **playbooks executaveis** que sao a fonte de verdade op
 
 ```
 skills/
-├── eng-arch-c4/          # Diagramas C4
+├── eng-backend-arch-c4/          # Diagramas C4
 │   ├── SKILL.md
 │   └── assets/
-├── eng-docs-write/       # Escrita de documentacao
+├── eng-global-docs-write/       # Escrita de documentacao
 │   └── SKILL.md
-├── eng-pr/               # Criacao de Pull/Merge Requests (GitLab/GitHub/Bitbucket)
+├── eng-global-pr/               # Criacao de Pull/Merge Requests (GitLab/GitHub/Bitbucket)
 │   └── SKILL.md
-├── eng-task-comment/     # Comentário no card (Jira/Linear/GitHub Issues/Asana)
+├── eng-global-task-comment/     # Comentário no card (Jira/Linear/GitHub Issues/Asana)
 │   └── SKILL.md
-├── eng-jira-comment/     # Alias → eng-task-comment
+├── eng-global-jira-comment/     # Alias → eng-global-task-comment
 │   └── SKILL.md
-├── eng-backend/          # APIs REST/GraphQL, auth JWT/OAuth2/RBAC, RabbitMQ workers, caching
+├── jarvis-list-specializations/ # Lista especializações de stack instaladas e registradas
 │   └── SKILL.md
-├── eng-frontend/         # React/Next.js/Vue, estado, performance UI, acessibilidade
+├── jarvis-create-specialization/ # Cria uma especialização de stack (backend/frontend) a partir do código do projeto e a registra na lista
+│   ├── SKILL.md
+│   └── assets/
+├── eng-backend/          # Base neutra de backend (APIs, auth, workers, dados); especializações por stack se somam a ele
 │   └── SKILL.md
-├── eng-microfrontend/    # Module Federation, shell/remote, contratos de interface, event bus
+├── eng-frontend/         # Base neutra de frontend (componentes, estado, performance UI, acessibilidade); especializações se somam a ele
 │   └── SKILL.md
-├── eng-design-system/    # Tokens semânticos, CVA, Storybook, versionamento, auditoria visual
+├── eng-frontend-microfrontend/    # Module Federation, shell/remote, contratos de interface, event bus
 │   └── SKILL.md
-├── eng-nestjs/           # Framework NestJS: módulos, DI, guards, interceptors, pipes, Passport/JWT
+├── eng-frontend-design-system/    # Tokens semânticos, CVA, Storybook, versionamento, auditoria visual
 │   └── SKILL.md
-├── eng-rabbitmq/         # Mensageria RabbitMQ (HTTP API, codigo, arquitetura, troubleshooting)
+├── eng-backend-nestjs/           # Framework NestJS: módulos, DI, guards, interceptors, pipes, Passport/JWT
 │   └── SKILL.md
-├── eng-cybersecurity/    # Segurança de aplicações: OWASP Top 10, secrets, supply chain, headers, SAST, compliance
+├── eng-backend-rabbitmq/         # Mensageria RabbitMQ (HTTP API, codigo, arquitetura, troubleshooting)
 │   └── SKILL.md
-├── churn-audit/          # Análise de churn SaaS por squad com relatório narrativo via $MESSAGE_COMUNICATOR
+├── eng-security-cybersecurity/    # Segurança de aplicações: OWASP Top 10, secrets, supply chain, headers, SAST, compliance
 │   └── SKILL.md
-├── eng-scraper/          # Web scraping com Puppeteer, Cheerio, anti-bot, pipelines ETL
+├── eng-backend-microservices-trace/ # Rastreamento de bugs entre serviços (HTTP + AMQP); especialização de backend
 │   └── SKILL.md
-├── eng-scraper-robot-builder/ # Converte fluxo manual (linguagem natural) em robô Playwright via Stagehand
+├── eng-security-threat-model/ # Threat model estruturado do projeto (bootstrap/entrevista)
+│   └── SKILL.md
+├── eng-security-triage/ # Deduplicar, verificar e rankear achados de segurança
+│   └── SKILL.md
+├── eng-security-patch/ # Diffs candidatos para achados de segurança confirmados
+│   └── SKILL.md
+├── eng-devops-performance-engineer/ # Performance: baseline, SLIs/SLOs, load tests
+│   └── SKILL.md
+├── eng-ai-engineer/ # Features com LLM, RAG, agentes, embeddings
+│   └── SKILL.md
+├── eng-global-browser-extension-builder/ # Extensões de navegador (Manifest V3)
+│   └── SKILL.md
+├── eng-data-engineer/ # Pipelines ETL/ELT, camadas bronze/silver/gold, contratos de dados
+│   └── SKILL.md
+├── eng-data-bi/ # Dashboards BI e queries analíticas
+│   └── SKILL.md
+├── eng-data-debug/ # Diagnóstico de falhas em pipelines por camada
+│   └── SKILL.md
+├── eng-data-onboard/ # Onboarding de fonte nova de dados
+│   └── SKILL.md
+├── eng-data-orchestrator/ # DAGs, retries e alertas de orquestração
 │   └── SKILL.md
-├── eng-tech-analyst/          # Triagem de chamados do HUBS board: keywords, sub-bug linking, frequência via comentários no card, encaminhamento para squad
+├── eng-qa-bug-report/ # Bug reports de QA
 │   └── SKILL.md
-├── lovable-prompt-generator/ # Geracao de prompts para frontend React via Lovable
+├── product-specs/ # Porta de entrada de especificação de produto
 │   └── SKILL.md
-├── docs-index/           # Indexacao de documentos
+├── product-specs-update/ # Sincroniza especificações de produto
 │   └── SKILL.md
-├── init-jarvis/         # Inicializacao do framework (/init-jarvis)
+├── product-roadmap-report/ # Relatório de status do roadmap
+│   └── SKILL.md
+├── eng-scraper/          # Web scraping com Puppeteer, Cheerio, anti-bot, pipelines ETL
+│   └── SKILL.md
+├── eng-scraper-robot-builder/ # Converte fluxo manual (linguagem natural) em robô Playwright via Stagehand
+│   └── SKILL.md
+├── jarvis-docs-index/           # Indexacao de documentos
+│   └── SKILL.md
+├── jarvis-init/         # Inicializacao do framework (/jarvis-init), com o passo opcional de adicionar as stacks
 │   ├── SKILL.md
 │   └── assets/
 ├── eng-qa-gate/              # Quality gate validation
@@ -81,11 +112,11 @@ skills/
 │   └── SKILL.md
 ├── eng-qa-unit-test/         # Testes unitarios
 │   └── SKILL.md
-├── report-issue/         # Reportar bug no próprio Jarvis (JARVIS_PROJECT)
+├── jarvis-report-issue/         # Reportar bug no próprio Jarvis (JARVIS_PROJECT)
 │   └── SKILL.md
-├── context-detect/       # Detecta contexto do projeto/tarefa
+├── jarvis-context-detect/       # Detecta contexto do projeto/tarefa
 │   └── SKILL.md
-└── docs-central/         # Sync/publish docs no central-docs (GitLab/GitHub/Bitbucket)
+└── jarvis-docs-central/         # Sync/publish docs no central-docs (GitLab/GitHub/Bitbucket)
     └── SKILL.md
 ```
 
@@ -127,19 +158,52 @@ license: AGPL-3.0
 metadata:
   author: jarvis-team
   version: "1.0"
+  area: backend        # obrigatório: área do skill (ver "Áreas e nomes")
+  stack: golang        # só em especializações de backend/frontend
 ---
 ```
 
+> **`metadata.area` é obrigatório.** Um skill instalado sem área reconhecida faz os comandos `eng.*` serem bloqueados (ver `rules/engineering/eng.skills-rules.md`).
+
 ---
 
-## Convencoes de Nomenclatura
+## Áreas e nomes
+
+### Áreas reconhecidas (`metadata.area`)
+
+| Área | O que cobre |
+|------|-------------|
+| `backend` | APIs, autenticação, workers, mensageria, banco de dados |
+| `frontend` | Componentes, estado, estilos, performance de UI, acessibilidade |
+| `qa` | Testes, quality gates, relatórios de qualidade |
+| `data` | Pipelines, qualidade e contratos de dados |
+| `ai` | Features com modelos de IA |
+| `security` | Segurança de aplicações |
+| `scraper` | Scraping e automação de robôs |
+| `devops` | Performance, infraestrutura, entrega |
+| `global` | Skills transversais de engenharia e do próprio framework |
+| `product` | Especificação de produto |
+
+Skill sem `metadata.area`, ou com área fora desta lista, é tratado como **sem área** (`unknown`) e bloqueia os comandos `eng.*`.
+
+### Nome do skill
+
+O nome tem a forma `<prefixo>-<área>-<nome>`; **só os dois primeiros segmentos importam** para a regra, o resto é livre.
+
+| Tipo | Padrão | Exemplos |
+|------|--------|----------|
+| Engenharia por área | `eng-<área>-<nome>` | `eng-qa-gate`, `eng-data-engineer`, `eng-security-cybersecurity` |
+| Skill base de backend/frontend | `eng-backend`, `eng-frontend` | — |
+| Especialização de stack | `eng-<backend\|frontend>-<stack>` | `eng-backend-nestjs`, `eng-frontend-design-system` |
+| Engenharia global | `eng-global-<nome>` | `eng-global-pr`, `eng-global-docs-write` |
+| Produto | `product-<nome>` | `product-specs`, `product-specs-update` |
+| Transversal do framework | `jarvis-<nome>` (`area: global`) | `jarvis-init`, `jarvis-docs-central` |
+
+### Skill base, especialização e `stack`
 
-| Domínio | Prefixo | Exemplos |
-|---------|---------|----------|
-| Engenharia | `eng-` | `eng-docs-write`, `eng-pr`, `eng-arch-c4` |
-| Produto | `prod-` | `prod-prd`, `prod-frd`, `prod-epic` |
-| QA | `qa-` | `eng-qa-gate`, `eng-qa-test-plan`, `eng-qa-unit-test` |
-| Geral / utilitário | _(sem prefixo)_ | `skill-creator`, `docs-index`, `init-jarvis` |
+- **Base:** `area: backend` ou `frontend`, **sem** `stack`. É sempre carregado pela regra `eng.specializations-rules.md`.
+- **Especialização:** `area: backend` ou `frontend`, **com** `metadata.stack` (o sufixo do nome). Só é carregada quando o projeto a registra em `BACKEND_SPECIALIZATIONS` ou `FRONTEND_SPECIALIZATIONS` no `ENV.md`.
+- Demais áreas não têm lista e não usam `stack`.
 
 ---
 
@@ -195,33 +259,32 @@ Skills são invocados de formas diferentes dependendo da IDE:
 
 | Comando / Trigger | Skill |
 |-------------------|-------|
-| `/init-jarvis` | `init` |
-| `/eng.docs` | `eng-docs-write`, `docs-index` |
+| `/jarvis-init` | `jarvis-init` |
+| `/eng.docs` | `eng-global-docs-write`, `jarvis-docs-index` |
 | `/eng.pre-pr` | `eng-qa-test-plan` |
-| `/eng.pr` | `eng-pr` |
+| `/eng.pr` | `eng-global-pr` |
 | QA validation | `eng-qa-gate` |
 | Criar skill | `skill-creator` |
 | `/taxonomy-manager` | `taxonomy-manager` |
+| Listar especializações de stack (instaladas e registradas) | `jarvis-list-specializations` |
+| Criar uma especialização de stack (backend ou frontend) a partir do código do projeto | `jarvis-create-specialization` |
 | `/members-manager` | `members-manager` |
-| Mensageria, filas, RabbitMQ, events, consumers, producers | `eng-rabbitmq` |
-| Gerar prompt para Lovable, criar frontend React com Lovable | `lovable-prompt-generator` |
-| APIs REST/GraphQL, auth, workers, RabbitMQ, caching | `eng-backend` |
-| Componentes, UI, estado, SSR/SSG, performance, acessibilidade | `eng-frontend` |
-| Micro frontend, Module Federation, shell/remote, contratos de interface | `eng-microfrontend` |
-| Design system, tokens, CVA, Storybook, versionamento de componentes | `eng-design-system` |
-| Módulos NestJS, DI, guards, interceptors, pipes, Passport/JWT | `eng-nestjs` |
+| Mensageria, filas, RabbitMQ, events, consumers, producers | `eng-backend-rabbitmq` (especialização de backend: registrar em `BACKEND_SPECIALIZATIONS`) |
+| APIs, auth, workers, filas, caching, banco de dados | `eng-backend` (base) + `BACKEND_SPECIALIZATIONS` |
+| Componentes, UI, estado, estilos, performance, acessibilidade | `eng-frontend` (base) + `FRONTEND_SPECIALIZATIONS` |
+| Micro frontend, Module Federation, shell/remote, contratos de interface | `eng-frontend-microfrontend` (especialização de frontend) |
+| Design system, tokens, CVA, Storybook, versionamento de componentes | `eng-frontend-design-system` (especialização de frontend) |
+| Módulos NestJS, DI, guards, interceptors, pipes, Passport/JWT | `eng-backend-nestjs` (especialização de backend) |
 | Web scraping, Puppeteer, extração de dados, parsing, ETL | `eng-scraper` |
 | Criar robô RPA novo ou manter existente (new|update + card) | `eng.rpa.robot` (workflow) |
-| Atendimento técnico, triagem de chamados, diagnóstico, classificação de bugs, escalonamento | `eng-tech-analyst` |
 | Gerar specs Cypress + TypeScript para fluxos de usuário | `eng-qa-cypress-e2e` |
 | Sessão de teste exploratório estruturada (charter, risco, achados, bug cards) | `eng-qa-exploratory` |
 | Orientar dev sobre cobertura Cypress sem escrever o teste | `eng-qa-dev-guide` |
 | Consolidar sessões exploratórias, bugs e quality gates e gerar relatório de qualidade por sprint/release | `eng-qa-quality-report` |
-| Análise de churn SaaS: coleta Slack, classificação por squad via taxonomy, relatório narrativo | `churn-audit` |
 | Testes de acessibilidade WCAG 2.1 AA: integra jest-axe em testes unitários existentes | `eng-qa-a11y-audit` |
 | Testes de contrato GraphQL: valida queries frontend contra schema do BFF | `eng-qa-graphql-contract` |
 | Spec E2E para handoff: cenários priorizados, Page Objects, fixtures, intercepts, setup | `eng-qa-e2e-spec-writer` |
-| Segurança de aplicações: OWASP Top 10, secrets, sanitização, headers, supply chain, compliance | `eng-cybersecurity` |
+| Segurança de aplicações: OWASP Top 10, secrets, sanitização, headers, supply chain, compliance | `eng-security-cybersecurity` |
 
 ---
 
@@ -235,10 +298,11 @@ Use o skill-creator:
 
 Ou manualmente:
 
-1. Criar pasta: `skills/{nome}/`
-2. Copiar template: `skills/skill-creator/assets/SKILL-template.md`
-3. Preencher todos os placeholders
-4. Validar estrutura
+1. Escolher a **área** e o nome no padrão `<prefixo>-<área>-<nome>` (ver "Áreas e nomes")
+2. Criar pasta: `skills/{nome}/`
+3. Copiar template: `skills/skill-creator/assets/SKILL-template.md`
+4. Preencher todos os placeholders, **inclusive `metadata.area`** (e `metadata.stack` se for especialização)
+5. Validar estrutura: `name` igual ao nome da pasta e área reconhecida
 
 ---
 
@@ -246,7 +310,7 @@ Ou manualmente:
 
 ### Nunca
 
-- Criar skill sem frontmatter completo
+- Criar skill sem frontmatter completo ou sem `metadata.area`
 - Duplicar skill existente
 - Colocar detalhes de persona (isso vai no agent)
 - Usar URLs web em references (use caminhos locais)