claudex-forge

Auditoria OFENSIVA (pentest read-only, não-destrutivo) do seu projeto — pensa como ATACANTE, não como bug hunter. Faz inventário da superfície exposta + todas as portas de entrada, ataca na pele de 8 personas (anônimo, link vazado, baixo privilégio, outro usuário/tenant, ex-membro, admin parcial, integração externa), roda um CÉTICO interno que tenta refutar cada achado, e fecha em 3 listas honestas (VULNERÁVEL / TESTADO E BLOQUEADO / NÃO TESTADO). Regra de ouro: nada é confirmado sem evidência contra o sistema NO AR — código, migration e doc podem estar desatualizados. O alvo, o ambiente e o regime de compliance vêm do claudex.config.json e de references/arquitetura.md; se não estiverem lá, o Passo 0 pergunta ao usuário. É uma MÁQUINA DE ESCOPO: sem alvo + ambiente + contas + ações proibidas definidos, ela PARA e pergunta. Acionar quando o usuário disser "/audit-offensive", "auditoria ofensiva", "pentest do projeto", "testa acesso indevido", "alguém consegue ver dado de outro usuário", "testa se vaza dado entre contas", "testa cross-tenant", "testa RLS de verdade", "alguém sem login consegue X", "red team", "testa link público", "ex-membro ainda acessa?" — mesmo sem citar o nome literal. NÃO acionar para caça-bug de 1 componente (use findbugs), nem para review de PR.

Roda na maquina local os checks do seu projeto (typecheck, testes, lint, migrations, security) antes de abrir/mergear PR — sem depender de CI pago ou de esperar o GitHub Actions. Use sempre que o usuario mencionar: rodar os testes local, checks local, validar a PR sem GitHub, "testa aqui antes de mergear", "roda os checks", "a PR ta travada no GitHub", "nao quero gastar minuto do Actions", "passou no CI?", ou quando uma PR estiver travada por checks vermelhos e o usuario quiser destravar. Tambem cobre mergear a PR por bypass de admin quando os checks passarem localmente. Esta e a versao TEMPLATE (claudex-forge). Os comandos rodados sao configurados em scripts/checks.config.sh — preencha com os comandos do SEU stack.

Plugin de desenvolvimento de software com revisao integrada do Codex (GPT). Ciclo completo: investigacao opcional -> plano -> revisao Codex -> implementacao com smoke test -> revisao em camadas -> revisao final. Acionar sempre que o usuario mencionar: implementar feature, corrigir bug, escrever migration, criar/editar funcao serverless, refatorar codigo, "manda pro codex", "revisa com codex", "codex review", "abre uma PR", "/claudex-forge". Filosofia: sequencial e continuo — nao pausa entre fases, so nos 7 casos taxativos abaixo. Fornece versionamento de plano + changelog, aprendizado entre runs, deteccao de loop e smoke test runtime. Tambem acionar quando o pedido vier so com os atalhos da skill: --build, --findbugs, --debug-browser, --full-investigate, --fiel, --desafio, --no-bench, --no-shot, "sem revisao", "so plano", "so implementa". NAO acionar para: consultas de dados no banco (usar MCP especifico do projeto), perguntas que nao envolvam codigo, leitura passiva de arquivos.

Pipeline de debug em 3 fases com 5 agentes para caçar bugs num componente/rota/módulo/arquivo e em TODOS os seus componentes relacionados (hooks, services, edge functions/funções de backend, tabelas/migrations). Versão híbrida que une modos de falha estrutural, checagem de complexidade e procedimento de migrations classificado com regra de evidência transversal, adversário semântico, checklists condicionais por stack e validator cético com proteção estrutural. Auto-detecta stack pelo manifesto e adapta checklists (Supabase, Prisma, Next.js, etc). Fase 1 spawna 3 bug hunters em paralelo (frontend, backend, contratos/integração), Fase 2 spawna 1 cross-validator com dois passes (cético operacional + estrutural-friendly), Fase 3 spawna 1 consolidator com plano de correção ordenado + migrations classificadas. Mudanças de banco só são aplicadas com autorização explícita. É o caminho de bug padrão do /claudex-forge (Fase 0). Acionar quando o usuário mencionar "/findbugs", "findbugs", "claudex-forge:findbugs", "/ultrabugfinder", "ultrabugfinder", "manda o pipeline completo de bug", "debuga essa rota inteira", "debuga esse componente e tudo que ele usa", "caça bugs em [X] e nos relacionados", "pipeline de debug em 3 fases", "encontra todos os bugs desse fluxo", "auditoria profunda de bug" — mesmo sem citar literalmente o nome. NÃO acionar em menções casuais a "bug", "debug" ou "erro" sem alvo claro, nem em pedidos de review geral de código.

Auditor de fricção e intuitividade de interface sob o filtro de Steve Jobs. Use quando o usuário pedir para "auditar essa tela", "analisar esse design", "ver fricção", "como Jobs avaliaria", "essa tela tá ok", "intuitividade", "auditoria de UX", ou estiver prestes a mergear feature visual. Aceita screenshot, descrição textual, rota/URL ou caminho de arquivo de componente. Retorna análise concreta com prioridades 🔴🟡🟢 e sugestões acionáveis aterradas em elemento visível — nunca filosofia. NÃO confundir com revisão de código (bugs/qualidade) — foco é UX, fluxo e fricção.