izanagi-ai 3.6.0 → 3.8.0

package/.claude/skills/accessibility-reviewer/SKILL.md

@@ -3,111 +3,111 @@ name: accessibility-reviewer
 description: "Audita acessibilidade WCAG 2.2 AA/AAA: contraste, navegação por teclado, ARIA e leitores de tela. Use ao revisar componentes ou páginas antes de merge/deploy."
 ---
 
-# Accessibility Reviewer (WCAG 2.2 AA)
-
-Auditoria de acessibilidade rigorosa contra padrões **WCAG 2.2 (nível AA e AAA)** — garantindo que pessoas com deficiência visual, motora, auditiva ou cognitiva consigam operar o sistema perfeitamente.
-
-## Quando usar
-
-Use ao: revisar componentes ou telas novas; auditar páginas antes de release; testar navegação por teclado e leitores de tela; validar contraste de cores do design system. **Pule** para: revisão geral de usabilidade sem foco em a11y (skill `ux-reviewer`); auditoria de código geral (skill `code-auditor`).
-
-## Princípios WCAG 2.2 (Perceptível, Operável, Compreensível, Robusto)
-
-### 1. Perceptible (Perceptível)
-- **Contraste de cores**: Relação mínima de `4.5:1` para texto normal e `3:1` para texto grande (≥18pt ou bold ≥14pt). Componentes de UI e ícones ativos: mínimo `3:1` contra o fundo.
-- **Alternativas textuais**: Toda imagem informativa tem `alt` descritivo; imagens puramente decorativas usam `alt=""` ou `aria-hidden="true"`.
-- **Conteúdo adaptável**: Informação e estrutura conveyadas por apresentação podem ser programaticamente determinadas (uso de headings h1-h6 sem pular níveis).
-
-### 2. Operable (Operável)
-- **Acessível por teclado**: 100% das funcionalidades operáveis via teclado (`Tab`, `Shift+Tab`, `Enter`, `Space`, setas). Zero armadilhas de foco (*keyboard traps*).
-- **Indicador de foco visível**: `focus-visible` customizado e claro (nunca `outline: none` sem substituto visível).
-- **Tempo suficiente**: Sem limites de tempo em formulários sem opção de extensão ou pausa.
-- **Área de toque adequada**: Alvos interativos com mínimo de `44x44px` (ou espaçamento equivalente).
-
-### 3. Understandable (Compreensível)
-- **Idioma da página**: Atributo `lang="pt-BR"` (ou adequado) no elemento `<html>`.
-- **Rótulos claros**: Todo input de formulário possui `<label>` explícito (`for`/`id`) ou `aria-label`/`aria-labelledby`.
-- **Prevenção e recuperação de erro**: Mensagens de erro inline claras, associadas ao campo via `aria-describedby` ou `aria-invalid="true"`.
-
-### 4. Robust (Robusto)
-- **HTML Semântico**: Uso correto de landmarks (`<main>`, `<nav>`, `<header>`, `<footer>`, `<aside>`, `<section>`).
-- **Atributos ARIA válidos**: Uso estrito apenas quando o HTML nativo não basta (ex: estados complexos como `aria-expanded`, `aria-selected`, `aria-live`).
-
-## Workflow de auditoria (4 passos)
-
-### 1. Inspeção automatizada (triagem inicial)
-```bash
-npx axe-core-cli https://localhost:3000   # ou integração com Playwright/Lighthouse
-```
-
-### 2. Validação de teclado (sem mouse)
-- Navegue pela página inteira usando apenas `Tab` e `Shift+Tab`.
-- Verifique se a ordem de foco é lógica (esquerda para direita, cima para baixo).
-- Confirme se o anel de foco (`focus-visible`) está visível em todos os botões, links e inputs.
-
-### 3. Verificação de contraste e zoom
-- Use ferramentas de cor (Eyedropper / axe DevTools) nas combinações texto/fundo.
-- Teste a página com zoom de `200%` — o layout não pode quebrar nem perder conteúdo.
-
-### 4. Relatório de achados
-Formate os achados com severidade, elemento HTML, falha WCAG e correção em código.
-
-## Exemplo de código acessível (componente de botão com loading e ARIA)
-
-```tsx
-interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
-  isLoading?: boolean;
-  children: React.ReactNode;
-}
-
-export function AccessibleButton({ isLoading, children, disabled, ...props }: ButtonProps) {
-  return (
-    <button
-      disabled={disabled || isLoading}
-      aria-busy={isLoading}
-      className="px-4 py-2 rounded-lg bg-zinc-100 text-zinc-900 font-medium focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-rose-500 disabled:opacity-50"
-      {...props}
-    >
-      {isLoading ? (
-        <span className="flex items-center gap-2">
-          <svg className="animate-spin h-4 w-4 text-current" viewBox="0 0 24 24" aria-hidden="true">
-            {/* path do spinner */}
-          </svg>
-          <span className="sr-only">Carregando...</span>
-          <span>{children}</span>
-        </span>
-      ) : (
-        children
-      )}
-    </button>
-  );
-}
-```
-
-## Checklist de qualidade (antes de entregar)
-- [ ] Contraste de texto atende 4.5:1 (AA)
-- [ ] 100% operável via teclado, sem armadilhas de foco
-- [ ] Indicador de foco (`focus-visible`) presente e destacado
-- [ ] Inputs com `<label>` associado ou `aria-label`
-- [ ] Estrutura de headings (`h1` a `h6`) sem saltar níveis
-- [ ] Atributos ARIA corretos em componentes customizados
-- [ ] Suporte a zoom 200% sem perda de funcionalidade
-- [ ] Testado com axe-core ou leitor de tela
-
-## Anti-padrões (proibido)
-1. ❌ `outline: none` em elementos interativos sem anel de foco customizado
-2. ❌ Usar `<div>` ou `<span>` com `onClick` sem `role="button"`, `tabIndex={0}` e suporte a `Enter`/`Space`
-3. ❌ Imagens informativas sem `alt` ou com `alt="imagem"`
-4. ❌ Texto cinza claro (#9ca3af) em fundo branco (contraste insuficiente)
-5. ❌ Modais que permitem o foco escapar para o fundo da página (sem focus trap)
-6. ❌ Uso excessivo de ARIA desnecessário onde HTML nativo resolve (`<button>` vs `<div role="button">`)
-
-## Composição com outras skills
-- **Antes**: `frontend` (construção da UI) → `design-directions` (paleta com contraste garantido)
-- **Depois**: `ux-reviewer` (heurísticas de usabilidade) → `qa` (testes E2E com axe/Playwright)
-
-## References
-- WCAG 2.2 QuickRef: https://www.w3.org/WAI/WCAG22/quickref/ · ARIA Authoring Practices Guide (APG): https://www.w3.org/WAI/ARIA/apg/ · axe-core: https://www.deque.com/axe/
+# Accessibility Reviewer (WCAG 2.2 AA)
+
+Auditoria de acessibilidade rigorosa contra padrões **WCAG 2.2 (nível AA e AAA)** — garantindo que pessoas com deficiência visual, motora, auditiva ou cognitiva consigam operar o sistema perfeitamente.
+
+## Quando usar
+
+Use ao: revisar componentes ou telas novas; auditar páginas antes de release; testar navegação por teclado e leitores de tela; validar contraste de cores do design system. **Pule** para: revisão geral de usabilidade sem foco em a11y (skill `ux-reviewer`); auditoria de código geral (skill `code-auditor`).
+
+## Princípios WCAG 2.2 (Perceptível, Operável, Compreensível, Robusto)
+
+### 1. Perceptible (Perceptível)
+- **Contraste de cores**: Relação mínima de `4.5:1` para texto normal e `3:1` para texto grande (≥18pt ou bold ≥14pt). Componentes de UI e ícones ativos: mínimo `3:1` contra o fundo.
+- **Alternativas textuais**: Toda imagem informativa tem `alt` descritivo; imagens puramente decorativas usam `alt=""` ou `aria-hidden="true"`.
+- **Conteúdo adaptável**: Informação e estrutura conveyadas por apresentação podem ser programaticamente determinadas (uso de headings h1-h6 sem pular níveis).
+
+### 2. Operable (Operável)
+- **Acessível por teclado**: 100% das funcionalidades operáveis via teclado (`Tab`, `Shift+Tab`, `Enter`, `Space`, setas). Zero armadilhas de foco (*keyboard traps*).
+- **Indicador de foco visível**: `focus-visible` customizado e claro (nunca `outline: none` sem substituto visível).
+- **Tempo suficiente**: Sem limites de tempo em formulários sem opção de extensão ou pausa.
+- **Área de toque adequada**: Alvos interativos com mínimo de `44x44px` (ou espaçamento equivalente).
+
+### 3. Understandable (Compreensível)
+- **Idioma da página**: Atributo `lang="pt-BR"` (ou adequado) no elemento `<html>`.
+- **Rótulos claros**: Todo input de formulário possui `<label>` explícito (`for`/`id`) ou `aria-label`/`aria-labelledby`.
+- **Prevenção e recuperação de erro**: Mensagens de erro inline claras, associadas ao campo via `aria-describedby` ou `aria-invalid="true"`.
+
+### 4. Robust (Robusto)
+- **HTML Semântico**: Uso correto de landmarks (`<main>`, `<nav>`, `<header>`, `<footer>`, `<aside>`, `<section>`).
+- **Atributos ARIA válidos**: Uso estrito apenas quando o HTML nativo não basta (ex: estados complexos como `aria-expanded`, `aria-selected`, `aria-live`).
+
+## Workflow de auditoria (4 passos)
+
+### 1. Inspeção automatizada (triagem inicial)
+```bash
+npx axe-core-cli https://localhost:3000   # ou integração com Playwright/Lighthouse
+```
+
+### 2. Validação de teclado (sem mouse)
+- Navegue pela página inteira usando apenas `Tab` e `Shift+Tab`.
+- Verifique se a ordem de foco é lógica (esquerda para direita, cima para baixo).
+- Confirme se o anel de foco (`focus-visible`) está visível em todos os botões, links e inputs.
+
+### 3. Verificação de contraste e zoom
+- Use ferramentas de cor (Eyedropper / axe DevTools) nas combinações texto/fundo.
+- Teste a página com zoom de `200%` — o layout não pode quebrar nem perder conteúdo.
+
+### 4. Relatório de achados
+Formate os achados com severidade, elemento HTML, falha WCAG e correção em código.
+
+## Exemplo de código acessível (componente de botão com loading e ARIA)
+
+```tsx
+interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+  isLoading?: boolean;
+  children: React.ReactNode;
+}
+
+export function AccessibleButton({ isLoading, children, disabled, ...props }: ButtonProps) {
+  return (
+    <button
+      disabled={disabled || isLoading}
+      aria-busy={isLoading}
+      className="px-4 py-2 rounded-lg bg-zinc-100 text-zinc-900 font-medium focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-rose-500 disabled:opacity-50"
+      {...props}
+    >
+      {isLoading ? (
+        <span className="flex items-center gap-2">
+          <svg className="animate-spin h-4 w-4 text-current" viewBox="0 0 24 24" aria-hidden="true">
+            {/* path do spinner */}
+          </svg>
+          <span className="sr-only">Carregando...</span>
+          <span>{children}</span>
+        </span>
+      ) : (
+        children
+      )}
+    </button>
+  );
+}
+```
+
+## Checklist de qualidade (antes de entregar)
+- [ ] Contraste de texto atende 4.5:1 (AA)
+- [ ] 100% operável via teclado, sem armadilhas de foco
+- [ ] Indicador de foco (`focus-visible`) presente e destacado
+- [ ] Inputs com `<label>` associado ou `aria-label`
+- [ ] Estrutura de headings (`h1` a `h6`) sem saltar níveis
+- [ ] Atributos ARIA corretos em componentes customizados
+- [ ] Suporte a zoom 200% sem perda de funcionalidade
+- [ ] Testado com axe-core ou leitor de tela
+
+## Anti-padrões (proibido)
+1. ❌ `outline: none` em elementos interativos sem anel de foco customizado
+2. ❌ Usar `<div>` ou `<span>` com `onClick` sem `role="button"`, `tabIndex={0}` e suporte a `Enter`/`Space`
+3. ❌ Imagens informativas sem `alt` ou com `alt="imagem"`
+4. ❌ Texto cinza claro (#9ca3af) em fundo branco (contraste insuficiente)
+5. ❌ Modais que permitem o foco escapar para o fundo da página (sem focus trap)
+6. ❌ Uso excessivo de ARIA desnecessário onde HTML nativo resolve (`<button>` vs `<div role="button">`)
+
+## Composição com outras skills
+- **Antes**: `frontend` (construção da UI) → `design-directions` (paleta com contraste garantido)
+- **Depois**: `ux-reviewer` (heurísticas de usabilidade) → `qa` (testes E2E com axe/Playwright)
+
+## References
+- WCAG 2.2 QuickRef: https://www.w3.org/WAI/WCAG22/quickref/ · ARIA Authoring Practices Guide (APG): https://www.w3.org/WAI/ARIA/apg/ · axe-core: https://www.deque.com/axe/
 - Veja `references.md` nesta pasta — curadoria de fontes canônicas (2026).
 
 > Gerado pelo Izanagi AI: cópia fiel de `skills/accessibility-reviewer/SKILL.md` (fonte da verdade).

package/.claude/skills/adversarial-critique/SKILL.md

@@ -3,38 +3,38 @@ name: adversarial-critique
 description: "Crítica adversarial de implementações: caça bugs, falhas de segurança, arquitetura e edge cases, com veredicto READY/READY_WITH_FIXES/NOT_READY. Use após qualquer implementação e antes da avaliação final."
 ---
 
-# Adversarial Critique — Tente Quebrar Antes da Produção
-
-> **Sua função não é implementar. É encontrar problemas.**
-
-## Identity
-
-Você é o ADVERSARIAL CRITIC do Izanagi. Recebe uma implementação e procura ativamente por problemas, com justificativa técnica para cada finding.
-
-## Workflow
-
-1. **Leia os requisitos originais** — verifique cobertura item por item.
-2. **Passeio adversarial pelo código**:
-   - Bugs: null/undefined, condições de corrida, off-by-one, async mal tratado, estados inconsistentes, memory leaks.
-   - Segurança: SQL/XSS/command injection, auth quebrada, secrets expostos, IDOR, SSRF, CORS errado, headers ausentes.
-   - Arquitetura: camadas violadas, acoplamento, dependências circulares, lógica de negócio em framework.
-   - Performance: N+1, loops O(n²), re-renders desnecessários, assets pesados.
-   - Edge cases: input vazio, valores extremos, unicode, timezone/locale, concorrência.
-   - Overengineering: abstrações sem retorno, complexidade acidental.
-   - AI slop: UI genérica, copy clichê, padrões robóticos (aplique anti-ai-slop).
-3. **Emita findings**: cada um com severidade (CRITICAL/HIGH/MEDIUM/LOW), local (arquivo+linha quando possível), impacto e sugestão de correção concreta.
-4. **Veredicto final**: READY / READY_WITH_FIXES / NOT_READY + lista priorizada de fixes.
-
-## Rules
-
-- Você **não corrige**: aponta com precisão; quem corrige é o senior-engineer.
-- Nenhum finding sem justificativa técnica — não reporte por vaidade.
-- Não aceite "funciona na minha máquina": questione portabilidade e produção.
-
-## Validation
-
-- Todo requisito original mapeado para: implementado | parcial | faltante.
-- Findings classificados com severidade.
+# Adversarial Critique — Tente Quebrar Antes da Produção
+
+> **Sua função não é implementar. É encontrar problemas.**
+
+## Identity
+
+Você é o ADVERSARIAL CRITIC do Izanagi. Recebe uma implementação e procura ativamente por problemas, com justificativa técnica para cada finding.
+
+## Workflow
+
+1. **Leia os requisitos originais** — verifique cobertura item por item.
+2. **Passeio adversarial pelo código**:
+   - Bugs: null/undefined, condições de corrida, off-by-one, async mal tratado, estados inconsistentes, memory leaks.
+   - Segurança: SQL/XSS/command injection, auth quebrada, secrets expostos, IDOR, SSRF, CORS errado, headers ausentes.
+   - Arquitetura: camadas violadas, acoplamento, dependências circulares, lógica de negócio em framework.
+   - Performance: N+1, loops O(n²), re-renders desnecessários, assets pesados.
+   - Edge cases: input vazio, valores extremos, unicode, timezone/locale, concorrência.
+   - Overengineering: abstrações sem retorno, complexidade acidental.
+   - AI slop: UI genérica, copy clichê, padrões robóticos (aplique anti-ai-slop).
+3. **Emita findings**: cada um com severidade (CRITICAL/HIGH/MEDIUM/LOW), local (arquivo+linha quando possível), impacto e sugestão de correção concreta.
+4. **Veredicto final**: READY / READY_WITH_FIXES / NOT_READY + lista priorizada de fixes.
+
+## Rules
+
+- Você **não corrige**: aponta com precisão; quem corrige é o senior-engineer.
+- Nenhum finding sem justificativa técnica — não reporte por vaidade.
+- Não aceite "funciona na minha máquina": questione portabilidade e produção.
+
+## Validation
+
+- Todo requisito original mapeado para: implementado | parcial | faltante.
+- Findings classificados com severidade.
 - Veredicto final claro com lista priorizada.
 
 > Gerado pelo Izanagi AI: cópia fiel de `skills/adversarial-critique/SKILL.md` (fonte da verdade).

package/.claude/skills/agentic-coding/SKILL.md

@@ -3,86 +3,86 @@ name: agentic-coding
 description: "Loop de codificação autônoma (planejar, codar, testar, corrigir) com verificação empírica obrigatória e tentativas limitadas. Use ao implementar features ou corrigir falhas de build/teste."
 ---
 
-# Agentic Coding (Codificação Autônoma em Loop)
-
-O agente que codifica em ciclo fechado: planeja, executa em incrementos pequenos, verifica com comandos reais, diagnostica falhas pelo log e corrige o delta. Nenhuma tarefa é declarada concluída sem evidência empírica (build, teste ou log executado).
-
-## Quando usar
-
-Use ao implementar features, corrigir erros de build/teste, refatorar ou rodar sessões longas de código onde o resultado só é conhecido depois de executar. **Pule para**: `parallel-agents` quando a tarefa se divide em 2+ domínios independentes (UI + backend + DB); `professor-modo` quando o pedido é só explicação; `brainstorming` quando o design ainda não existe.
-
-## Stack / Padrões
-
-- **Comandos de verificação do projeto** (`npm run build`, `npm test`, `npm run doctor`) — a evidência empírica que fecha o loop. Descubra os comandos reais no `package.json`/README antes de começar.
-- **`git diff` / `git status`** — revisão por delta em vez de releitura total (token economy).
-- **Log completo do erro** — diagnóstico por causa raiz, nunca por resumo truncado.
-
-## Workflow (6 passos)
-
-1. **Planeje demarcado**: antes de tocar em arquivo, liste os arquivos a criar/editar e verifique premissas por inspeção direta (grep/read) — nunca suponha API ou assinatura que não viu.
-
-2. **Execute incrementalmente**: uma mudança por vez, um arquivo por passada, editando por diff. Alteração destrutiva (delete/rename em massa) exige confirmação.
-
-3. **Verifique empiricamente** — loop finito com limite de tentativas (nunca `while true`):
-
-```powershell
-# Loop de verificação com teto de tentativas (PowerShell)
-$tentativas = 0
-do {
-  $tentativas++
-  npm run build 2>&1 | Tee-Object -FilePath .agents\tmp\build.log
-  if ($LASTEXITCODE -ne 0) {
-    $erro = Select-String -Path .agents\tmp\build.log -Pattern "error TS|Error:" | Select-Object -First 1
-    Write-Host "FALHA ($tentativas/3): $($erro.Line)"
-  }
-} while ($LASTEXITCODE -ne 0 -and $tentativas -lt 3)
-if ($LASTEXITCODE -ne 0) { Write-Host "ESCALAR: mudar abordagem ou perguntar." }
-```
-
-4. **Diagnostique pelo log**: leia o erro inteiro (não só o summary), identifique arquivo+linha, formule a hipótese e confirme antes de corrigir. Corrija **apenas o primeiro erro** da lista — os demais costumam ser sintomas encadeados.
-
-5. **Self-fix com regressão**: após corrigir, rode o comando que falhou **e** a suíte vizinha. Nunca desabilite teste quebrado para passar.
-
-6. **Reflita e feche**: resumo do que mudou com as evidências (saída de build/teste) e, se descobriu padrão novo, registre em `.agents/memoria/learnings.md`.
-
-## Regras de ouro
-
-- **Sempre** exigir evidência de execução (log/teste real) antes de declarar pronto.
-- Loop é sempre finito: máx. 3 tentativas por erro; estourou, **mude a abordagem**.
-- Uma mudança por verificação: corrija 1 erro, rode, corrija o próximo.
-- Nunca assumir API/assinatura sem inspeção direta do código.
-- Nunca engolir exceções (`catch {}`) para fingir sucesso.
-- Nunca re-verificar por releitura total — revise o diff.
-- Nenhuma tarefa é concluída sem o comando real do projeto ter rodado.
-
-## Checklist
-
-- [ ] Plano explicita arquivos a criar/editar
-- [ ] Premissas verificadas por inspeção (grep/read)
-- [ ] Build/teste real executado com evidência no output
-- [ ] Loop com limite de tentativas (sem loop infinito)
-- [ ] Nenhum teste desabilitado para "passar"
-- [ ] Diff revisado antes da entrega
-- [ ] Aprendizado registrado se houve padrão novo
-
-## Anti-padrões
-
-1. ❌ **Loop sem limite** ("vou tentar até dar certo") — queima tokens e acumula mudanças não revertidas.
-2. ❌ **Correção em lote** (10 erros de uma vez) — erros encadeados; o primeiro fix derruba os demais.
-3. ❌ **API suposta** ("essa lib deve ter X") sem verificar — alucinação de interface vira build quebrado.
-4. ❌ **Exceção engolida** — esconde a falha e invalida a própria verificação.
-5. ❌ **Pronto por inspeção** ("deve funcionar") — código que não compilou não existe.
-6. ❌ **Reler o arquivo inteiro para conferir** — custo de tokens; `git diff` cobre.
-7. ❌ **Persistir na mesma abordagem após 3 falhas** — insanidade do loop; escalar ou perguntar.
-
-## Composição com outras skills
-
-- **Antes**: `memoria-projeto` (erros já corrigidos e decisões), `tdd` (escrever o teste que falha antes do código), `task-planner` (frentes pequenas), `economia-tokens` (contexto mínimo)
-- **Depois**: `self-critique` (revisão do diff), `qa` (auditoria final), `professor-modo` (explicar o que mudou)
-
-## References
-
-- pytest: https://docs.pytest.org · Node.js: https://nodejs.org/api · Git: https://git-scm.com/doc
+# Agentic Coding (Codificação Autônoma em Loop)
+
+O agente que codifica em ciclo fechado: planeja, executa em incrementos pequenos, verifica com comandos reais, diagnostica falhas pelo log e corrige o delta. Nenhuma tarefa é declarada concluída sem evidência empírica (build, teste ou log executado).
+
+## Quando usar
+
+Use ao implementar features, corrigir erros de build/teste, refatorar ou rodar sessões longas de código onde o resultado só é conhecido depois de executar. **Pule para**: `parallel-agents` quando a tarefa se divide em 2+ domínios independentes (UI + backend + DB); `professor-modo` quando o pedido é só explicação; `brainstorming` quando o design ainda não existe.
+
+## Stack / Padrões
+
+- **Comandos de verificação do projeto** (`npm run build`, `npm test`, `npm run doctor`) — a evidência empírica que fecha o loop. Descubra os comandos reais no `package.json`/README antes de começar.
+- **`git diff` / `git status`** — revisão por delta em vez de releitura total (token economy).
+- **Log completo do erro** — diagnóstico por causa raiz, nunca por resumo truncado.
+
+## Workflow (6 passos)
+
+1. **Planeje demarcado**: antes de tocar em arquivo, liste os arquivos a criar/editar e verifique premissas por inspeção direta (grep/read) — nunca suponha API ou assinatura que não viu.
+
+2. **Execute incrementalmente**: uma mudança por vez, um arquivo por passada, editando por diff. Alteração destrutiva (delete/rename em massa) exige confirmação.
+
+3. **Verifique empiricamente** — loop finito com limite de tentativas (nunca `while true`):
+
+```powershell
+# Loop de verificação com teto de tentativas (PowerShell)
+$tentativas = 0
+do {
+  $tentativas++
+  npm run build 2>&1 | Tee-Object -FilePath .agents\tmp\build.log
+  if ($LASTEXITCODE -ne 0) {
+    $erro = Select-String -Path .agents\tmp\build.log -Pattern "error TS|Error:" | Select-Object -First 1
+    Write-Host "FALHA ($tentativas/3): $($erro.Line)"
+  }
+} while ($LASTEXITCODE -ne 0 -and $tentativas -lt 3)
+if ($LASTEXITCODE -ne 0) { Write-Host "ESCALAR: mudar abordagem ou perguntar." }
+```
+
+4. **Diagnostique pelo log**: leia o erro inteiro (não só o summary), identifique arquivo+linha, formule a hipótese e confirme antes de corrigir. Corrija **apenas o primeiro erro** da lista — os demais costumam ser sintomas encadeados.
+
+5. **Self-fix com regressão**: após corrigir, rode o comando que falhou **e** a suíte vizinha. Nunca desabilite teste quebrado para passar.
+
+6. **Reflita e feche**: resumo do que mudou com as evidências (saída de build/teste) e, se descobriu padrão novo, registre em `.agents/memoria/learnings.md`.
+
+## Regras de ouro
+
+- **Sempre** exigir evidência de execução (log/teste real) antes de declarar pronto.
+- Loop é sempre finito: máx. 3 tentativas por erro; estourou, **mude a abordagem**.
+- Uma mudança por verificação: corrija 1 erro, rode, corrija o próximo.
+- Nunca assumir API/assinatura sem inspeção direta do código.
+- Nunca engolir exceções (`catch {}`) para fingir sucesso.
+- Nunca re-verificar por releitura total — revise o diff.
+- Nenhuma tarefa é concluída sem o comando real do projeto ter rodado.
+
+## Checklist
+
+- [ ] Plano explicita arquivos a criar/editar
+- [ ] Premissas verificadas por inspeção (grep/read)
+- [ ] Build/teste real executado com evidência no output
+- [ ] Loop com limite de tentativas (sem loop infinito)
+- [ ] Nenhum teste desabilitado para "passar"
+- [ ] Diff revisado antes da entrega
+- [ ] Aprendizado registrado se houve padrão novo
+
+## Anti-padrões
+
+1. ❌ **Loop sem limite** ("vou tentar até dar certo") — queima tokens e acumula mudanças não revertidas.
+2. ❌ **Correção em lote** (10 erros de uma vez) — erros encadeados; o primeiro fix derruba os demais.
+3. ❌ **API suposta** ("essa lib deve ter X") sem verificar — alucinação de interface vira build quebrado.
+4. ❌ **Exceção engolida** — esconde a falha e invalida a própria verificação.
+5. ❌ **Pronto por inspeção** ("deve funcionar") — código que não compilou não existe.
+6. ❌ **Reler o arquivo inteiro para conferir** — custo de tokens; `git diff` cobre.
+7. ❌ **Persistir na mesma abordagem após 3 falhas** — insanidade do loop; escalar ou perguntar.
+
+## Composição com outras skills
+
+- **Antes**: `memoria-projeto` (erros já corrigidos e decisões), `tdd` (escrever o teste que falha antes do código), `task-planner` (frentes pequenas), `economia-tokens` (contexto mínimo)
+- **Depois**: `self-critique` (revisão do diff), `qa` (auditoria final), `professor-modo` (explicar o que mudou)
+
+## References
+
+- pytest: https://docs.pytest.org · Node.js: https://nodejs.org/api · Git: https://git-scm.com/doc
 - Veja `references.md` nesta pasta — curadoria de fontes canônicas (2026).
 
 > Gerado pelo Izanagi AI: cópia fiel de `skills/agentic-coding/SKILL.md` (fonte da verdade).