Você abriu o settings.json5 (um arquivo de configuração — como uma lista de instruções que o OpenClaw lê), mudou um campo, salvou, e o agente parou de responder. Ou pior: começou a responder errado. Aí você reverteu, mexeu de novo, quebrou de novo. Duas horas perdidas.
O problema não foi o arquivo. Foi a abordagem. Editar config diretamente é microgerenciar uma ferramenta que não precisa ser microgerenciada.
| Abordagem | Exemplo | Risco |
|---|---|---|
| Comando direto | ”Edita o campo X no config” | Alto — quebra silenciosa, sem validação |
| Reverse prompt | ”Quero que o briefing chegue 1h mais cedo, como resolver?” | Baixo — agente valida antes de alterar |
Gerente vs. microgerente
Existe uma diferença prática entre dois estilos de delegação.
O gerente diz “preciso do relatório até sexta, com os números de conversão por canal”. O microgerente diz “abre o Excel, vai na aba 3, seleciona B12 até B45, formata como moeda, copia para o slide 7, ajusta a fonte para 11pt”.
O segundo gasta mais energia, produz instruções que ficam obsoletas quando a ferramenta muda de versão, e remove a capacidade do colaborador de usar seu próprio julgamento para resolver problemas no caminho.
Com o OpenClaw, o padrão de microgerenciamento é editar arquivos de configuração diretamente. O padrão de gerenciamento é descrever o objetivo e deixar o agente decidir como chegar lá — com a opção de revisar antes de executar.
Reverse prompting é esse segundo modo. Você descreve o que quer, não como fazer.
3 exemplos lado a lado
Mudar o horário do briefing
Antes — comando direto:
“No arquivo
~/.openclaw/cron.json5, muda o campoeverydo jobbriefing-matinalde0 6 * * *para0 7 * * *.”
Isso parece preciso, mas assume que você sabe exatamente qual campo controla o horário, que a sintaxe cron (do agendador de tarefas) está correta, e que não há outros jobs dependentes. Se um desses pressupostos estiver errado, o job quebra silenciosamente — sem erro, sem aviso.
Depois — reverse prompt:
“Quero que meu briefing matinal chegue 1 hora mais tarde do que está agora. O que precisa mudar e existe algum risco de conflito com outros jobs?”
O agente lê o arquivo atual, identifica o job correto, confirma a mudança antes de fazer, e verifica se outros jobs dependem desse horário. Você aprova, ele executa.
Adicionar um novo canal de notificação
Antes — comando direto:
“Adiciona no
settings.json5um bloco de configuração para Discord com webhook (um aviso automático que um sistema manda para outro quando algo acontece)https://discord.com/api/webhooks/...”
O problema aqui é diferente. Você não sabe se o schema do settings.json5 aceita Discord da forma que você imaginou, se há campos obrigatórios além do webhook, ou se existe alguma validação que vai rejeitar o bloco.
Depois — reverse prompt:
“Quero receber alertas de erro também no Discord, além do Telegram que já funciona. Como configurar isso sem afetar o canal atual?”
O agente busca a documentação do schema interno, monta a configuração correta, mostra o diff (a diferença entre o arquivo antigo e o novo) antes de aplicar, e confirma que o Telegram continua funcionando.
Debugar por que o heartbeat parou
Antes — comando direto:
“Verifica o arquivo de logs em
~/.openclaw/logs/heartbeat.loge me diz o que tem de errado.”
Isso funciona, mas é uma pesquisa manual. Você está apontando para um arquivo específico baseado numa hipótese — e se o problema estiver em outro lugar?
Depois — reverse prompt:
“O heartbeat (verificação automática periódica) parou de chegar ontem às 14h. O que pode ter acontecido? Faz uma análise e me apresenta as hipóteses mais prováveis antes de qualquer mudança.”
O agente verifica logs, histórico de configuração, status de rede, e apresenta um diagnóstico com as hipóteses em ordem de probabilidade. Você escolhe por onde começar.
Quando o agente erra repetidamente: crie uma Skill
Se você percebe que o agente faz o mesmo erro em situações parecidas, o reverse prompt para isso é:
“Pausa. Analisa o que deu errado nessa interação específica. Depois cria uma Skill para que esse problema não aconteça de novo.”
Skills (habilidades configuradas) são a “memória muscular” do agente — regras que ele carrega automaticamente em situações que batem com o padrão. Se o agente sempre confunde o formato de data que você usa, uma Skill pode fixar isso. Se ele sempre adiciona introduções que você não quer nos relatórios, uma Skill remove esse padrão.
A Skill fica em ~/.openclaw/skills/ como um arquivo markdown. Você pode ler, editar, versionar. Não é uma caixa preta.
O momento certo de criar uma Skill: quando você se pega corrigindo o mesmo comportamento pela terceira vez. Da primeira à segunda vez é um acidente. Da segunda à terceira é um padrão que vale fixar.
Troubleshooting
O agente fez algo que eu não pedi
O reverse prompt estava aberto demais. “Melhora minha configuração” é um convite para o agente tomar decisões que você não aprovou. Seja específico sobre o objetivo sem ser específico sobre a implementação. “Quero que o briefing seja mais curto — máximo 100 palavras” é melhor que “melhora meu briefing”.
O agente demorou muito para responder
Prompt muito aberto gera análise excessiva. Adicione uma restrição de escopo: “analisa apenas o arquivo de Cron, não outros configs” ou “apresenta no máximo 3 hipóteses”. Limites de escopo aceleram a resposta sem perder qualidade.
Ele criou uma Skill ruim que continua causando problemas
Não apague a Skill imediatamente. Primeiro, leia o arquivo em ~/.openclaw/skills/ e entenda o que ela está fazendo. Depois peça ao agente: “A Skill X está causando o comportamento Y. Revisa ela para corrigir isso sem remover o que ela faz bem.” Iteração é mais eficiente que exclusão.
Quero confirmar tudo antes de qualquer mudança de config
Adicione “não faça nenhuma alteração sem minha confirmação explícita” no final de qualquer prompt que envolva configuração. O agente vai apresentar o plano e aguardar. Você pode tornar isso padrão criando uma Skill de aprovação obrigatória para mudanças de config.