Discovery de org com IA: como transformar prompt solto em skill reutilizável
Um framework de cinco dimensões para você parar de reinventar a análise de objetos custom e automação toda vez que entra num org novo
Prompt bem escrito resolve uma vez. Skill bem escrita resolve sempre. Veja como estruturar análise de objetos custom e automação com um framework de cinco dimensões que produz resultado consistente, auditável e reutilizável em qualquer discovery de org Salesforce.
Todo arquiteto que já entrou num org com dez anos de histórico conhece o problema: ninguém sabe mais por que aquele objeto Legacy_Contact__c existe, quem ainda usa o Contact2__c, ou por que existem três flows e um trigger competindo pelo mesmo campo. A resposta clássica é gastar dias rodando query manual, lendo Apex linha por linha e perguntando pro time "quem mexeu nisso por último". IA acelera essa etapa, mas só se você parar de tratar prompt como conversa avulsa e começar a tratar como skill.
A diferença é conceitual e prática. Prompt é uma pergunta pontual que você faz e descarta. Skill é uma instrução estruturada e versionada, que você roda hoje, roda daqui a três meses num org diferente, e continua produzindo o mesmo tipo de análise, no mesmo formato, com o mesmo rigor. Se você já perdeu tempo comparando dois relatórios de IA sobre o mesmo assunto e percebeu que vieram em formatos completamente diferentes, o problema não é o modelo. É a ausência de estrutura na instrução.
As cinco dimensões que sustentam uma skill boa
Para qualquer skill de discovery funcionar de forma consistente, cinco elementos precisam estar explícitos, não implícitos na cabeça de quem escreveu o prompt:
- Scope: o que a IA deve analisar e, principalmente, o que ela deve ignorar. Sem isso, o modelo tende a variar o recorte a cada execução.
- Question: a pergunta específica que orienta a análise. "Analise a automação" é vago. "Identifique objetos com três ou mais tipos de automação ativa" é acionável.
- Output format: tabela, lista priorizada, sumário executivo. Definir o formato antecipadamente é o que permite comparar resultados entre sessões de discovery diferentes.
- Constraints: regras que a IA precisa respeitar, como não tocar em managed packages, não assumir informação que não está na metadata, ou considerar políticas internas da organização.
- Structure: dividir a skill em fases sequenciais, cada uma consumindo o output da anterior. Isso evita estourar a janela de contexto e permite reexecutar uma fase isolada quando o agente falha ou dá timeout, sem precisar rodar tudo de novo.
Esse último ponto é o que separa uma skill profissional de um prompt genérico. Fase 1 gera output estruturado, fase 2 consome esse output como input, fase 3 aprofunda em cima do que sobrou. Cada fase é independente o suficiente para ser auditada e reexecutada sozinha.
Aplicando o framework em objetos custom
Para mapear a saúde de objetos custom num org maduro, a estrutura sugerida é de três fases, pensada para orgs com histórico de objetos duplicados ou abandonados.
Fase 1 faz o levantamento geral do schema: contagem total de objetos custom, objetos com um único record type, e nomes que sugerem sobreposição funcional com objetos padrão (Contact2__c, Legacy_Contact__c e afins). Cada objeto sinalizado recebe um score de risco alto ou médio antes de seguir para a próxima fase.
Fase 2 pega só os objetos de risco alto e médio da fase anterior e roda uma avaliação individual: volume de registros, frequência de criação, quantidade de campos (incluindo os obsoletos), complexidade de validation rules, número de triggers, flows ativos e profundidade de fórmulas cross-object. Aqui entra um sinal clássico de dívida técnica: campos com sufixo Cache, Denorm, Copy ou From_Parent, e fórmulas com mais de três níveis de travessia. Isso é praticamente uma assinatura de gambiarra arquitetural acumulada ao longo dos anos.
Fase 3 mapeia o raio de dependência de cada objeto sinalizado: classes Apex que referenciam o objeto, relacionamentos de lookup e master-detail, volume e frequência de execução de reports, e pontos de integração de entrada e saída.
Um detalhe que faz diferença prática: managed packages entram na contagem total, mas ficam fora das recomendações de remediação. Você não vai sugerir refatorar um objeto do CPQ ou do Field Service que não pode tocar. Isso evita que o relatório final vire uma lista de problemas que ninguém pode resolver.
Aplicando o framework em automação
Falha de automação quase sempre aparece em runtime, não em design time. Um campo alterado de forma aparentemente inofensiva pode quebrar uma validation rule, disparar um loop recursivo ou fazer um record-triggered flow reexecutar triggers de um jeito que ninguém previu. A skill de automação existe justamente para antecipar esse tipo de risco antes que ele vire incidente em produção.
A estrutura aqui tem quatro fases:
Fase 1 consulta via Tooling API todos os tipos de automação ativa por objeto: before-save flows, record-triggered flows (com tipo e ordem de disparo), scheduled flows, autolaunched flows, triggers Apex (incluindo se são bulk-safe e em qual contexto de evento rodam), Process Builder e workflow rules. Validation rules entram numa consulta separada via SOQL contra o objeto ValidationRule. Qualquer objeto com três ou mais tipos de automação ativa, triggers com contexto de evento sobreposto, ou Process Builder convivendo com flow é sinalizado. Triggers não bulk-safe (UsageIsBulk = false, SOQL ou DML dentro de loop) também entram na lista de flags.
Fase 2 pega os objetos sinalizados e mapeia contra a ordem de salvamento do Salesforce, identificando qual automação dispara em qual momento do save order.
Um ponto que a documentação original destaca e que eu reforço por experiência: em org grande, com múltiplos times de desenvolvimento trabalhando sem handler framework compartilhado, é comum encontrar automação empilhada sem dono claro. Isso muda como você lê o resultado da Fase 1. Org pequeno, você provavelmente roda tudo numa passada só. Org grande, vale filtrar por processo de negócio ou ciclo de release antes de avançar, senão o output da Fase 2 vira ruído.
Script substitui prompt quando a tarefa é determinística
Nem toda etapa de discovery precisa de conversa com a IA. Para tarefa repetitiva e determinística, como iterar sobre lista de objetos, extrair metadata de campo ou sinalizar inconsistência de nomenclatura, um script roda mais rápido e não consome token nenhum. Se o agente já gerou uma query SOQL ou lógica de extração de metadata durante uma passada de discovery, guarde esse script junto da skill e referencie ele nas instruções. Toda vez que a skill rodar, o script executa de forma idêntica, dando uma base consistente para o resto da análise.
Discovery malfeito custa caro de um jeito silencioso: retrabalho descoberto só depois do deploy, requisito que ninguém levantou porque a análise inicial foi rasa, objeto legado que continua vivo porque ninguém teve coragem de mapear as dependências dele. Skills bem escritas resolvem o problema de escala que prompt avulso não resolve: você consegue repetir a mesma análise em orgs diferentes, em momentos diferentes, com o mesmo padrão de qualidade, e ainda auditar cada fase separadamente.
Este é um conteúdo técnico e estrutural, não uma novidade de produto. O valor está na metodologia de construção de skills de IA aplicadas a discovery arquitetural, algo que vale tanto para quem usa Agentforce quanto para quem monta pipelines próprios com outros modelos.
Comece pequeno: pegue um domínio só, objetos custom ou automação, e escreva a skill seguindo as cinco dimensões antes de rodar qualquer coisa. Documente scope, question, output format, constraints e structure num arquivo de skill versionado, não numa conversa que se perde no histórico do chat. Rode a Fase 1 isolada primeiro, valide o output, só depois libere a IA para consumir esse resultado na fase seguinte. Isso evita perder trabalho quando o agente falha no meio de uma execução longa.
Se seu org tem menos de cinquenta objetos custom, pode rodar as duas primeiras fases da análise de objetos juntas. Acima disso, mantenha a separação de fases, porque o volume de objetos sinalizados na Fase 1 tende a estourar o que a Fase 2 consegue processar num único run.
O erro mais comum é deixar a IA decidir o formato de output sozinha. Isso gera relatórios inconsistentes entre execuções e torna impossível comparar discovery de sessões diferentes. Defina o formato na instrução, sempre, mesmo que pareça redundante.
Outro cuidado é com managed packages: CPQ, Billing e Field Service podem responder por dezenas de triggers no org, e você não vai conseguir remediar nada ali. Inclua nos totais para ter visão completa do ambiente, mas separe claramente das recomendações de ação, senão o relatório final mistura problema real com ruído que ninguém pode resolver.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.