Verificando acesso...

Início / Trilha 2 / Módulo 2.5
MÓDULO 2.5

🎭 Criando a skill Orpheus — Seu deep work agent

Configure o Pantheon, escreva os três system prompts do Triad e teste Orpheus com uma tarefa real.

7
Tópicos
~50
Minutos
Intermediário
Nível
Prática
Tipo
1

🧩 O que é uma skill no Hermes e como funciona

Uma skill no Hermes não é um app, é um agente nomeado com persona, missão e prompts. Cada skill agrupa três coisas: um system prompt (quem você é), um modelo escolhido (quem responde) e ferramentas disponíveis (o que pode fazer).

O que é

Uma skill é uma unidade reutilizável de agente — combinação fixa de persona, modelo, ferramentas e system prompt — que você invoca por nome quando precisa daquela capacidade. Orpheus é a sua skill de deep work: um orquestrador Triad nomeado, com prompt pré-escrito e modelo Opus configurado.

🔧 Anatomia de uma skill

  • •Nome e missão: identificador único + uma frase que define o trabalho da skill.
  • •System prompt: instruções fixas que definem comportamento, formato de saída e regras.
  • •Modelo: qual LLM responde (Opus, Sonnet, DeepSeek, GPT-5.5…). Determina custo, velocidade e profundidade.
  • •Ferramentas: capacidades adicionais (web search, code, file I/O, sub-skills) que a skill pode acionar.
  • •Sub-skills: uma skill pode invocar outras como ferramentas — é assim que Orpheus chama Conductor, Worker e Critic.

💡 Por que aprender

Skills são unidades de reuso. Sem skill nomeada, você reescreve o system prompt toda vez — e a qualidade varia. Com Orpheus configurada, você invoca o Triad inteiro com um comando.

🔑 Conceitos-chave

Skill = persona + modelo + prompt

Os três elementos fixos que definem o comportamento reproduzível

Invocação por nome

Você chama "Orpheus" em vez de reconstruir o prompt do zero

Sub-skills como ferramentas

Orpheus invoca Conductor/Worker/Critic como capacidades aninhadas

Reuso e consistência

Skill garante que o comportamento seja o mesmo em toda execução

2

🎼 O Pantheon — o painel de personas e skills

O Pantheon é o painel onde você cria, edita e gerencia todas as suas skills do Hermes. É o lugar onde Orpheus vai morar — junto com qualquer outra persona que você criar depois.

O que é

Pantheon é a interface visual do Hermes para gerenciar skills. Você abre com hermes pantheon, vê todas as personas configuradas, cria novas, edita prompts existentes e revisa quais modelos estão em uso.

⚙️ Acessando o Pantheon

$ hermes pantheon

# abre o painel visual no navegador (porta 7777)

$ hermes pantheon list

# lista todas as skills configuradas no terminal

$ hermes pantheon new orpheus

# cria uma nova skill chamada orpheus

🗂️ O que você vê no Pantheon

  • •Lista de skills: cards com nome, missão curta e modelo em uso.
  • •Editor de prompt: textarea grande com syntax highlight para Markdown.
  • •Seletor de modelo: dropdown com Opus, Sonnet, Haiku, DeepSeek-R1, GPT-5.5 etc.
  • •Sub-skills: checkbox para indicar quais outras skills esta pode invocar.
  • •Histórico de versões: diff entre versões anteriores do prompt — fundamental para iteração.

🔑 Conceitos-chave

hermes pantheon

Comando que abre o painel visual de skills do Hermes

Editor visual de prompt

Interface dedicada para escrever e revisar system prompts

Histórico de versões

Diff entre versões do prompt — base para iteração sistemática

Mapa de sub-skills

Visualização de quais skills uma persona pode invocar como ferramenta

3

👤 Criando a persona Orpheus no Pantheon

Orpheus é a persona orquestradora — o Condutor do seu Triad. Nome, missão e modelo precisam ser configurados antes dos system prompts. Use Opus como modelo orquestrador — é o que dá nuance ao briefing.

O que é

A persona Orpheus é a skill principal do seu deep work agent. Ela recebe seu objetivo em linguagem natural, refina em briefing, despacha ao Worker, recebe drafts, envia ao Critic e devolve o resultado final. As outras duas — Worker e Critic — são sub-skills invocadas por Orpheus.

📋 Configuração inicial

name: orpheus

mission: Deep work agent. Orquestra Triad para tarefas estratégicas.

model: claude-opus-4

role: conductor

sub_skills:

- worker_deepseek

- critic_gpt55

tools: [web_search, file_read]

🎯 Por que Opus como Condutor

  • •Nuance no briefing: Opus identifica ambiguidades sutis no objetivo que modelos menores deixam passar.
  • •Critérios mensuráveis: consegue transformar "boa análise" em condições testáveis sem perder o espírito do pedido.
  • •Síntese final: ao consolidar drafts aprovados pelo Critic, Opus preserva os melhores elementos de cada ângulo.
  • •Custo justificado: Opus é caro, mas é o ponto onde investimento de modelo tem maior retorno.

🔑 Conceitos-chave

Nome curto e único

"orpheus" — invocável por comando, sem ambiguidade

Missão em uma frase

Critério para decidir se uma tarefa pertence a Orpheus ou outra skill

Opus como Condutor

Maior retorno por dólar de modelo em todo o sistema Triad

Sub-skills declaradas

worker_deepseek e critic_gpt55 ficam disponíveis como ferramentas

4

📝 Os três system prompts do Triad

Os três prompts são o cérebro do sistema. Conductor faz briefing, Worker paraleliza, Critic julga. Cada um com responsabilidade clara — e nenhum invade o papel do outro.

O que é

São os três system prompts que definem o comportamento de cada papel do Triad. Você cola cada um na skill correspondente no Pantheon: Orpheus recebe o Conductor, worker_deepseek recebe o Worker, critic_gpt55 recebe o Critic.

🎼 Conductor (Opus) — system prompt

You are the CONDUCTOR. Given a user goal, interrogate to remove ambiguity, then produce a briefing with: - Objective in one unambiguous sentence - 3-5 measurable success criteria (testable, not subjective) - Explicit constraints (what NOT to do, formats, assumptions) - Relevant context (data, prior decisions, operational limits) - 3-5 angles to explore in parallel (each with a FUNDAMENTALLY DIFFERENT premise — not paraphrasing) Dispatch the briefing to WORKER. When CRITIC returns SHIP, validate that the success criteria are objectively met and return the final result to the user. When CRITIC returns REVISE, forward to WORKER with the specific corrections requested. When CRITIC returns FUNDAMENTAL FLAW, restart the failing angle from a different premise.

⚙️ Worker (DeepSeek) — system prompt

You are the WORKER. Given a briefing from CONDUCTOR, explore 3-5 angles in parallel. Each angle MUST have a FUNDAMENTALLY DIFFERENT premise — not paraphrasing of the same idea with new words. For each angle: - State the premise explicitly at the top - Show your reasoning (not only conclusions) - Address every success criterion from the briefing - Identify which constraints apply and which don't Do NOT judge value across angles — CRITIC does that. Do NOT pick a winner. Deliver all angles fully developed. If you hit the token limit before completing all angles: - Deliver the angles you finished - Signal PARTIAL_DELIVERY: [X of Y angles complete] - Never truncate an angle mid-development

⚖️ Critic (GPT-5.5) — system prompt

You are the CRITIC. Evaluate each WORKER draft against the briefing's success criteria. Be rigorous, not polite. Return EXACTLY ONE of three verdicts per angle: SHIP - Meets all success criteria objectively - No unverifiable premises remain - Approved as-is for delivery REVISE - List specific problems with: location (which angle, paragraph, claim) what is wrong (concrete, not "could be better") why it fails the criterion how it would look if corrected - Worker will rework based on this list FUNDAMENTAL FLAW - The premise itself is unrecoverable - Restart this angle from a different premise - Do not waste iterations patching a broken foundation Never approve out of politeness. Never reject without specifying what would change the verdict.

✗ System prompt vago

  • ✗"Você é um assistente útil que dá bons conselhos"
  • ✗"Pense profundamente e seja criativo"
  • ✗"Critique de forma construtiva"
  • ✗"Explore o problema de várias formas"

✓ System prompt acionável

  • ✓"Retorne SHIP, REVISE ou FUNDAMENTAL FLAW por ângulo"
  • ✓"Cada ângulo: premissa fundamentalmente diferente"
  • ✓"REVISE deve incluir: local + o quê + por quê + como corrigir"
  • ✓"PARTIAL_DELIVERY se atingir limite de tokens"

🔑 Conceitos-chave

Conductor: briefing

Remove ambiguidade, define critérios mensuráveis, despacha angles

Worker: paralelismo

3-5 ângulos com premissas distintas, raciocínio visível, sem julgar

Critic: três veredictos

SHIP, REVISE com especificidade, ou FUNDAMENTAL FLAW

Sem invasão de papel

Worker não julga, Critic não cria, Conductor não pula etapas

5

🔄 Sincronizando Orpheus com Hermes via prompt

Depois de salvar os três prompts, não invoque Orpheus imediatamente com uma tarefa real. Faça primeiro uma sincronização: peça confirmação de entendimento. Isso valida que o sistema absorveu os prompts antes de gastar tokens com uma tarefa de valor.

O que é

Sincronização é um prompt curto enviado a Orpheus que pede um resumo do próprio system prompt, dos critérios de despacho e do contrato com Worker e Critic. Se a resposta vier coerente, está pronto. Se vier confuso, o prompt tem ambiguidade.

🔄 Prompt de sincronização

Antes de qualquer tarefa, confirme que você entendeu: 1. Qual é a sua missão como Conductor? 2. Quais são os 5 elementos obrigatórios do briefing? 3. Em qual situação você despacha ao Worker? 4. O que você faz quando Critic retorna REVISE? 5. O que você faz quando Critic retorna FUNDAMENTAL FLAW? Responda cada item em uma frase. Não execute nenhuma tarefa real ainda — apenas confirme o entendimento.

🧪 Como interpretar a resposta

  • •Resposta coerente e específica: sistema sincronizado, pode prosseguir para tarefa real.
  • •Resposta genérica ou parafraseada: o prompt tem instrução vaga em algum ponto — revise antes de testar com tarefa de valor.
  • •Resposta com lacunas: Orpheus não absorveu alguma regra. Identifique qual e reforce no system prompt.
  • •Resposta confunde papéis: se Orpheus diz que vai "criticar os drafts", o limite de papel está fraco — reforce que Critic é uma sub-skill separada.

💡 Por que sincronizar primeiro

Sincronização custa centavos. Uma tarefa real mal sincronizada custa dólares e tempo. É o equivalente a "compile-check" antes de rodar um pipeline caro.

🔑 Conceitos-chave

Sync prompt

Prompt de baixo custo que valida absorção do system prompt

Confirmação por enumeração

Listar os 5 itens força resposta específica, evita paráfrase genérica

Detecção de invasão de papel

Se Orpheus diz que vai criticar, o limite de papel não está claro

Compile-check do agente

Sync é o "compile" antes de gastar tokens com tarefa real

6

🚀 Testando Orpheus com uma tarefa real

Primeiro teste real: tarefa de valor estratégico médio — não trivial (não testa nada) e não crítica (custo de errar alto). O objetivo é ver o ciclo completo: briefing, paralelismo, crítica, iteração e entrega.

O que é

É a primeira execução end-to-end do Triad com tarefa real — onde você observa cada etapa, mede tempo e tokens por papel, e identifica onde o sistema funciona ou trava. Exemplo de tarefa: "Defina os 3 segmentos de cliente onde nosso produto tem maior tração e justifique com critério mensurável".

1

Você envia o objetivo a Orpheus

Linguagem natural, sem se preocupar em estruturar. Ex: "Identifique nossos 3 melhores segmentos de cliente e justifique".

2

Conductor interroga

Faz 2–4 perguntas para remover ambiguidade: "tração = receita ou retenção?", "horizonte de tempo?", "exclui clientes legacy?". Você responde.

3

Conductor produz o briefing

Objetivo, 4 critérios mensuráveis, 2 restrições, contexto, 4 ângulos com premissas distintas (por receita, por retenção, por CAC, por NPS).

4

Worker explora 4 ângulos em paralelo

Cada ângulo com raciocínio visível, sem julgamento de valor. Entrega 4 drafts completos.

5

Critic emite veredicto por ângulo

Ex: ângulo 1 SHIP, ângulo 2 REVISE (premissa não verificável), ângulo 3 SHIP, ângulo 4 FUNDAMENTAL FLAW (definição circular).

6

Conductor itera o que precisa

Reenviar ângulo 2 ao Worker com correções; reiniciar ângulo 4 do zero com premissa diferente. Loop até todos SHIP.

7

Orpheus consolida e devolve resultado

Síntese dos ângulos aprovados → 3 segmentos finais com justificativa por critério mensurável. Entrega pronta para decisão.

🎯 O que medir nesta primeira execução

Tempo total, número de iterações no loop Worker-Critic, número de FUNDAMENTAL FLAW, tokens por papel. Esses 4 números são a baseline para todas as iterações de prompt que você vai fazer no Tópico 7.

🔑 Conceitos-chave

Tarefa de valor médio

Nem trivial nem crítica — para testar sem custo de erro alto

Ciclo end-to-end

Objetivo → briefing → angles → veredicto → iteração → entrega

Baseline de 4 métricas

Tempo, iterações, FUNDAMENTAL FLAW, tokens por papel

Síntese final pelo Conductor

Orpheus consolida angles aprovados — não o Worker, não o Critic

7

🔧 Ajustando e refinando após o primeiro uso

Depois da primeira execução, você tem dados. Iterar o system prompt com base no resultado é onde o sistema deixa de ser genérico e vira seu — calibrado ao tipo de tarefa que você roda.

O que é

É o processo de revisar os system prompts de Orpheus, Worker e Critic com base no que aconteceu na execução real — identificando padrões de reprovação, gaps de instrução e oportunidades de redução de iterações. Cada ajuste é uma nova versão no histórico do Pantheon.

🛠️ Padrões comuns e ajustes

  • •Critic reprova muito por "premissa não verificável": adicione no Conductor "exija que cada ângulo declare evidência verificável de premissa".
  • •Worker entrega ângulos quase idênticos: reforce "premissa fundamentalmente diferente — não paráfrase" no Worker e dê 2 exemplos de premissas distintas no briefing.
  • •Loop com 5+ iterações: o briefing está fraco. Audite os 5 elementos antes de despachar e adicione critério mais específico no Conductor.
  • •Critic dá REVISE vago: reforce a estrutura "local + o quê + por quê + como corrigir" e dê exemplo no system prompt.
  • •Orpheus pula a interrogação: adicione no Conductor "antes de produzir briefing, faça pelo menos 2 perguntas se o objetivo tem ambiguidade".

📋 Ciclo de iteração

1.Registre as 4 métricas da execução (tempo, iterações, FUNDAMENTAL FLAW, tokens).
2.Identifique o padrão de reprovação mais frequente do Critic.
3.Ajuste o system prompt do papel correto (Conductor, Worker ou Critic) com instrução específica para cobrir o gap.
4.Re-sincronize com o prompt de confirmação (Tópico 5) antes de testar.
5.Re-execute uma tarefa de referência similar e compare as 4 métricas.

🎯 Benchmark de Orpheus calibrada

Menos de 3 iterações no loop Worker-Critic para tarefas de complexidade média. Zero FUNDAMENTAL FLAW por execução. Briefing produzido em menos de 2 minutos. Acima disso, há prompt para refinar.

🔑 Conceitos-chave

Iteração baseada em dados

As 4 métricas dão a direção do ajuste — não intuição

Versionamento do prompt

Cada ajuste vira uma nova versão no histórico do Pantheon

Padrão de reprovação → gap

Onde Critic reprova mais aponta o gap no Conductor ou Worker

Tarefa de referência

Mesma tarefa antes e depois do ajuste — comparação válida

✅ Resumo do Módulo

✓
Skill = persona + modelo + prompt — unidade reusável invocável por nome, com sub-skills como ferramentas
✓
Pantheon — o painel onde Orpheus mora, com editor de prompt e histórico de versões
✓
Opus como Condutor — maior retorno por dólar em todo o Triad; nuance no briefing e na síntese final
✓
Três system prompts — Conductor (briefing), Worker (paralelismo), Critic (SHIP/REVISE/FUNDAMENTAL FLAW)
✓
Sync prompt antes da tarefa real — confirmação por enumeração detecta ambiguidade barato
✓
Iterar com 4 métricas — tempo, iterações, FUNDAMENTAL FLAW e tokens são a baseline para refinar os prompts

Próximo Módulo:

2.6 — soul.md na prática: dando alma e contexto persistente a Orpheus

← Voltar para Trilha 2 Próximo Módulo →