Modelos de Automação

Modelos prontos para copiar e colar, cobrindo padrões comuns de automação. Cada modelo usa o agendador cron embutido do Hermes para gatilhos por tempo e a plataforma de webhooks para gatilhos por evento.

Todos os modelos funcionam com qualquer modelo de linguagem — nada fica preso a um único provedor.

Para modelos parametrizados, com formulários no lugar da sintaxe de cron, veja o Catálogo de Modelos de Automação.

Três tipos de gatilho

Gatilho	Como funciona	Ferramenta
Agendamento	Roda numa cadência (a cada hora, toda noite, toda semana)	Ferramenta cronjob ou comando de barra /cron
Evento do GitHub	Dispara em abertura de PR, push, issues, resultados de CI	Plataforma de webhooks (hermes webhook subscribe)
Chamada de API	Um serviço externo envia um POST com JSON para o seu endpoint	Plataforma de webhooks (rotas no config.yaml ou hermes webhook subscribe)

Os três entregam o resultado no Telegram, Discord, Slack, SMS, e-mail, comentários do GitHub ou arquivos locais.

---

Fluxo de desenvolvimento

Triagem noturna do backlog

Rotule, priorize e resuma as issues novas toda noite. Entrega um resumo no canal do seu time.

Gatilho: agendamento (toda noite)

hermes cron create "0 2 * * *" \
  "Você é um gerente de projeto fazendo a triagem do repositório NousResearch/hermes-agent no GitHub.

1. Rode: gh issue list --repo NousResearch/hermes-agent --state open --json number,title,labels,author,createdAt --limit 30
2. Identifique as issues abertas nas últimas 24 horas
3. Para cada issue nova:
   - Sugira um rótulo de prioridade (P0-critical, P1-high, P2-medium, P3-low)
   - Sugira um rótulo de categoria (bug, feature, docs, security)
   - Escreva uma nota de triagem de uma linha
4. Resuma: total de issues abertas, novas hoje, distribuição por prioridade

Formate como um resumo limpo. Se não houver issues novas, responda com [SILENT]." \
  --name "Triagem noturna do backlog" \
  --deliver telegram

Revisão automática de código em PRs

Revise cada pull request assim que ele for aberto. Publica o comentário de revisão direto no PR.

Gatilho: webhook do GitHub

Opção A — assinatura dinâmica (CLI):

hermes webhook subscribe github-pr-review \
  --events "pull_request" \
  --prompt "Revise este pull request:
Repositório: {repository.full_name}
PR #{pull_request.number}: {pull_request.title}
Autor: {pull_request.user.login}
Ação: {action}
URL do diff: {pull_request.diff_url}

Baixe o diff com: curl -sL {pull_request.diff_url}

Revise procurando por:
- Problemas de segurança (injeção, bypass de autenticação, segredos no código)
- Questões de desempenho (consultas N+1, laços sem limite, vazamentos de memória)
- Qualidade de código (nomes, duplicação, tratamento de erro)
- Testes faltando para o comportamento novo

Publique uma revisão concisa. Se o PR for uma mudança trivial de docs ou de typo, diga isso em poucas palavras." \
  --skills github-code-review \
  --deliver github_comment

Opção B — rota estática (config.yaml):

platforms:
  webhook:
    enabled: true
    extra:
      port: 8644
      secret: "seu-segredo-global"
      routes:
        github-pr-review:
          events: ["pull_request"]
          secret: "segredo-do-webhook-do-github"
          prompt: |
            Revise o PR #{pull_request.number}: {pull_request.title}
            Repositório: {repository.full_name}
            Autor: {pull_request.user.login}
            URL do diff: {pull_request.diff_url}
            Revise segurança, desempenho e qualidade de código.
          skills: ["github-code-review"]
          deliver: "github_comment"
          deliver_extra:
            repo: "{repository.full_name}"
            pr_number: "{pull_request.number}"

Depois, no GitHub: Settings → Webhooks → Add webhook → Payload URL: http://seu-servidor:8644/webhooks/github-pr-review, Content type: application/json, Secret: segredo-do-webhook-do-github, Events: Pull requests.

Detecção de documentação defasada

Varredura semanal dos PRs mesclados para achar mudanças de API que precisam de atualização na documentação.

Gatilho: agendamento (semanal)

hermes cron create "0 9 * * 1" \
  "Varra o repositório NousResearch/hermes-agent atrás de documentação defasada.

1. Rode: gh pr list --repo NousResearch/hermes-agent --state merged --json number,title,files,mergedAt --limit 30
2. Filtre os PRs mesclados nos últimos 7 dias
3. Para cada PR mesclado, verifique se ele alterou:
   - Schemas de ferramentas (tools/*.py) — pode exigir atualizar docs/reference/tools-reference.md
   - Comandos da CLI (hermes_cli/commands.py, hermes_cli/main.py) — pode exigir atualizar docs/reference/cli-commands.md
   - Opções de configuração (hermes_cli/config.py) — pode exigir atualizar docs/user-guide/configuration.md
   - Variáveis de ambiente — pode exigir atualizar docs/reference/environment-variables.md
4. Cruze as informações: para cada mudança de código, verifique se a página de documentação correspondente também foi atualizada no mesmo PR

Relate qualquer lacuna em que o código mudou e a documentação não. Se estiver tudo em dia, responda com [SILENT]." \
  --name "Detecção de docs defasada" \
  --deliver telegram

Auditoria de segurança das dependências

Varredura diária atrás de vulnerabilidades conhecidas nas dependências do projeto.

Gatilho: agendamento (diário)

hermes cron create "0 6 * * *" \
  "Faça uma auditoria de segurança das dependências do projeto hermes-agent.

1. cd ~/.hermes/hermes-agent && source .venv/bin/activate
2. Rode: pip audit --format json 2>/dev/null || pip audit 2>&1
3. Rode: npm audit --json 2>/dev/null (no diretório website/, se ele existir)
4. Procure CVEs com pontuação CVSS >= 7.0

Se encontrar vulnerabilidades:
- Liste cada uma com nome do pacote, versão, ID da CVE e severidade
- Verifique se há atualização disponível
- Anote se é dependência direta ou transitiva

Se não houver vulnerabilidades, responda com [SILENT]." \
  --name "Auditoria de dependências" \
  --deliver telegram

---

DevOps e monitoramento

Verificação de deploy

Dispare testes de fumaça depois de cada deploy. Seu pipeline de CI/CD envia um POST para o webhook quando o deploy termina.

Gatilho: chamada de API (webhook)

hermes webhook subscribe deploy-verify \
  --events "deployment" \
  --prompt "Um deploy acabou de terminar:
Serviço: {service}
Ambiente: {environment}
Versão: {version}
Feito por: {deployer}

Rode estas verificações:
1. Confira se o serviço responde: curl -s -o /dev/null -w '%{http_code}' {health_url}
2. Procure erros nos logs recentes: veja no payload do deploy se há indícios de erro
3. Confirme se a versão bate: curl -s {health_url}/version

Relate: situação do deploy (saudável/degradado/falhou), tempo de resposta e erros encontrados.
Se estiver saudável, seja breve. Se estiver degradado ou tiver falhado, dê um diagnóstico detalhado." \
  --deliver telegram

Seu pipeline de CI/CD dispara assim:

curl -X POST http://seu-servidor:8644/webhooks/deploy-verify \
  -H "Content-Type: application/json" \
  -H "X-Hub-Signature-256: sha256=$(echo -n '{"service":"api","environment":"prod","version":"2.1.0","deployer":"ci","health_url":"https://api.example.com/health"}' | openssl dgst -sha256 -hmac 'seu-segredo' | cut -d' ' -f2)" \
  -d '{"service":"api","environment":"prod","version":"2.1.0","deployer":"ci","health_url":"https://api.example.com/health"}'

Triagem de alertas

Correlacione alertas de monitoramento com mudanças recentes para rascunhar uma resposta. Funciona com Datadog, PagerDuty, Grafana ou qualquer sistema de alerta que consiga enviar JSON por POST.

Gatilho: chamada de API (webhook)

hermes webhook subscribe alert-triage \
  --prompt "Alerta de monitoramento recebido:
Alerta: {alert.name}
Severidade: {alert.severity}
Serviço: {alert.service}
Mensagem: {alert.message}
Horário: {alert.timestamp}

Investigue:
1. Procure na web por problemas conhecidos com esse padrão de erro
2. Verifique se isso tem relação com algum deploy ou mudança de configuração recente
3. Rascunhe um resumo de triagem com:
   - Causa raiz provável
   - Primeiros passos sugeridos de resposta
   - Recomendação de escalonamento (P1-P4)

Seja conciso. Isso vai para o canal do plantão." \
  --deliver slack

Monitor de disponibilidade

Confira os endpoints a cada 30 minutos. Só avisa quando algo estiver fora do ar.

Gatilho: agendamento (a cada 30 min)

~/.hermes/scripts/check-uptime.py

import urllib.request, json, time

ENDPOINTS = [
    {"name": "API", "url": "https://api.example.com/health"},
    {"name": "Web", "url": "https://www.example.com"},
    {"name": "Docs", "url": "https://docs.example.com"},
]

results = []
for ep in ENDPOINTS:
    try:
        start = time.time()
        req = urllib.request.Request(ep["url"], headers={"User-Agent": "Hermes-Monitor/1.0"})
        resp = urllib.request.urlopen(req, timeout=10)
        elapsed = round((time.time() - start) * 1000)
        results.append({"name": ep["name"], "status": resp.getcode(), "ms": elapsed})
    except Exception as e:
        results.append({"name": ep["name"], "status": "DOWN", "error": str(e)})

down = [r for r in results if r.get("status") == "DOWN" or (isinstance(r.get("status"), int) and r["status"] >= 500)]
if down:
    print("OUTAGE DETECTED")
    for r in down:
        print(f"  {r['name']}: {r.get('error', f'HTTP {r[\"status\"]}')} ")
    print(f"\nAll results: {json.dumps(results, indent=2)}")
else:
    print("NO_ISSUES")

hermes cron create "every 30m" \
  "Se o script reportar OUTAGE DETECTED, resuma quais serviços estão fora do ar e sugira causas prováveis. Se for NO_ISSUES, responda com [SILENT]." \
  --script ~/.hermes/scripts/check-uptime.py \
  --name "Monitor de disponibilidade" \
  --deliver telegram

---

Pesquisa e inteligência

Vigia de repositórios concorrentes

Acompanhe os repositórios dos concorrentes atrás de PRs, funcionalidades e decisões de arquitetura interessantes.

Gatilho: agendamento (diário)

hermes cron create "0 8 * * *" \
  "Vigie estes repositórios de agentes de IA atrás de atividade relevante nas últimas 24 horas:

Repositórios a conferir:
- anthropics/claude-code
- openai/codex
- All-Hands-AI/OpenHands
- Aider-AI/aider

Para cada repositório:
1. gh pr list --repo <repo> --state all --json number,title,author,createdAt,mergedAt --limit 15
2. gh issue list --repo <repo> --state open --json number,title,labels,createdAt --limit 10

Foque em:
- Funcionalidades novas em desenvolvimento
- Mudanças de arquitetura
- Padrões de integração dos quais dá para aprender
- Correções de segurança que talvez também nos afetem

Ignore atualizações rotineiras de dependência e ajustes de CI. Se não houver nada relevante, responda com [SILENT].
Se houver achados, organize por repositório com uma análise breve de cada item." \
  --skill competitive-pr-scout \
  --name "Vigia de concorrentes" \
  --deliver telegram

Resumo de notícias de IA

Retrospectiva semanal do que aconteceu em IA/ML.

Gatilho: agendamento (semanal)

hermes cron create "0 9 * * 1" \
  "Gere um resumo semanal de notícias de IA cobrindo os últimos 7 dias:

1. Procure na web por grandes anúncios de IA, lançamentos de modelos e avanços de pesquisa
2. Procure repositórios de ML em alta no GitHub
3. Consulte o arXiv atrás de artigos muito citados sobre modelos de linguagem e agentes

Estrutura:
## Manchetes (3-5 histórias principais)
## Artigos notáveis (2-3 artigos com resumo de uma frase)
## Código aberto (repositórios novos interessantes ou lançamentos importantes)
## Movimentos do mercado (investimentos, aquisições, lançamentos)

Deixe cada item em 1-2 frases. Inclua links. Total abaixo de 600 palavras." \
  --name "Resumo semanal de IA" \
  --deliver telegram

Resumo de artigos com anotações

Varredura diária do arXiv que salva os resumos no seu sistema de anotações.

Gatilho: agendamento (diário)

hermes cron create "0 8 * * *" \
  "Procure no arXiv os 3 artigos mais interessantes sobre 'language model reasoning' OU 'tool-use agents' publicados no último dia. Para cada artigo, crie uma nota no Obsidian com o título, os autores, um resumo do abstract, a contribuição principal e a possível relevância para o desenvolvimento do Hermes Agent." \
  --skill arxiv --skill obsidian \
  --name "Resumo de artigos" \
  --deliver local

---

Automações por eventos do GitHub

Rotulagem automática de issues

Rotule e responda automaticamente às issues novas.

Gatilho: webhook do GitHub

hermes webhook subscribe github-issues \
  --events "issues" \
  --prompt "Nova issue recebida no GitHub:
Repositório: {repository.full_name}
Issue #{issue.number}: {issue.title}
Autor: {issue.user.login}
Ação: {action}
Corpo: {issue.body}
Rótulos: {issue.labels}

Se for uma issue nova (action=opened):
1. Leia o título e o corpo da issue com atenção
2. Sugira rótulos apropriados (bug, feature, docs, security, question)
3. Se for um relato de bug, veja se dá para identificar pela descrição qual componente é afetado
4. Publique uma primeira resposta útil confirmando o recebimento

Se for uma mudança de rótulo ou de responsável, responda com [SILENT]." \
  --deliver github_comment

Análise de falhas de CI

Analise falhas de CI e publique o diagnóstico no PR.

Gatilho: webhook do GitHub

# rota no config.yaml
platforms:
  webhook:
    enabled: true
    extra:
      routes:
        ci-failure:
          events: ["check_run"]
          secret: "segredo-do-ci"
          prompt: |
            Uma verificação de CI falhou:
            Repositório: {repository.full_name}
            Verificação: {check_run.name}
            Situação: {check_run.conclusion}
            PR: #{check_run.pull_requests.0.number}
            URL dos detalhes: {check_run.details_url}

            Se a conclusão for "failure":
            1. Busque o log na URL de detalhes, se estiver acessível
            2. Identifique a causa provável da falha
            3. Sugira uma correção
            Se a conclusão for "success", responda com [SILENT].
          deliver: "github_comment"
          deliver_extra:
            repo: "{repository.full_name}"
            pr_number: "{check_run.pull_requests.0.number}"

Portar mudanças entre repositórios automaticamente

Quando um PR é mesclado num repositório, porte a mudança equivalente para outro automaticamente.

Gatilho: webhook do GitHub

hermes webhook subscribe auto-port \
  --events "pull_request" \
  --prompt "PR mesclado no repositório de origem:
Repositório: {repository.full_name}
PR #{pull_request.number}: {pull_request.title}
Autor: {pull_request.user.login}
Ação: {action}
Commit de merge: {pull_request.merge_commit_sha}

Se a ação for 'closed' e pull_request.merged for true:
1. Baixe o diff: curl -sL {pull_request.diff_url}
2. Analise o que mudou
3. Decida se essa mudança precisa ser portada para o equivalente no SDK Go
4. Se sim, crie um branch, aplique as mudanças equivalentes e abra um PR no repositório de destino
5. Cite o PR original na descrição do PR novo

Se a ação não for 'closed' ou o PR não tiver sido mesclado, responda com [SILENT]." \
  --skills github-pr-workflow \
  --deliver log

---

Operações de negócio

Monitoramento de pagamentos no Stripe

Acompanhe eventos de pagamento e receba resumos das falhas.

Gatilho: chamada de API (webhook)

hermes webhook subscribe stripe-payments \
  --events "payment_intent.succeeded,payment_intent.payment_failed,charge.dispute.created" \
  --prompt "Evento do Stripe recebido:
Tipo do evento: {type}
Valor: {data.object.amount} centavos ({data.object.currency})
Cliente: {data.object.customer}
Situação: {data.object.status}

Para payment_intent.payment_failed:
- Identifique o motivo da falha em {data.object.last_payment_error}
- Diga se é um problema temporário (tentar de novo) ou permanente (falar com o cliente)

Para charge.dispute.created:
- Marque como urgente
- Resuma os detalhes da contestação

Para payment_intent.succeeded:
- Apenas uma confirmação breve

Mantenha as respostas concisas para o canal de operações." \
  --deliver slack

Resumo diário de receita

Compile as métricas principais do negócio toda manhã.

Gatilho: agendamento (diário)

hermes cron create "0 8 * * *" \
  "Gere um resumo matinal das métricas do negócio.

Procure na web por:
1. Cotação atual de Bitcoin e Ethereum
2. Situação do S&P 500 (pré-mercado ou fechamento anterior)
3. Notícias importantes do setor de tecnologia/IA nas últimas 12 horas

Formate como um briefing matinal curto, no máximo 3-4 tópicos.
Entregue como uma mensagem limpa e fácil de ler." \
  --name "Briefing matinal" \
  --deliver telegram

---

Fluxos com várias skills

Pipeline de auditoria de segurança

Combine várias skills numa revisão de segurança semanal completa.

Gatilho: agendamento (semanal)

hermes cron create "0 3 * * 0" \
  "Faça uma auditoria de segurança completa do código do hermes-agent.

1. Procure vulnerabilidades nas dependências (pip audit, npm audit)
2. Vasculhe o código atrás de antipadrões comuns de segurança:
   - Segredos ou chaves de API fixos no código
   - Vetores de injeção de SQL (formatação de string em consultas)
   - Riscos de path traversal (entrada do usuário em caminhos de arquivo sem validação)
   - Desserialização insegura (pickle.loads, yaml.load sem SafeLoader)
3. Revise os commits recentes (últimos 7 dias) atrás de mudanças relevantes para segurança
4. Verifique se alguma variável de ambiente nova foi adicionada sem ser documentada

Escreva um relatório de segurança com os achados categorizados por severidade (Crítica, Alta, Média, Baixa).
Se não encontrar nada, informe que está tudo limpo." \
  --skill codebase-security-audit \
  --name "Auditoria semanal de segurança" \
  --deliver telegram

Pipeline de conteúdo

Pesquise, rascunhe e prepare conteúdo de forma agendada.

Gatilho: agendamento (semanal)

hermes cron create "0 10 * * 3" \
  "Pesquise e rascunhe o esqueleto de um post técnico sobre um tema em alta em agentes de IA.

1. Procure na web os temas de agentes de IA mais comentados nesta semana
2. Escolha o mais interessante entre os relevantes para agentes de IA de código aberto
3. Crie um esqueleto com:
   - Gancho/ângulo de introdução
   - 3-4 seções principais
   - Profundidade técnica adequada para pessoas desenvolvedoras
   - Conclusão com um aprendizado prático
4. Salve o esqueleto em ~/rascunhos/blog-$(date +%Y%m%d).md

Deixe o esqueleto em cerca de 300 palavras. Isso é um ponto de partida, não um post pronto." \
  --name "Esqueleto de post" \
  --deliver local

---

Referência rápida

Sintaxe de agendamento do cron

Expressão	Significado
every 30m	A cada 30 minutos
every 2h	A cada 2 horas
0 2 * * *	Todo dia às 2h
0 9 * * 1	Toda segunda-feira às 9h
0 9 * * 1-5	Dias úteis às 9h
0 3 * * 0	Todo domingo às 3h
0 */6 * * *	A cada 6 horas

Destinos de entrega

Destino	Opção	Observações
Mesma conversa	--deliver origin	Padrão — entrega onde a tarefa foi criada
Arquivo local	--deliver local	Salva a saída, sem notificação
Telegram	--deliver telegram	Canal padrão, ou telegram:CHAT_ID para um específico
Discord	--deliver discord	Canal padrão, ou discord:CHANNEL_ID
Slack	--deliver slack	Canal padrão
SMS	--deliver sms:+15551234567	Direto para o número de telefone
Tópico específico	--deliver telegram:-100123:456	Tópico de fórum do Telegram

Variáveis de template dos webhooks

Variável	Descrição
{pull_request.title}	Título do PR
{issue.number}	Número da issue
{repository.full_name}	owner/repo
{action}	Ação do evento (opened, closed etc.)
{__raw__}	Payload JSON completo (truncado em 4000 caracteres)
{sender.login}	Usuário do GitHub que disparou o evento

O padrão [SILENT]

Quando a resposta de uma tarefa cron contém [SILENT], a entrega é suprimida. Use isso para evitar excesso de notificação em execuções sem novidade:

Se nada de relevante aconteceu, responda com [SILENT].

Assim você só é notificado quando o agente tem algo a relatar.

---