⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato, IP, conta ou recurso alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo somente leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

WP Guard

[!WARNING] Uso Autorizado Apenas. Revise apenas código e ambientes WordPress que o usuário possui ou está explicitamente autorizado a avaliar. Mantenha as verificações não destrutivas e dentro do escopo aprovado.

Você está revisando código WordPress gerado ou alterado antes que ele seja enviado. Aplique as regras abaixo como um passe de segurança após a primeira passagem de implementação. Seja um revisor perspicaz, não pedante: sinalize o que cria vulnerabilidades, quebra traduções ou derrete servidores — ignore preferências cosméticas que as ferramentas WPCS já tratam.

Essas regras existem porque agentes de IA produzem código WordPress com falhas sistemáticas: echo bruto de dados de requisição, manipuladores AJAX sem verificação de nonce ou capacidade, SQL construído por interpolação de strings, inglês codificado em strings voltadas para o usuário, posts_per_page => -1 em sites com um milhão de posts e substituições manuais para APIs que o core já fornece. Cada um parece bom em uma demonstração e falha em produção.

Quando Usar

Use esta habilidade ao revisar código WordPress gerado ou alterado — plugins, temas e blocos — antes que ele seja enviado. Ative-a reativamente após um agente escrever, editar ou revisar código que toque nas APIs do WordPress: hooks, tipos de post personalizados, endpoints REST, consultas de banco de dados e integrações do editor de blocos.

Como Usar Esta Habilidade

Modo de passe de segurança (recomendado): após o código WordPress ter sido gerado ou editado, aplique as regras ao diff ou aos arquivos alvo, e então execute a auto-verificação antes da entrega. Corrija violações antes de mostrar ao usuário.

Modo ao vivo (explícito): quando o usuário invoca esta habilidade antes de escrever código WordPress, aplique as mesmas regras durante a escrita, e então execute a auto-verificação antes da entrega.

Modo de revisão (o usuário pede para você revisar, auditar ou avaliar código WordPress): percorra references/review-checklist.md contra os arquivos alvo e produza um relatório estruturado de descobertas. Não edite o código no modo de revisão a menos que solicitado.

Emparelhe esta habilidade com clean-code-guard quando ambos estiverem instalados: clean-code-guard é responsável pela qualidade genérica do código; wp-guard é responsável pela camada WordPress.

Adapte-se ao Projeto Primeiro

1. Leia as instruções do agente do projeto (CLAUDE.md, AGENTS.md), configuração phpcs.xml/WPCS e composer.json. As convenções do projeto prevalecem em caso de conflito.
2. Identifique o prefixo estabelecido (funções, opções, chaves de meta, handles) e as versões mínimas suportadas de WP/PHP. Combine ambos.
3. Detecte o contexto: APIs do WooCommerce em uso → aplique woo-guard juntamente com esta habilidade quando ela estiver instalada; caso contrário, aplique as regras de HPOS, CRUD e checkout do WooCommerce de sua documentação para desenvolvedores. Site multilíngue (WPML/Polylang/multisite) → regras de i18n são bloqueadoras, não consultivas.
4. Leia um arquivo vizinho antes de escrever. Espelhe seu tratamento de erros, estilo de registro de hooks e hábitos de escape — a menos que violem as regras de segurança abaixo, que são inegociáveis.

As Regras

Segurança — deve corrigir, sem exceções

1. Escape no final, escape tudo. Toda variável que cruza para a saída HTML passa pela função correta para o contexto: esc_html(), esc_attr(), esc_url(), ou wp_kses()/wp_kses_post() para conteúdo rico. Dados passados para JS inline passam por wp_json_encode() + wp_add_inline_script() — esc_js() é legado, apenas para strings entre aspas simples em atributos inline. O escape ocorre na saída, não no armazenamento. echo $anything; sem um wrapper esc_* falha na revisão.

…