trailofbits/goal-prompt

Goal Prompt

/goal mantiene al agente trabajando hasta que se cumpla una condición de finalización. Tanto Claude Code como Codex lo aceptan en una sola línea, máximo 4000 caracteres. En Claude Code, un modelo pequeño reevalúa la condición después de cada turno basándose únicamente en la transcripción (no puede ejecutar comandos).

Redacta una condición que pueda finalizar, luego dale formato. Un objetivo se ajusta a un trabajo mayor que un solo turno con una línea de meta comprobable; encadena objetivos pequeños con revisiones intermedias en lugar de escribir un objetivo gigante.

Redacción

Incluye, unidos con AND — nunca "o" — el bucle tomará la rama más barata:

1. Estado final, no actividad — "todos los sitios de llamada legacyAuth() usan auth.verify()", no "migrar el código de autenticación". Una actividad puede ser afirmada; un estado final es verdadero o falso.
2. Alcance a leer primero — los archivos, issues, logs o plan a leer antes de actuar.
3. Verificación explícita — el comando exacto y su resultado observable ("npm test sale con 0"), más una instrucción para ejecutarlo y mostrar la salida; un resultado que nunca llega a la transcripción no existe para el evaluador.
4. Invariantes — lo que no debe cambiar ("sin modificar vendor/"), incluyendo siempre "no debilitar, saltar ni editar las propias verificaciones".
5. Límite de parada o cláusula de bloqueo — "o detenerse después de 20 turnos", "si está bloqueado, detenerse e informar del bloqueador". Sin una, una condición mal redactada se repite infinitamente; el formateador advierte cuando falta. (Claude Code reinicia el contador de turnos al reanudar la sesión, por lo que un límite de turnos se extiende silenciosamente entre reanudaciones.)

Mantenlo pequeño. Cada restricción reduce el espacio de estados que el modelo puede explorar. Colapsa a un solo criterio de finalización cuando sea posible, mueve el alcance y las definiciones a un archivo referenciado, y elimina los no-objetivos: una restricción gana su lugar solo si cierra una salida fácil real.

Para objetivos largos, también nombra la evidencia final (diff, informe, artefacto) y requiere un archivo de registro de progreso (estado duradero entre compactaciones y reanudaciones). Si el resumen supera los 4000 caracteres, pon los detalles en un archivo GOAL.md y referencia ese archivo desde el objetivo.

Nunca inventes elementos faltantes. Fundamenta cada elemento en la solicitud del usuario, la conversación o el repositorio — busca las cosas en lugar de adivinarlas. Si un elemento no se puede completar con la información disponible, optimiza y formatea lo que el usuario proporcionó, omite el elemento y márcalo como faltante (ver Formato). Un objetivo con una condición de éxito inventada termina en el contrato equivocado.

Cerrar las salidas fáciles

Antes de formatear, relee la condición redactada como lo haría un modelo perezoso: ¿cuál es la forma más barata de hacer que cada verificación pase sin hacer el trabajo previsto? Cierra las más baratas — prefiere emparejar verificaciones que ya tienes sobre agregar restricciones, y no enumeres todas las salidas concebibles en una lista de no-objetivos. Las salidas recurrentes:

• Borrar o hacer stub en lugar de corregir — "la búsqueda no imprime nada" también se cumple cuando los llamadores han desaparecido; empareja tales verificaciones con una que demuestre que la funcionalidad aún funciona.
• Pasar en un subconjunto — ejecutar un solo archivo de prueba, reducir la ruta de búsqueda, excluir directorios de la verificación.
• Jugar con la puerta — saltar/marcar pruebas como xfail, hardcodear salidas esperadas, especializar las entradas de prueba, editar la verificación (la regla de invariantes).
• Afirmar sin ejecutar — declarar hecho o bloqueado sin salida de verificación en la transcripción (la regla de mostrar la salida).

Misma disciplina que arriba: una salida que no puedas cerrar con la información disponible va a la lista Faltante: como advertencia — una restricción inventada o absurda es peor que una brecha marcada.

Objetivos de investigación de seguridad

Colapsa los objetivos de auditoría a un solo criterio de finalización, como identificar, desencadenar y validar una vulnerabilidad de alta gravedad válida bajo un archivo de modelo de amenazas referenciado. Ese archivo, no el objetivo, lleva el alcance, los poderes del atacante, la línea base de gravedad y los hallazgos conocidos a omitir. Usa redacción neutral ("desencadenar y validar", no "demostrar que esto es explotable"), requiere precondiciones demostradas — el acceso asumido del atacante es el falso positivo más común — y detente para revisión humana después de cada hallazgo en lugar de acumular informes no clasificados. Valida los hallazgos con una segunda pasada de un agente nuevo, nunca el descubridor solo.

Formato

Ejecuta uv run --no-project {baseDir}/scripts/format_goal_prompt.py --fenced sobre el borrador (archivo o stdin). Colapsa los espacios en blanco a una línea, elimina prefijos /goal, comillas y fences, advierte sobre una cláusula de parada faltante, y rechaza salidas de más de 4000 caracteres — acorta o mueve los detalles a un archivo y vuelve a ejecutar.

Devuelve exactamente un bloque text con fence, una línea:

/goal <objetivo normalizado único>

No agregues prosa alrededor — excepto cuando los elementos de la lista de verificación no se hayan podido fundamentar: entonces sigue el bloque con una lista Faltante:, una línea por brecha, indicando al usuario qué debe proporcionar.

Ejemplo

Borrador:

/goal Migrar el módulo de autenticación:
  - reemplazar legacyAuth() con auth.verify()
  - asegurarse de que las pruebas sigan funcionando

Redactado y formateado:

/goal Todos los sitios de llamada legacyAuth() usan auth.verify(): `rg "legacyAuth\(" -t ts` no imprime nada Y `npm test` sale con 0 (ejecutar ambos, mostrar la salida), sin modificar vendor/ ni debilitar ninguna prueba. Si está bloqueado, detenerse e informar las rutas intentadas y el bloqueador, o detenerse después de 20 turnos.

Aquí npm test provino del package.json del repositorio — no de una suposición — y emparejarlo con la verificación de cero coincidencias cierra la salida más barata: borrar los sitios de llamada en lugar de migrarlos. Cuando nada fundamenta un elemento, formatea lo que existe y marca las brechas:

Borrador: hacer el checkout más rápido, sin métrica ni benchmark en ningún lugar del contexto:

/goal Hacer el checkout más rápido

Faltante:

• estado final medible — qué métrica y umbral cuentan como "más rápido"
• verificación — el benchmark o comando que lo demuestra
• límite de parada — p.ej. "o detenerse después de 20 turnos"