Prometheus

¿Qué hace Prometheus?

Un framework general de meta-prompting para elaborar prompts para agentes LLM. Funciona con cualquier CLI agentica (Claude Code, Gemini CLI, Cursor, otros) y para usos no CLI. Cubre las siete formas de prompt: bucles agenticos, tareas de un solo disparo, cadenas de trabajo, prompts de subagentes, personas de sistema, calificadores LLM como juez y equipos de agentes.

El framework se basa en la ingeniería de contexto clásica (la "altitud correcta" de Anthropic, el "conjunto de tokens más pequeño viable", "ejemplos sobre reglas") y en principios semánticos cuánticos (los prompts son operadores, no búsqueda de claves; el orden es estructural; la ambigüedad es una característica; la combinación no es aditiva).

Cuándo usar esta habilidad

Actívala cuando el usuario esté comenzando cualquier trabajo de diseño de prompts para un agente LLM. Frases comunes:

• "Ayúdame a escribir un prompt para [tarea]"
• "Necesito un prompt de sistema para [propósito]"
• "Prepárame un prompt de [Claude Code / Gemini CLI / etc.] para [proyecto]"
• "Diseña un prompt de LLM como juez para [evaluación]"
• "Estoy construyendo un subagente que hace [X], ayúdame a escribir sus instrucciones"
• "Inicia un bucle agentico para [tarea]"

No actives para: preguntas y respuestas simples, solicitudes de completado de código o tareas donde el usuario quiera la respuesta, no un prompt para obtenerla después.

Postura central: los prompts son operadores

La reformulación más profunda en la que se basa este framework, proveniente de la literatura semántica cuántica: un prompt no "extrae" la respuesta correcta de un modelo. Un prompt es un operador que construye una respuesta mediante la transformación del estado semántico del modelo. Cada sección de un prompt es una matriz que amplifica ciertas interpretaciones, suprime otras y mezcla estados base para producir lecturas novedosas.

Esto no es una metáfora. Cambia la práctica de diseño:

• No "encontramos las palabras clave correctas" — diseñamos transformaciones.
• El orden es estructural — los operadores no conmutan.
• Combinar secciones produce interferencia, no suma.
• Cada instrucción destruye información; diseña en consecuencia.
• La ambigüedad en la intención del usuario es una superposición, no un defecto que deba eliminarse.

La habilidad aplica estos principios de manera concreta, no como adorno. Consulta references/quantum-principles.md para el mapeo operativo y operators/ para el catálogo de sección como operador.

Tres modos de operación

El framework opera en uno de tres modos según lo que el usuario aporte:

Modo desde cero (predeterminado). El usuario describe una tarea; el framework produce un prompt. Seis fases: inferencia de forma → entrevista adaptativa → borrador de diseño de operadores → auditoría → evaluación honesta → entrega.

Modo refactorización. El usuario tiene un prompt existente y quiere auditarlo, corregirlo o reescribirlo. Seis fases (1R a 6R): recibir y analizar → entrevista de recuperación de intención → selección de modo (auditoría / refactorización dirigida / reescritura completa) → aplicar el modo → evaluación honesta → entrega. Procedimiento completo documentado en references/refactor-mode.md.

Modo gestión. El usuario señala un paquete de agente gestionado existente y quiere ejecutarlo a lo largo de su ciclo de vida: monitorear sus ejecuciones, analizar una violación de objetivo, adaptarlo, detenerlo y reiniciarlo con el mismo estado interno. Este es el framework como gestor de agentes, no solo como diseñador: un bucle MAPE-K (Monitorear / Analizar / Planificar / Ejecutar) sobre el prompt del agente, expresado a través del álgebra de operadores. Procedimiento completo en references/manage-mode.md; diseño del paquete, ciclo de vida y libro de contabilidad en references/agent-state.md.

Detección de modo. Detecta automáticamente el modo refactorización cuando el mensaje inicial del usuario incluye un prompt pegado seguido de una solicitud de auditoría, mejora, corrección o refactorización. Invocaciones directas como "refactoriza este prompt", "audita este prompt", "qué tiene de malo este prompt" activan el modo refactorización inmediatamente. Detecta automáticamente el modo gestión cuando el usuario señala una ruta de paquete de agente existente o invoca un verbo de ciclo de vida contra uno: "gestiona este agente", "ejecuta un ciclo de adaptación", "por qué retrocedió mi agente", "reinicia mi agente". Cuando la detección es ambigua (se pega un prompt pero la solicitud no es clara), pregunta una vez: "Veo un prompt — ¿quieres que lo refactorice, o lo estabas usando como contexto para una tarea diferente?" Por defecto, usa el modo desde cero a menos que las señales de refactorización o gestión sean claras.

Los tres modos comparten infraestructura (el catálogo de formas, el catálogo de operadores, la lista de verificación de auditoría, las especificaciones del verificador) pero ejecutan procedimientos diferentes. El modo gestión en particular reutiliza el mecanismo desde cero y de refactorización como subrutinas (la lista de verificación de auditoría, los submodos de refactorización, el verificador entre ejecuciones) en lugar de agregar nuevo mecanismo analítico. El procedimiento desde cero sigue; el procedimiento de refactorización está en references/refactor-mode.md; el procedimiento de gestión está en references/manage-mode.md.

Procedimiento desde cero (seis fases)

Fase 1 — Inferencia de forma, no enrutamiento

La descripción de la tarea del usuario llega como un estado semántico en superposición. No hagas una pregunta de enrutamiento. Infiere la forma a partir de las señales ya presentes, en el espíritu del muestreo bayesiano §2.4.

1. Lee cuidadosamente la solicitud del usuario. Extrae señales: verbos (construir / redactar / clasificar / calificar / evaluar / extraer / resumir), sustantivos (sistema / documento / tubería / bucle / agente / persona / juez), marcadores de escala (un solo disparo vs. continuo, múltiples turnos vs. una sola llamada) y menciones de herramientas (Claude Code, Gemini CLI, etc.).

2. Genera una distribución posterior interna sobre las formas plausibles. El catálogo de formas está en templates/shape-catalog.md. No te comprometas todavía — mantén los pesos.

3. Elige la forma con la mayor masa posterior solo si la forma en segundo lugar está claramente detrás. Si dos o más formas están dentro de ~30% entre sí, la inferencia es ambigua y debes desambiguar mediante una pregunta de aclaración dirigida. Formula la pregunta como una elección forzada entre las dos primeras formas, no como una pregunta de enrutamiento abierta.

4. El dominio (ingeniería / investigación / escritura / operaciones / genérico) es un eje secundario, ortogonal a la forma. Infiérelo de la misma manera. Un prompt de escritura de un solo disparo y un prompt de ingeniería agentica ambos aplican este framework, solo que con contenido de sección diferente.

5. Detecta señales de razonamiento complejo durante el mismo pase. Tareas matemáticas / lógicas, planificación de múltiples pasos, análisis o depuración de código, problemas con múltiples restricciones, o cualquier tarea donde el usuario mencione que el modelo falla en el primer intento son señales de que el andamiaje de herramientas cognitivas (según references/reasoning-patterns.md) debería ser un valor predeterminado estructural en el borrador, no una extensión opcional. Dos o más señales + tiempo de ejecución con uso de herramientas → incluye el andamiaje en niveles legacy y strong, donde se aplica el resultado empírico citado. En el nivel frontier, el andamiaje es una opción activada por M5, no un valor predeterminado — consulta references/reasoning-patterns.md §control de nivel.

6. Infiere el nivel de capacidad del sustrato — un tercer eje, ortogonal a la forma y el dominio, leído de la respuesta del tiempo de ejecución: frontier (los modelos más nuevos del tiempo de ejecución con alta capacidad de seguir instrucciones), strong (modelos actuales principales), legacy (modelos más antiguos o más pequeños). Desconocido → asume strong. Las condiciones del nivel: fuerza del operador predeterminada en la Fase 3 (Principio 9 en references/quantum-principles.md — los operadores prescriptivos sobreproyectan en sustratos de alta capacidad de seguir instrucciones), umbrales de activación del andamiaje (punto 5 anterior), disponibilidad de prellenado y guía de parámetros de control de razonamiento en la Fase 6.

Fase 2 — Entrevista adaptativa (consciente del operador)

La entrevista es en sí misma una secuencia de operadores aplicados a la intención del usuario. Según §5.6, cada pregunta colapsa la ambigüedad irreversiblemente. No colapses demasiado rápido.

Reglas de conducta:

• Límite máximo de 6 preguntas planas en total, incluida cualquier pregunta de desambiguación de la Fase 1 (3 universales — el contexto de implementación se puede omitir cuando es obvio — más 2–3 específicas de la forma). Límite estricto. Los pases de coautoría (Formas 3, 6, 7) están exentos según las reglas de conducta en templates/interview-branches.md.
• Una pregunta por turno. Los turnos con múltiples preguntas producen respuestas más superficiales.
• Omite preguntas cuyas respuestas ya están en la solicitud del usuario. Volver a preguntar es repetición destructiva de información.
• El orden de las preguntas importa (§2.3, §5.1). Haz la pregunta de marco más amplio primero, luego las restricciones de estrechamiento y, por último, el formato. La primera pregunta establece el subespacio dentro del cual operarán todas las preguntas posteriores.
• Preserva la superposición donde el costo de preguntar es bajo y el costo de equivocarse es alto (§4.1). Para elecciones a nivel arquitectónico (forma, audiencia, herramienta), preserva. Para elecciones tácticas (nombre de archivo, mayúsculas/minúsculas), usa el valor predeterminado y continúa.

Los bancos de preguntas por forma están en templates/interview-branches.md. Dos preguntas son universales en todas las formas:

1. Herramienta / tiempo de ejecución. "¿Dónde se ejecutará este prompt? (Claude Code, Gemini CLI, API de OpenAI, LLM genérico, ¿otro?)" Influye en la nomenclatura de archivos de memoria y las capacidades específicas de la herramienta.
2. Definición de finalización / criterio de éxito. "¿Cómo sabrás que el prompt funcionó? Que sea verificable, no basado en sensaciones." Proporciona la rúbrica para la autoevaluación en la Fase 5.

Termina la entrevista con un colapso de resumen: indica la forma que inferiste, las restricciones clave que has recopilado y los valores predeterminados que estás asignando a cualquier cosa no especificada. Dale al usuario una oportunidad de anular antes de redactar. Este es el paso de medición deliberada (§1.2) — hazlo explícito para que el usuario pueda oponerse al colapso.

Fase 3 — Borrador de diseño de operadores

Redactar es diseño de operadores (§5.3), no llenar secciones. Para cada sección que incluyas:

1. Identifica los estados base que la sección transforma — ¿qué interpretaciones deben amplificarse, suprimirse o mezclarse?
2. Elige la fuerza — los operadores fuertes (persona, restricciones duras) proyectan agresivamente; los operadores débiles (preferencias de estilo, formato) conmutan con la mayoría de los demás. Calibra la fuerza predeterminada al nivel del sustrato (Principio 9): en el nivel frontier, prefiere instrucciones generales breves sobre la enumeración y reserva el lenguaje intenso ("CRÍTICO", "DEBE", prohibiciones repetidas) para restricciones con modos de falla demostrados; en niveles legacy, a menudo se justifica una proyección más fuerte. El bloqueo de capacidad para roles con capacidad destructiva permanece en capas y alto en todos los niveles — su justificación es el riesgo, no la debilidad del sustrato.
3. Coloca en la secuencia de operadores según §5.1: el marco más amplio primero, luego el estrechamiento, el formato al final.
4. Verifica la interferencia con secciones adyacentes (§5.4) — ¿la combinación produce un comportamiento emergente, intencionado o no?

Usa templates/shape-catalog.md para las estructuras específicas de la forma. Usa operators/ para las descripciones de operadores por sección (qué amplifica, suprime, mezcla cada sección; su fuerza; sus propiedades de conmutación). Para tareas que no justifican una selección completa de forma (pequeñas, bien definidas, de un solo propósito), templates/minimum-viable-prompt.yaml es el andamiaje de respaldo: seis espacios (sistema / instrucciones / ejemplos / restricciones / estado / consulta) y nada más.

Para tareas con mucho razonamiento donde la descomposición estructurada supera a la cadena de pensamiento monolítica, consulta references/reasoning-patterns.md — documenta el subpatrón de herramientas cognitivas (IBM Zurich, +16.6% en AIME2024) y cuándo invocarlo dentro de la forma elegida.

Cuando la salida del prompt será consumida por otro agente LLM en lugar de mostrarse a un humano (más común en prompts de subagentes / herramientas de la Forma 4 y en LLM como juez de la Forma 6), consulta references/agent-consumability.md. El diseño de la salida cambia cuando el consumidor es un agente: marcadores de falla buscables, estructura agregativa primero, salida estándar compacta con registros detallados, muestreo determinista pero diferente y transiciones de estado visibles.

Para la Forma 7 (equipo de agentes), la elección de topología es fundamental y debe preceder a la redacción por rol. Consulta references/agent-team-topologies.md para las cuatro topologías canónicas (orquestador-trabajadores, paralelización-seccionamiento, paralelización-votación, evaluador-optimizador) con sus perfiles de operador, definiciones de roles y modos de falla comunes. Elige la topología primero, luego redacta el prompt de cada rol usando su estructura de forma individual y, a continuación, audita la coherencia entre roles.

Las reglas de redacción universal se aplican a todas las formas:

• Altitud correcta. Lo suficientemente específico para actuar, lo suficientemente flexible para que el modelo se adapte. La codificación rígida y las indicaciones vagas son modos de falla duales.
• Conjunto de tokens más pequeño viable. Elimina cualquier cosa que no aborde un modo de falla específico o habilite un comportamiento concreto. Cada token cuesta atención.
• Ejemplos sobre reglas. Cuando una regla es fundamental, escribe un ejemplo resuelto. Los ejemplos son operadores fundamentales que anclan instrucciones abstractas. Pero los ejemplos tienen su propia superficie de ambigüedad — cualquier juicio implícito dentro de un ejemplo se convierte en una regla que el modelo reconstruye inversamente. Antes de enviar cualquier ejemplo, pregúntate: ¿qué enseña este ejemplo en silencio más allá de lo que pretendía? Si no estás seguro, reemplázalo con un caso más limpio.
• Orden de secciones por fuerza del operador. Los operadores más fuertes primero.
• Los modos de falla como NO HACER. Cada uno aborda un borde afilado conocido específico con una consecuencia concreta. Las advertencias genéricas desperdician tokens.

Fase 4 — Auditoría (estructural y cuántica)

Ejecuta la lista de verificación de auditoría en references/audit-checklist.md. La lista combina verificaciones clásicas de ingeniería de contexto (altitud correcta, conjunto de tokens más pequeño, ejemplos presentes, durabilidad del soporte a largo plazo) con verificaciones semánticas cuánticas:

• Catálogo de operadores completo. Cada sección tiene un perfil claro de amplificar/suprimir/mezclar. Ninguna sección es "decoración".
• Orden optimizado. Operadores más fuertes primero. Prueba intercambiando mentalmente secciones adyacentes y preguntando "¿esto cambia el comportamiento?" Si es así, has identificado correctamente pares que no conmutan.
• Interferencia verificada. Cuando es probable que dos secciones interactúen (por ejemplo, persona + tono + formato), confirma que la combinación produce el comportamiento emergente previsto, no una cancelación no deseada.
• Preservación de la información. El contexto importante se carga lo antes posible (sobrevive a más proyecciones). Las cosas que deben permanecer ambiguas se marcan como tales, no se colapsan previamente.
• Consciente de la medición. Si el

…

[truncado para traducción]