Prometheus

O que Prometheus faz?

Um framework geral de meta-prompting para criar prompts para agentes LLM. Funciona com qualquer CLI agêntica (Claude Code, Gemini CLI, Cursor, outros) e para uso não-CLI. Abrange todas as sete formas de prompt: loops agênticos, tarefas únicas, cadeias de fluxo de trabalho, prompts de subagentes, personas de sistema, avaliadores LLM-como-juiz e equipes de agentes.

O framework é construído sobre engenharia de contexto clássica ("nível certo de abstração" da Anthropic, "menor conjunto viável de tokens", "exemplos em vez de regras") e sobre princípios semânticos quânticos (prompts são operadores, não busca de chaves; a ordem é estrutural; ambiguidade é uma característica; a combinação não é aditiva).

Quando usar esta skill

Acione quando o usuário estiver iniciando qualquer trabalho de design de prompts para um agente LLM. Frases comuns:

• "Ajude-me a escrever um prompt para [tarefa]"
• "Preciso de um prompt de sistema para [propósito]"
• "Configure-me um prompt do [Claude Code / Gemini CLI / etc.] para [projeto]"
• "Projete um prompt LLM-como-juiz para [avaliação]"
• "Estou construindo um subagente que faz [X], ajude-me a escrever suas instruções"
• "Inicialize um loop agêntico para [tarefa]"

Não acione para: perguntas e respostas simples, solicitações de conclusão de código ou tarefas onde o usuário quer a resposta, não um prompt para obter a resposta depois.

Postura central: prompts são operadores

O rearranjo mais profundo sobre o qual este framework se apoia, da literatura semântica quântica: um prompt não "extrai" a resposta correta de um modelo. Um prompt é um operador que constrói uma resposta através da transformação do estado semântico do modelo. Cada seção de um prompt é uma matriz que amplifica certas interpretações, suprime outras e mistura estados base para produzir leituras novas.

Isso não é metáfora. Isso muda a prática de design:

• Não "encontramos as palavras-chave certas" — projetamos transformações.
• A ordem é estrutural — operadores não comutam.
• Combinar seções produz interferência, não adição.
• Cada instrução destrói informação; projetar de acordo.
• Ambiguidade na intenção do usuário é uma superposição, não um defeito a ser eliminado.

A skill aplica esses princípios de forma concreta, não como adorno. Consulte references/quantum-principles.md para o mapeamento operacional e operators/ para o catálogo de seção como operador.

Três modos de operação

O framework opera em um dos três modos, dependendo do que o usuário traz:

Modo from-scratch (padrão). O usuário descreve uma tarefa; o framework produz um prompt. Seis fases: inferência de forma → entrevista adaptativa → rascunho de design de operador → auditoria → avaliação honesta → entrega.

Modo refactor. O usuário tem um prompt existente e deseja auditá-lo, corrigi-lo ou reescrevê-lo. Seis fases (1R a 6R): receber e analisar → entrevista de recuperação de intenção → seleção de modo (auditoria / refatoração direcionada / reescrita completa) → aplicar o modo → avaliação honesta → entrega. Procedimento completo documentado em references/refactor-mode.md.

Modo manage. O usuário aponta para um pacote de agente gerenciado existente e quer executá-lo ao longo de seu ciclo vital — monitorar suas execuções, analisar uma violação de objetivo, adaptá-lo, pará-lo e reiniciá-lo com o mesmo estado interno. Este é o framework como um gerenciador de agente, não apenas um designer: um loop MAPE-K (Monitorar / Analisar / Planejar / Executar) sobre o prompt do agente, expresso através da álgebra de operadores. Procedimento completo em references/manage-mode.md; layout do pacote, ciclo vital e livro-razão em references/agent-state.md.

Detecção de modo. Detecte automaticamente o modo refactor quando a mensagem de abertura do usuário incluir um prompt colado seguido de uma solicitação para auditar, melhorar, corrigir ou refatorar. Invocações diretas como "refatore este prompt", "audite este prompt", "o que há de errado com este prompt" acionam o modo refactor imediatamente. Detecte automaticamente o modo manage quando o usuário apontar para um caminho de pacote de agente existente ou invocar um verbo de ciclo vital contra ele — "gerencie este agente", "execute um ciclo de adaptação", "por que meu agente regrediu", "reinicie meu agente". Quando a detecção for ambígua (um prompt é colado, mas a solicitação não está clara), pergunte uma vez: "Vejo um prompt — você quer que eu o refatore, ou estava usando-o como contexto para uma tarefa diferente?" Padrão para o modo from-scratch, a menos que os sinais de refactor ou manage estejam claros.

Os três modos compartilham infraestrutura (o catálogo de formas, o catálogo de operadores, a lista de verificação de auditoria, as especificações do verificador), mas executam procedimentos diferentes. O modo manage em particular reutiliza mecanismos do from-scratch e refactor como sub-rotinas (a lista de verificação de auditoria, os sub-modos de refatoração, o verificador entre execuções) em vez de adicionar novos mecanismos analíticos. O procedimento from-scratch segue abaixo; o procedimento refactor está em references/refactor-mode.md; o procedimento manage está em references/manage-mode.md.

Procedimento from-scratch (seis fases)

Fase 1 — Inferência de forma, não roteamento

A descrição da tarefa do usuário chega como um estado semântico em superposição. Não faça uma pergunta de roteamento. Infira a forma a partir dos sinais já presentes, no espírito da amostragem bayesiana §2.4.

1. Leia a solicitação do usuário com atenção. Extraia sinais: verbos (construir / rascunhar / classificar / avaliar / pontuar / extrair / resumir), substantivos (sistema / documento / pipeline / loop / agente / persona / juiz), marcadores de escala (único vs contínuo, multi-turn vs chamada única) e menções de ferramentas (Claude Code, Gemini CLI, etc.).

2. Gere uma distribuição posterior interna sobre formas plausíveis. O catálogo de formas está em templates/shape-catalog.md. Não se comprometa ainda — mantenha pesos.

3. Escolha a forma com maior massa posterior apenas se a segunda forma estiver claramente atrás. Se duas ou mais formas estiverem dentro de ~30% uma da outra, a inferência é ambígua e você deve desambiguar via uma pergunta de esclarecimento direcionada. Formulação como uma escolha forçada entre as duas principais formas, não como uma pergunta de roteamento aberta.

4. Domínio (engenharia / pesquisa / escrita / operações / genérico) é um eixo secundário, ortogonal à forma. Infira-o da mesma maneira. Um prompt de escrita única e um prompt de engenharia agêntico ambos aplicam este framework, apenas com conteúdo de seção diferente.

5. Detecte sinais de raciocínio duro durante a mesma passagem. Tarefas matemáticas/lógicas, planejamento em múltiplas etapas, análise ou depuração de código, problemas com múltiplas restrições, ou qualquer tarefa onde o usuário mencione o modelo falhando na primeira tentativa são sinais de que o arcabouço de ferramentas cognitivas (por references/reasoning-patterns.md) deve ser um padrão estrutural no rascunho, não uma extensão opcional. Dois ou mais sinais + runtime com chamada de ferramentas → incluir o arcabouço nos níveis legacy e strong, onde o resultado empírico citado se aplica. No nível frontier, o arcabouço é uma opção acionada por M5, não um padrão — veja references/reasoning-patterns.md §gating de nível.

6. Infira o nível de capacidade do substrato — um terceiro eixo, ortogonal à forma e ao domínio, lido a partir da resposta do runtime: frontier (os modelos mais recentes com alta capacidade de seguir instruções), strong (modelos mainstream atuais), legacy (modelos mais antigos ou menores). Desconhecido → assuma strong. O nível condiciona: força do operador padrão na Fase 3 (Princípio 9 em references/quantum-principles.md — operadores prescritivos superprojetam em substratos com alta capacidade de seguir instruções), limites de acionamento do arcabouço (ponto 5 acima), disponibilidade de preenchimento e orientação de parâmetros de controle de raciocínio na Fase 6.

Fase 2 — Entrevista adaptativa (consciente de operador)

A entrevista é ela mesma uma sequência de operadores aplicados à intenção do usuário. Por §5.6, cada pergunta colapsa a ambiguidade irreversivelmente. Não colapse rápido demais.

Regras de condução:

• Limite de 6 perguntas planas no total, incluindo qualquer pergunta de desambiguação da Fase 1 (3 universais — contexto de implantação ignorável quando óbvio — mais 2–3 específicas da forma). Limite rígido. Passagens de co-autoria (Formas 3, 6, 7) estão isentas, conforme regras de conduta em templates/interview-branches.md.
• Uma pergunta por vez. Perguntas múltiplas por turno produzem respostas mais rasas.
• Pule perguntas cujas respostas já estão na solicitação do usuário. Repetir é destruição de informação.
• A ordem das perguntas importa (§2.3, §5.1). Faça a pergunta de enquadramento mais ampla primeiro, depois restrições de estreitamento, formatação por último. A primeira pergunta define o subespaço no qual todas as perguntas posteriores operarão.
• Preserve a superposição onde o custo de perguntar é baixo e o custo de errar é alto (§4.1). Para escolhas de nível arquitetural (forma, público, ferramenta), preserve. Para escolhas táticas (nome de arquivo, capitalização), defina um padrão e siga em frente.

Bancos de perguntas por forma estão em templates/interview-branches.md. Duas perguntas são universais em todas as formas:

1. Ferramenta / runtime. "Onde este prompt será executado? (Claude Code, Gemini CLI, API OpenAI, LLM genérico, outro?)" Influencia a nomeação de arquivos de memória e affordances específicas da ferramenta.
2. Definição de conclusão / critério de sucesso. "Como você saberá que o prompt funcionou? Algo verificável, não baseado em sensação." Fornece a rubrica para autoavaliação na Fase 5.

Termine a entrevista com um colapso de resumo: declare a forma que você inferiu, as principais restrições que reuniu e os padrões que está atribuindo a qualquer coisa não especificada. Dê ao usuário uma chance de se opor antes de rascunhar. Este é o passo de medição deliberada (§1.2) — torne-o explícito para que o usuário possa contestar o colapso.

Fase 3 — Rascunho de design de operador

Rascunhar é design de operador (§5.3), não preenchimento de seção. Para cada seção que você incluir:

1. Identifique os estados base que a seção transforma — quais interpretações devem ser amplificadas, suprimidas ou misturadas?
2. Escolha a força — operadores fortes (persona, restrições rígidas) projetam agressivamente; operadores fracos (preferências de estilo, formatação) comutam com a maioria. Calibre a força padrão para o nível do substrato (Princípio 9): no nível frontier, prefira instruções breves e gerais em vez de enumeração e reserve linguagem de intensidade ("CRÍTICO", "DEVE", proibições repetidas) para restrições com modos de falha demonstrados; nos níveis legacy, uma projeção mais forte é frequentemente justificada. O bloqueio de capacidade para funções com capacidade destrutiva permanece em camadas e alto em todos os níveis — sua justificativa é risco, não fraqueza do substrato.
3. Posicione na sequência de operadores conforme §5.1: enquadramento mais amplo primeiro, estreitamento em seguida, formato por último.
4. Verifique interferência com seções adjacentes (§5.4) — a combinação produz comportamento emergente, intencional ou não?

Use templates/shape-catalog.md para espinhas específicas de forma. Use operators/ para as descrições de operador por seção (o que cada seção amplifica, suprime, mistura; sua força; suas propriedades de comutação). Para tarefas que não justificam seleção completa de forma (pequenas, bem definidas, de propósito único), templates/minimum-viable-prompt.yaml é o arcabouço de fallback — seis slots (sistema / instruções / exemplos / restrições / estado / consulta) e nada mais.

Para tarefas de raciocínio pesado onde a decomposição estruturada supera a cadeia de pensamento monolítica, consulte references/reasoning-patterns.md — ele documenta o subpadrão de ferramentas cognitivas (IBM Zurich, +16,6% no AIME2024) e quando invocá-lo dentro da forma escolhida.

Quando a saída do prompt for consumida por outro agente LLM, em vez de exibida a um humano (mais comum em prompts de subagente/ferramenta Forma 4 e prompts LLM-como-juiz Forma 6), consulte references/agent-consumability.md. O design da saída muda quando o consumidor é um agente: marcadores de falha pesquisáveis, estrutura agregada primeiro, saída padrão compacta com logs detalhados, amostragem determinística mas diferente e transições de estado visíveis.

Para Forma 7 (equipe de agentes), a escolha de topologia é fundamental e deve preceder o rascunho por função. Consulte references/agent-team-topologies.md para as quatro topologias canônicas (orquestrador-trabalhadores, seccionamento de paralelização, votação de paralelização, avaliador-otimizador) com seus perfis de operador, definições de função e modos de falha comuns. Escolha a topologia primeiro, depois rascunhe o prompt de cada função usando a espinha de sua forma individual, então audite a coerência entre funções.

Regras universais de rascunho se aplicam a todas as formas:

• Nível certo de abstração. Específico o suficiente para agir, flexível o suficiente para o modelo se adaptar. Codificação rígida frágil e gestos vagos são modos de falha duais.
• Menor conjunto viável de tokens. Corte qualquer coisa que não aborde um modo de falha específico ou habilite um comportamento concreto. Cada token custa atenção.
• Exemplos em vez de regras. Quando uma regra é essencial, escreva um exemplo trabalhado. Exemplos são operadores essenciais que ancoram instruções abstratas. Mas exemplos têm sua própria superfície de ambiguidade — qualquer julgamento silencioso dentro de um exemplo se torna uma regra que o modelo engenharia reversamente. Antes de enviar qualquer exemplo, pergunte: o que este exemplo ensina silenciosamente além do que eu pretendia? Se não tiver certeza, substitua por um caso mais limpo.
• Ordenação de seções por força do operador. Operadores mais fortes primeiro.
• Modos de falha como NÃO FAÇA. Cada um aborda uma aresta afiada específica conhecida com consequência concreta. Avisos genéricos desperdiçam tokens.

Fase 4 — Auditoria (estrutural e quântica)

Execute a lista de verificação de auditoria em references/audit-checklist.md. A lista combina verificações clássicas de engenharia de contexto (nível certo de abstração, menor conjunto de tokens, exemplos presentes, durabilidade de suporte de longo horizonte) com verificações semântico-quânticas:

• Catálogo de operadores completo. Cada seção tem um perfil claro de amplificar/suprimir/misturar. Nenhuma seção é "decoração".
• Ordenação otimizada. Operadores mais fortes primeiro. Teste trocando mentalmente seções adjacentes e perguntando "isso muda o comportamento?" Se sim, você identificou corretamente pares não comutativos.
• Interferência verificada. Quando duas seções provavelmente interagem (por exemplo, persona + tom + formato), confirme que a combinação produz o comportamento emergente pretendido, não cancelamento indesejado.
• Preservação de informação. Contexto importante é carregado o mais cedo possível (ele sobrevive a mais projeções). Coisas que devem permanecer ambíguas são sinalizadas como tal, não pré-colapsadas.
• Consciente de medição. Se o prompt incluir uma etapa de autoavaliação ou verificação, a métrica está alinhada com a definição de conclusão da Fase 2?

...

[truncado para tradução]