


Crie um conjunto de habilidades de pesquisa de SEO que funcione em várias ferramentas de agentes de IA
Para que as mesmas habilidades de pesquisa de SEO funcionem em várias ferramentas de agentes de IA. Mantém uma única cópia principal, envia cada pergunta à análise certa, não guarda chaves de API em arquivos e testa em cada ferramenta.
Para usar estas regras de IA
## Escreva cada habilidade uma só vez com recursos que todas as ferramentas entendem
Crie cada habilidade de pesquisa em uma fonte canônica e neutra em relação à plataforma. Limite o contrato central aos recursos que todos os ambientes de agentes pretendidos possam interpretar.
Exija que cada definição de habilidade forneça:
- um nome estável e uma descrição clara;
- declarações opcionais de modelo e ferramentas somente quando o host oferecer suporte;
- orientações operacionais completas no corpo;
- entradas, resultados, restrições e condições de falha explícitos.
Trate os controles específicos de plataforma como extensões opcionais. Um verificador de compatibilidade deve alertar quando um host puder ignorar uma extensão sem precisar rejeitar uma habilidade que, de outro modo, seja portátil.
Edite a fonte canônica, não as cópias geradas para plataformas. Valide todas as definições de habilidades antes do empacotamento ou da distribuição, para que metadados ausentes e sintaxe incompatível falhem logo no início.
## Descubra onde cada ferramenta de agentes de IA procura instruções e habilidades
Mapeie como cada ambiente de destino descobre as instruções do projeto e as habilidades reutilizáveis. Os padrões comuns incluem arquivos de instruções na raiz, diretórios dedicados a regras, pastas de habilidades nativas, despachantes gerados e alternativas baseadas em documentação.
Registre para cada host:
- qual arquivo é lido automaticamente no início da sessão;
- onde as habilidades reutilizáveis devem ser copiadas, vinculadas ou instaladas;
- se a ativação é automática ou exige um comando explícito;
- como a delegação incompatível recorre à execução no próprio contexto;
- qual documentação do projeto funciona como alternativa final.
Não presuma que uma única disposição de instalação funcione em todos os lugares. Preserve uma única fonte semântica enquanto adapta a descoberta, a ativação e o empacotamento ao comportamento verificado do host.
## Descreva os passos como ações simples e converta para os nomes de cada ferramenta
Escreva os procedimentos em termos de operações neutras, como ler, gravar, editar, executar comandos, listar arquivos, pesquisar texto e obter conteúdo da Web.
Mantenha um mapa de compatibilidade verificado entre essas operações e os nomes das ferramentas de cada host. Deixe que os adaptadores convertam os nomes alternativos quando o host oferecer mapeamento automático. Quando um recurso não estiver disponível, defina uma alternativa documentada em vez de omitir a etapa silenciosamente.
Mantenha a conversão de ferramentas separada da lógica de pesquisa. Um procedimento de análise de página deve informar que precisa de uma obtenção protegida e de um analisador de HTML, sem depender dos rótulos de ferramentas de um fornecedor.
Revise os mapeamentos sempre que um host alterar sua interface de ferramentas. Não alegue compatibilidade apenas pela semelhança dos nomes; execute a operação mapeada.
## Deixe uma pequena habilidade principal escolher qual habilidade de pesquisa carregar
Use um pequeno orquestrador para classificar a solicitação e carregar somente o recurso pertinente. Mantenha a lógica detalhada de análise em módulos específicos, não em um único arquivo de instruções muito grande.
Separe o sistema em:
- uma habilidade de roteamento que selecione o fluxo de trabalho;
- habilidades de pesquisa específicas com critérios completos de análise;
- agentes especialistas opcionais para trabalho independente ou paralelo;
- scripts locais para execução determinística;
- modelos de esquema para metadados estruturados de busca;
- adaptadores para empacotamento específico do host;
- extensões para fornecedores opcionais e recursos de alto custo.
Mantenha as extensões fora do caminho central de dependências. A ausência de uma extensão deve reduzir a cobertura opcional sem prejudicar a pesquisa básica.
## Escolha a análise de SEO mais específica para cada pergunta
Selecione o recurso de menor escopo que responda à pergunta da pesquisa:
- use uma auditoria completa do site para descoberta ampla e priorização;
- use a análise de uma única página para examinar detalhadamente uma URL;
- use a análise técnica para rastreabilidade, indexação, desempenho e infraestrutura relacionada;
- use a análise de conteúdo para sinais de qualidade, confiança, especialização e experiência;
- use a análise de dados estruturados para detecção, validação e geração;
- use a análise do mapa do site para cobertura e geração de XML;
- use a análise de imagens para metadados na página, visibilidade nos resultados da busca e otimização de arquivos;
- use a análise de busca com IA para visibilidade generativa e otimização para mecanismos de respostas.
Amplie para uma auditoria mais abrangente somente quando as descobertas atravessarem vários limites de recursos. Preserve a URL original, a fonte das evidências, o horário da observação e a incerteza de cada afirmação externa.
## Separe o planejamento de SEO e acompanhe as mudanças a partir de um ponto inicial
Forneça fluxos de trabalho distintos para planejamento estratégico, agrupamento semântico de palavras-chave, análise da experiência de busca e arquitetura de conteúdo. Não combine essas tarefas de planejamento com diagnósticos técnicos.
Mantenha explícito o estado do monitoramento:
1. capture uma referência estável;
2. compare uma observação posterior com essa referência;
3. preserve o histórico para que mudanças recorrentes possam ser diferenciadas de ruídos pontuais.
Use módulos especializados para comércio, páginas de destino programáticas, páginas de comparação com concorrentes, busca local, visibilidade em mapas, segmentação internacional por idioma, dados próprios de busca, experiência da página e análise de links de entrada.
Trate fornecedores externos de dados, rastreamento em larga escala e geração de recursos como extensões opcionais. Identifique os requisitos do fornecedor, as credenciais, os custos e os limites de cobertura antes de acioná-los.
## Confira as URLs antes de buscá-las e não coloque chaves de API nas habilidades
Use scripts locais para trabalhos determinísticos, como obtenção protegida de páginas, análise de HTML, verificações de desempenho, captura de referências e exportação estruturada.
Todo auxiliar que acesse a rede deve validar a URL de destino antes de fazer uma solicitação para reduzir o risco de falsificação de solicitações do lado do servidor. Preserve a verificação de certificados; investigue as falhas de certificado em vez de desativar a segurança do transporte.
Mantenha as credenciais de API em um local de configuração do usuário ou em um ambiente injetado, nunca nas habilidades canônicas, nos resultados de exemplo nem nos pacotes gerados. Pare com um resultado claro de credenciais ausentes em vez de inventar valores.
Execute os auxiliares pelo ambiente de linguagem e pelo gerenciador de dependências configurados. Quando um host na nuvem não expuser esse ambiente em `PATH`, use o caminho absoluto verificado do executável.
Retorne resultados legíveis por máquina quando outro módulo consumir o resultado. Preserve caminhos absolutos para capturas de tela ou outros arquivos gravados em diretórios temporários.
## Teste as habilidades em cada ferramenta de agentes de IA antes de compartilhá-las
Execute uma análise de portabilidade em cada habilidade canônica antes do empacotamento. Confirme os metadados obrigatórios, a estrutura válida e os recursos conhecidos específicos de cada host.
Teste em cada ambiente compatível:
- a descoberta das instruções na raiz;
- a instalação ou vinculação de habilidades;
- os caminhos de ativação explícita e automática;
- a conversão de nomes de ferramentas;
- a alternativa no próprio contexto quando agentes delegados não estiverem disponíveis;
- a execução de auxiliares locais;
- o roteamento gerado e as alternativas baseadas em documentação.
Os alertas devem identificar o recurso, o host afetado e a degradação esperada. Um campo opcional ignorado pode continuar compatível; uma instrução obrigatória ausente ou uma operação central indisponível não pode.
## Investigue erros próprios de cada ferramenta sem desligar as proteções
Trate as falhas específicas do host como evidências do ambiente, não como permissão para enfraquecer as proteções.
- Investigue falhas da cadeia de certificados ou de resolução de nomes antes de alterar o código.
- Use um executável verificado do ambiente virtual quando o caminho de comando padrão não tiver as dependências.
- Verifique os diretórios temporários documentados quando as capturas de tela ou os relatórios não estiverem no diretório de trabalho.
- Use caminhos absolutos quando os artefatos atravessarem limites de processos ou contêineres.
- Substitua integrações remotas indisponíveis por auxiliares locais documentados somente quando eles fornecerem evidências equivalentes.
Registre se uma limitação afeta a descoberta, a execução, a delegação, a rede ou a localização dos artefatos. Mantenha a solução alternativa no adaptador ou na nota operacional, em vez de contaminar a lógica de pesquisa canônica.
## Conclua as mudanças testando em ferramentas reais e atualizando a documentação
Antes de declarar concluída uma alteração de pesquisa multiplataforma:
- revise a habilidade canônica e todos os adaptadores afetados;
- recompile o roteamento e os pacotes gerados;
- execute a análise de portabilidade e os testes pertinentes dos auxiliares;
- teste hosts representativos em vez de confiar na inspeção da sintaxe;
- atualize o catálogo de recursos, as orientações de instalação e as notas de arquitetura;
- confirme que as extensões opcionais continuam isoladas;
- revise os resultados para detectar credenciais, afirmações sem fundamento e evidências ausentes.
Informe o recurso alterado, os hosts verificados, as avaliações aprovadas, os alertas observados, as alternativas usadas e as validações que não puderam ser executadas. Não alegue equivalência total quando um host ignorar um comportamento obrigatório ou somente um ambiente tiver sido testado.
