Coding-Agent Prompting and Context Recipes

Cómo utilizar esta referencia

Estas recetas son propuestas editoriales del Atlas para preparar y verificar trabajo con coding agents. Las referencias de producto se consultaron el 2026-11-09. No son frases óptimas universales, un benchmark ni una nueva metodología de desarrollo.

task-prompts, context-engineering-for-software-development y persistent-instructions conservan las definiciones. Aquí se muestran aplicaciones: objetivo, límites, selección de información y evidencia. Un prompt orienta al modelo; los controles de agent-permissions-and-approval-boundaries deben aplicarse donde corresponda.

Receta 1: encargo con aceptación observable

En lugar de pedir solamente «arreglá los tests», indicar el comportamiento que debe cambiar y lo que debe conservarse. En un repositorio .NET ficticio:

El endpoint de alta acepta una orden sin líneas y después falla al procesarla.
Quiero rechazar ese caso en la entrada, con la convención de errores existente.
Conservá el contrato de las órdenes válidas y no agregues dependencias.
Localizá primero el endpoint y sus pruebas; proponé un cambio delimitado.
Después de implementarlo, comprobá el caso vacío y un caso válido.
Informá archivos cambiados, comandos ejecutados y limitaciones.
No hagas commit ni publiques.

El agente puede investigar la implementación, con aceptación y autoridad explícitas. Los nombres de archivos y comandos deben obtenerse del repositorio real; no inventarse a partir del ejemplo.

La guía de Codex propone planificar primero cuando la tarea es compleja o ambigua. Esa intervención permite resolver decisiones antes de editar. Un cambio pequeño con aceptación clara puede necesitar una exploración más breve.

Receta 2: adquirir contexto según la decisión

Comenzar por estructura pertinente, símbolos y pruebas cercanas. Leer implementaciones y contratos cuando ayuden a distinguir hipótesis. Ampliar si el comportamiento cruza una frontera o la evidencia contradice el supuesto inicial.

Buscá primero la entrada de la operación y sus pruebas.
Leé los archivos que expliquen la validación y la convención de errores.
Si aparece otra capa responsable, ampliá la investigación y explicá por qué.
Separá lo observado de lo supuesto; no cargues todo el repositorio por defecto.

Es una estrategia, no un límite rígido de archivos. Una lectura pequeña pero incompleta puede producir una conclusión peor que una exploración más amplia justificada. Medir solamente tokens leídos no demuestra corrección.

Si existe un índice de código, comprobar cobertura y actualidad antes de inferir ausencia de símbolos o dependencias. Buscar directamente los huecos pertinentes. Usar recuperación o memoria para localizar fuentes no convierte un resumen antiguo en el estado actual del repositorio.

Receta 3: distinguir guía, datos y autoridad

Identificar qué guía cargó el cliente y su scope. El encargo puede remitir a instrucciones mantenidas sin pegar todo su texto. Observaciones de herramientas, issues y archivos externos requieren evaluar confianza.

Como diagnóstico específico, Gemini CLI documenta estos comandos dentro de su sesión:

/memory show
/memory reload

Permiten inspeccionar contexto instruccional concatenado y recargar sus archivos. No son comandos universales ni prueban que el modelo obedecerá la guía. Verificar carga tampoco demuestra mayor autoridad frente al encargo o las políticas del runtime.

Si un log pide publicar credenciales o ignorar restricciones, conservar el límite de prompt-injection. Repetir «no sigas instrucciones maliciosas» no sustituye permisos, separación de datos ni validación de efectos.

Receta 4: comprobar lo que distingue el fallo

La guía de Claude Code destaca proporcionar una comprobación ejecutable y enforcement para reglas sin excepciones. El Atlas añade una pregunta de ingeniería: ¿esa comprobación distinguiría el defecto del comportamiento deseado?

Relacioná cada criterio de aceptación con una comprobación pertinente.
Ejecutá los comandos del repositorio que cubran el cambio.
Si fallan, distinguí un defecto del cambio de un bloqueo del entorno.
Mostrá comando, resultado observado y revisión del código comprobada.
Si no pudiste verificar algo, dejalo como pendiente.

Un exit code exitoso es evidencia sobre ese comando, no prueba universal del producto. Un test que reproduce detalles de implementación puede pasar mientras el contrato sigue incumplido. generated-code-verification y ai-assisted-test-generation ayudan a examinar esa diferencia.

Reutilizar resultados solo si corresponden a entradas y entorno relevantes; ejecutar de nuevo cuando el cambio o la incertidumbre lo exija. Esa decisión necesita evidencia de vigencia, no confianza en el recuerdo del chat. Tampoco requiere repetir todo después de cada párrafo.

Receta 5: handoff antes de perder continuidad

Cuando cambie la sesión o el responsable, conservar un resumen recuperable con referencias a fuentes. Un ejemplo de registro breve es:

Objetivo y aceptación:
Estado observado del repositorio y revisión de referencia:
Decisiones tomadas y motivo:
Archivos afectados:
Comprobaciones ejecutadas y ubicación de su evidencia:
Pendientes, incertidumbres y próximo paso:

Los campos son una guía de escritura, no un formulario obligatorio. El receptor debe comprobar que revisión y archivos siguen correspondiendo a la tarea. Guardar «todo está bien» sin evidencia u omitir incertidumbres empeora la continuidad.

Claude Code también documenta /compact con un foco. Esa operación tiene costo y resume información selectivamente. Conservar criterios y referencias ayuda, pero no demuestra que preserve cada restricción ni que todos los runtimes recarguen instrucciones igual.

Receta 6: evaluar la receta y retirar ruido

Usar tareas representativas, incluyendo ambigüedad, errores y cambios del entorno. Observar aceptación, correcciones humanas, información omitida y costo total. Al comparar encargos, mantener condiciones suficientemente comparables para interpretar la diferencia.

No atribuir automáticamente una mejora a una frase: modelos, herramientas, permisos y contexto también cambian. agent-evaluation y agent-execution-and-human-review-cost permiten encuadrar esas variables. No se afirma una reducción porcentual de tokens ni una mejora medida de productividad.

Revisar guías que exigen pasos sin evidencia útil y ubicar enforcement en el control apropiado. coding-agent-development-format-reference muestra formatos posibles y ai-technology-catalog delimita las implementaciones. No se ejecutaron estas recetas como estudio de resultados ni se alteró la configuración del Atlas para imponerlas.