📄 Baixando e abrindo o template soul.md
O soul.md é o arquivo de contexto pessoal que o Hermes lê toda vez que abre uma sessão. O local correto é ~/.hermes/soul.md — não ~/Documents, não dentro do projeto. Fora desse caminho, o Hermes não carrega.
O que é
Um arquivo Markdown único em ~/.hermes/soul.md com seis seções fixas: Identity, Mission, Business, Voice, Rhythm e Memory. O Hermes faz parse dessas seções no boot e injeta como contexto persistente em todas as sessões.
⬇️ Baixando o template
$ mkdir -p ~/.hermes
$ curl -o ~/.hermes/soul.md https://hermes.automationsai.net/soul.template.md
$ $EDITOR ~/.hermes/soul.md
📝 Estrutura do template em branco
# soul.md — contexto pessoal do operador ## Identity name: location: role: channels: ## Mission Goal: Pillars: Not goals: ## Business revenue: costs: runway: metrics: ## Voice tone: forbidden: hard_nos: ## Rhythm deep_work_windows: creation_days: energy_curve: ## Memory decisions: people: tools:
💡 Por que esse caminho exato
O Hermes procura soul.md em um único lugar: ~/.hermes/. Diretório oculto, fora do projeto, fora do Drive sincronizado. Mantém o contexto privado, evita commits acidentais e funciona em qualquer projeto onde você invocar Hermes.
🔑 Conceitos-chave
Único caminho válido — qualquer outro local não é carregado pelo runtime
Identity, Mission, Business, Voice, Rhythm, Memory — ordem e nomes importam para o parser
Fora do projeto evita commit acidental e mantém o contexto pessoal privado
Hermes lê o arquivo a cada sessão — edição requer reload, não restart
🆔 Preenchendo Identity e Mission com seus dados reais
Identity responde quem você é em termos operacionais. Mission responde para onde você está indo em headline goal sem suavizações. Vagueza aqui contamina todo o resto do contexto.
O que é
Identity é o cartão de visita operacional: nome, fuso, papel, canais de contato. Mission é o objetivo de horizonte (12 meses) descrito como meta numérica, pilares mensuráveis e — crucial — uma lista explícita do que NÃO é objetivo, para o modelo recusar caminhos errados.
📝 Identity preenchido (exemplo real)
## Identity name: Nei Maldaner location: Caxias do Sul, BR (UTC-3) role: Founder + Operator @ AutomationsAI channels: hermes@automationsai.net, +55 54 ..., @neimaldaner
🎯 Mission preenchida (headline sem suavização)
## Mission 2026 Goal: 10x revenue via TRIAD + AutomationsAI platform Pillars: (1) course launches Q2, (2) consulting Q3, (3) SaaS Q4 Not goals: enterprise sales, agency model
✗ Mission suavizada (inútil)
- ✗"Crescer o negócio de forma sustentável"
- ✗"Lançar mais produtos em 2026"
- ✗"Explorar oportunidades de receita"
- ✗Sem lista de Not goals
✓ Mission headline (válida)
- ✓"10x revenue via TRIAD + AutomationsAI"
- ✓3 pilares datados (Q2, Q3, Q4)
- ✓Not goals explícito: enterprise, agency
- ✓Número mensurável (10x) — testável
🔑 Conceitos-chave
UTC-3 evita que o Hermes agende reuniões em horários errados
"10x revenue" é testável, "crescer" não — sem número, sem Mission
A lista do que NÃO fazer protege contra sugestões fora de escopo
Cada pilar com trimestre — transforma Mission em plano executável
💼 Documentando seu negócio — receita, custos, runway
Sem números reais, o Hermes sugere movimentos que ignoram sua realidade financeira. Runway é a restrição mais importante — toda sugestão estratégica precisa caber dentro dela.
O que é
Business é a seção de números do soul.md: MRR atual, custos fixos mensais, runway em meses e métricas-chave que você acompanha (CAC, LTV, churn). Esses números entram nas decisões do Hermes como restrições duras, não como contexto opcional.
💰 Business preenchido
## Business revenue: MRR R$ 28k (Apr/26), trending +12% MoM costs: R$ 11k/mo fixed (infra R$ 2.1k + team R$ 8.9k) runway: 9 months at current burn (cap: R$ 150k) metrics: - CAC: R$ 340 (course funnel) - LTV: R$ 1.9k (12-mo cohort) - churn: 4.2% monthly
⛔ Runway como restrição dura
Quando você pede ao Hermes "estratégia para próximos 6 meses", ele cruza com runway: 9 meses. Sugestões que exigem investimento upfront acima de 30% do cap são automaticamente flagueadas. Sem o número, ele assume runway infinito e propõe gastos que você não tem.
🔑 Conceitos-chave
Use o valor do último fechamento — números arredondados perdem a função
Hermes recusa sugestões que estouram o cap definido
Três métricas mínimas — sem elas, recomendações de growth são chutes
Business é a única seção que muda mensalmente — agende reload
🎤 Definindo sua voz e seus hard nos
Voice é o que protege seu posicionamento. Palavras proibidas e hard nos dizem ao Hermes o que nunca aparecer no output — independentemente do contexto da tarefa.
O que é
Voice define tom (formal/informal, técnico/acessível), uma lista de palavras proibidas (jargão que diluiu sua marca) e hard nos — compromissos operacionais que você nunca aceita, independente do quão tentadora seja a proposta.
🚫 Voice + Hard Nos preenchidos
## Voice tone: direto, técnico, sem suavizações; PT-BR primário forbidden: ["sinergia", "alavancar", "ecossistema", "jornada"] ## Hard Nos - Never commit to deadlines under 48h - Never email cold leads (warm intros only) - Never schedule meetings before 10am - Never discount published prices - Never accept retainer + scope creep combo
✗ Goal suavizado
- ✗"Tentar evitar reuniões cedo"
- ✗"Prazos curtos só se possível"
- ✗"Preferir warm intros"
- ✗Modelo continua negociando
✓ Hard No real
- ✓"Never schedule meetings before 10am"
- ✓"Never commit under 48h"
- ✓"Never email cold leads"
- ✓Modelo recusa imediatamente
🛡️ Por que "never" em vez de "preferir"
Modelos de linguagem negociam preferências. Não negociam "never". Use o verbo absoluto — é a única forma que sobrevive a uma proposta tentadora que o Hermes esteja avaliando.
🔑 Conceitos-chave
Lista de jargão diluído — protege voz da marca em qualquer output
Verbo absoluto não é negociável pelo modelo — preferência sim
Cada hard no é uma porta fechada — Hermes não negocia o que está bloqueado
Voice + hard nos juntos garantem coerência entre o que você diz e faz
⏰ Mapeando seu ritmo de trabalho
Rhythm diz ao Hermes quando você está disponível para qual tipo de trabalho. Sem isso, ele agenda reunião na sua janela de deep work e tarefa criativa quando sua energia está no chão.
O que é
Rhythm define três coisas: janelas de deep work (faixas horárias intocáveis), dias da semana reservados para criação (vs. reuniões/operação) e a curva de energia ao longo do dia. O Hermes usa isso para sugerir o horário certo para cada tipo de tarefa.
📅 Rhythm preenchido
## Rhythm deep_work_windows: - 10:00–13:00 (peak focus, no meetings) - 15:30–17:00 (writing, code) creation_days: Mon, Tue, Wed (no external meetings) meeting_days: Thu, Fri (batched, 14:00–17:00) energy_curve: morning: HIGH (creative/strategic) afternoon: MEDIUM (execution/admin) evening: LOW (no decisions after 19:00)
Defina deep work windows com horário fechado
Faixas específicas (10:00–13:00), não conceitos ("manhã"). Hermes precisa de timestamps para comparar com pedidos de agendamento.
Separe creation days de meeting days
Bloqueia segunda a quarta para output, agrupa reuniões em quinta-sexta. Reduz context-switching que destrói produtividade criativa.
Documente a curva de energia honestamente
Manhã HIGH/tarde MEDIUM/noite LOW não é universal — é seu. Hermes aloca tipo de tarefa à faixa de energia certa quando você lhe dá esse mapa.
Inclua "no decisions after X"
Hora-limite para decisões importantes. Hermes adia qualquer pedido decisório recebido após esse horário para o dia seguinte.
🔑 Conceitos-chave
10:00–13:00 é parseável; "de manhã" não — o Hermes precisa de horários
Agrupar reuniões protege janelas de deep work do context-switching
Documenta sua biologia — Hermes aloca tarefa certa à faixa de energia certa
"No decisions after 19:00" — Hermes adia pedidos decisórios automaticamente
🧠 Registrando decisões, pessoas e ferramentas em Memory
Memory é onde decisões passadas viram anti-sugestões automáticas. Você já testou X e descartou? Documente — assim o Hermes não te sugere X de novo daqui a três meses.
O que é
Memory tem três sub-listas: decisions (escolhas estratégicas já feitas e seu raciocínio), people (rede de contatos com contexto de relacionamento), tools (stack atual com motivo de cada escolha). Cada item documenta o "porquê" para evitar re-debater no futuro.
📚 Memory preenchido
## Memory ### decisions - 2025-Q4: rejected Substack migration reason: lock-in + comissão; mantemos Ghost self-hosted - 2026-Q1: dropped enterprise tier from roadmap reason: sales cycle 6+ meses não cabe em runway atual - 2026-Q1: TRIAD pricing tiered (R$ 297 / 997 / 2.997) reason: anchor + upsell path validado em 3 cohorts ### people - @marina_ux — designer parceira, projetos visuais - @rafa.dev — co-founder técnico, decisões de stack - @clara_growth — consultora paid ads, contratar Q3 ### tools - Claude Code (Opus 4.7) — primary dev/writing - Ghost self-hosted — newsletter + courses - Stripe BR — pagamentos (alt: Pagar.me se Stripe cair) - Supabase — backend SaaS layer (Q4)
🔁 Anti-sugestão por decisão documentada
Cada decisão em Memory inclui o motivo. Quando o Hermes está prestes a sugerir algo que você já descartou, ele cruza com a lista, encontra a entrada, e em vez de propor X, propõe Y considerando que X foi rejeitado por motivo Z. Sem o motivo, ele esquece — e sugere de novo.
🔑 Conceitos-chave
Nunca registre só a decisão — o "porquê" é o que vira anti-sugestão
Não basta o handle — papel e tipo de relacionamento ativam introduções certas
"Stripe BR (alt: Pagar.me)" — Hermes sabe para onde migrar em incidente
Decisões antigas (>12 meses) viram candidatas a revisão automática
🔄 Fazendo Hermes carregar o soul.md — verificação final
Preencher não é ativar. Você precisa forçar reload e diagnosticar — caso contrário, fica achando que o Hermes lê o arquivo enquanto ele ainda está com o estado vazio em memória.
O que é
A sequência de ativação: hermes reload soul força releitura do arquivo, hermes diagnose mostra quais seções foram parseadas com sucesso e quais ficaram vazias. Sem rodar os dois, o soul.md pode estar editado em disco mas não em memória.
⚡ Comandos de ativação e verificação
# 1. Forçar reload do soul.md $ hermes reload soul ✓ soul.md reloaded from ~/.hermes/soul.md ✓ 6 sections parsed (Identity, Mission, Business, Voice, Rhythm, Memory) # 2. Diagnosticar estado em memória $ hermes diagnose [soul.md] Identity ........... ✓ 4 fields Mission ............ ✓ Goal set, 3 pillars, 2 not-goals Business ........... ✓ MRR/runway/3 metrics Voice .............. ✓ tone + 4 forbidden + 5 hard_nos Rhythm ............. ✓ 2 windows + creation_days + curve Memory ............. ✓ 3 decisions + 3 people + 4 tools # 3. Teste com pergunta de contexto $ hermes ask "qual meu runway atual?" → 9 months (cap R$ 150k, burn R$ 11k/mo) — Apr/26
Salve o arquivo no editor
Edição em disco não é leitura em memória — o Hermes ainda está com a versão antiga até você rodar reload.
Rode hermes reload soul
Comando explícito de releitura. Output confirma quantas seções foram parseadas — se vier menos de 6, há erro de sintaxe no Markdown.
Rode hermes diagnose
Mostra estado atual em memória, campo a campo. Qualquer seção marcada como vazia (✗) indica que o parser não conseguiu ler — corrija e reload de novo.
Teste com pergunta de contexto
"Qual meu runway?" / "Quais meus hard nos?" — se o Hermes responde com o valor correto, está ativo. Se responde genericamente, reload falhou silenciosamente.
🎯 Critério de sucesso da ativação
hermes diagnose mostra ✓ em todas as 6 seções, e uma pergunta de contexto retorna o valor exato do soul.md. Se um desses dois falha, o soul.md não está ativo — independentemente do que está salvo em disco.
🔑 Conceitos-chave
Salvar no editor não recarrega o Hermes — reload explícito é obrigatório
Força releitura e reporta quantas seções foram parseadas com sucesso
Snapshot do estado em memória — fonte da verdade do que está ativo
Verificação funcional — se a resposta tem o valor exato, soul.md está ativo
🎓 Resumo do Módulo — e fim da Trilha 2
Você completou a Trilha 2 (Técnica). Saiu de "ouvi falar do soul.md" para um arquivo preenchido, parseado e ativo, governando todas as suas sessões com o Hermes.
Próxima Trilha: Trilha 3 — Avançado
Com soul.md ativo, você está pronto para engenharia de prompts, controle de custos, observabilidade e arquitetura multi-agente.