Task Prompts and Reusable Task Prompts
Qué problema resuelven
Un Task Prompt comunica un encargo concreto a un sistema AI: qué trabajo se solicita, con qué propósito y dentro de qué límites. Puede incluir contexto, restricciones y expectativas de evidencia. Esta definición de trabajo del Atlas describe una función comunicativa; no exige un archivo, una fórmula verbal ni una interfaz de producto. Un pedido escrito en chat y un formulario de tarea pueden cumplir esa función.
En desarrollo, la dificultad no consiste solamente en expresar una operación. «Arreglá el checkout» deja abiertas preguntas sobre comportamiento esperado, área afectada y autorización. El agente podría interpretar que debe cambiar una validación, ampliar tests o investigar sin editar. Un encargo más preciso reduce esa ambigüedad, aunque no garantiza que el sistema comprenda correctamente el dominio o produzca una solución aceptable.
El prompt tampoco contiene necesariamente toda la información necesaria. Puede señalar una especificación, un reporte de error o una revisión del repositorio. context-engineering-for-software-development trata cómo seleccionar y renovar esa información. El encargo inicia y orienta trabajo; la investigación puede revelar requisitos incompatibles o evidencia insuficiente. En ese caso, completar responsablemente puede requerir aclarar una decisión antes de modificar el sistema.
Goal, Scope and Success Criteria
Goal es el resultado deseado. Scope delimita qué trabajo se incluye y qué queda fuera. Success Criteria expresa condiciones o evidencia que permiten evaluar la terminación. Los tres ayudan a formular una tarea, pero cumplen funciones distintas y no necesitan convertirse en tres documentos independientes.
| Dimensión | Pregunta útil | Ejemplo en Commerce |
|---|---|---|
| Goal | ¿Qué resultado necesitamos? | Consultar el estado de un pedido autorizado. |
| Scope | ¿Dónde termina este encargo? | Agregar la consulta; conservar el contrato de cobros. |
| Success Criteria | ¿Qué permitiría revisarlo? | Comportamiento esperado y pruebas relevantes con resultados registrados. |
El goal puede permanecer estable mientras cambia el plan. La investigación podría descubrir que ya existe una consulta interna y que basta exponerla correctamente. Eso no amplía por sí solo el scope hacia rediseñar pedidos. Del mismo modo, ejecutar un comando solicitado puede ser una condición necesaria sin demostrar que el objetivo comercial se alcanzó.
Los criterios de aceptación pertenecen al trabajo de Requirements Engineering. Un Task Prompt puede referenciarlos y pedir evidencia sobre su cumplimiento; no reemplaza su significado ni redefine cómo el equipo los acepta. Cuando el prompt y un requisito durable se contradicen, la discrepancia necesita resolución autorizada. La recencia de un mensaje no prueba que exista una decisión de cambiar el producto.
Task Prompt vs Persistent Instructions
persistent-instructions conserva guía reutilizable dentro de un alcance: convenciones, restricciones y formas de trabajar. El Task Prompt solicita el trabajo actual. Ambos pueden entrar en el contexto activo y ambos pueden representarse como texto, pero su ciclo de vida y propósito son diferentes.
«Usar los tests existentes del área» puede ser guía del repositorio. «Agregar cobertura de esta regresión en Payments UI» es un encargo. Copiar todas las convenciones a cada solicitud puede introducir versiones divergentes; omitir toda referencia a restricciones particulares puede ocultar un límite decisivo. La solución depende de que el runtime cargue guía aplicable y de que el encargo haga visibles sus excepciones autorizadas.
Una instrucción persistente no se vuelve permiso técnico porque aparezca dentro del prompt. agent-permissions-and-approval-boundaries delimita autorización de acciones y decisiones adicionales. Pedir investigar un fallo de CI no implica autorizar publicar una release. Tampoco una plantilla compartida debe conceder operaciones de producción por contener una frase general como «resolver de extremo a extremo».
Task Prompt vs Specification y Plan
Una especificación describe comportamiento, restricciones o diseño esperado con una duración y estructura adecuadas al problema. El prompt pide actuar: implementar, contrastar, investigar o revisar esa descripción. Puede incluir parte de una especificación, pero no adquiere automáticamente la estabilidad, autoridad o cobertura de un contrato mantenido por el equipo.
Un plan organiza pasos de ejecución previstos. Puede elaborarlo una persona o el agente después de entender el encargo. No es el encargo mismo: una buena solicitud puede dejar abierta la secuencia de investigación. Confundir ambos lleva a evaluar obediencia a pasos incidentales en vez de comprobar el resultado, o a modificar el objetivo cuando un paso deja de ser viable.
En Commerce, pedir investigar una discrepancia de totales no obliga a introducir una librería concreta. Si el plan propone revisar conversiones, ejecutar una prueba y comparar el contrato, sus pasos pueden cambiar ante evidencia nueva. El límite «no modificar la regla de cobro» sigue vigente hasta que exista una decisión distinta. Un plan fallido no elimina esa frontera.
Reusable Task Prompts
Un Reusable Task Prompt conserva una estructura de encargo que aparece repetidamente. Puede ofrecer espacios para objetivo, revisión de código, fallo observado, restricciones y evidencia esperada. La reutilización ahorra reconstruir la comunicación; no hace idénticas las tareas ni autoriza una secuencia fija para todos los repositorios.
| Familia de encargo | Contexto que necesita cada instancia |
|---|---|
| Revisar un PR | Revisión concreta, intención del cambio y criterios de revisión. |
| Investigar CI | Ejecución fallida, etapa, logs pertinentes y alcance autorizado. |
| Actualizar una dependencia | Versión objetivo, restricciones y comprobaciones compatibles. |
| Preparar una migración | Estado actual, destino, riesgos y decisiones todavía abiertas. |
Una plantilla de revisión puede recordar que se contrasten requisitos y diff. No debería suponer que todos los PRs modifican código ejecutable o que cada hallazgo exige un test nuevo. Una plantilla de upgrade puede pedir examinar cambios incompatibles, sin prescribir un gestor de paquetes inexistente. Reusable significa adaptable a una clase de trabajo con entradas concretas, no independiente del contexto.
Los parámetros incompletos también son información. Si falta la revisión objetivo o no se conoce qué comportamiento es correcto, el agente no debería rellenar esos huecos con decisiones comerciales imaginadas. Puede avanzar en observaciones independientes y delimitar lo que sigue abierto. La plantilla ayuda cuando conserva esa incertidumbre, en vez de transformarla en un valor por defecto oculto.
Relación con Skills y Profiles
agent-skills ofrece un procedimiento o capacidad reutilizable para una clase de tareas. El Task Prompt solicita un caso concreto. Un encargo de investigar CI puede usar una skill de diagnóstico, pero la skill no contiene necesariamente el identificador de la ejecución ni decide si está autorizado editar el workflow. Tampoco todo prompt reutilizable necesita convertirse en una skill.
agent-profiles configura un especialista y sus capacidades soportadas. El perfil puede orientar cómo se investiga, pero no define por sí mismo qué incidente debe resolverse hoy. La selección de un especialista y la redacción del encargo son decisiones distintas. Un sistema puede usar el mismo perfil para varias tareas y diferentes perfiles para investigar el mismo problema bajo autorizaciones equivalentes.
Estas diferencias permiten conservar instrucciones, procedimientos y encargos sin duplicarlos. Si una solicitud repetida depende de conocimiento especializado estable, puede resultar útil extraer una skill. Si solo cambia el número del PR, una plantilla puede ser suficiente. No hay una escala de madurez que obligue a convertir cada prompt en un paquete, un especialista o una automatización.
Evidencia y expectativas de terminación
Un encargo orientado a evidencia permite distinguir intención, acción y resultado. «Implementar el endpoint y ejecutar las pruebas relevantes» expresa más que «hacer que funcione», pero todavía requiere identificar qué comportamiento cubren esas pruebas. Los resultados deben conectarse con una revisión del código y con las condiciones reales del entorno, no solamente con una afirmación de éxito.
Puede ser útil pedir que se informe qué se ejecutó, qué pasó y qué quedó sin comprobar. Si falta una dependencia del entorno, no corresponde convertir «no ejecutado» en «aprobado». Si una prueba falla por un defecto anterior, el reporte debe separar esa observación del cambio actual. development-context-and-execution-records conserva estas diferencias para revisión y continuidad.
La evidencia solicitada debe ser proporcional. Una corrección de enlace no necesita automáticamente una batería de integración; una migración de datos no queda demostrada por compilar. Sobrecargar el prompt con comandos irrelevantes puede consumir tiempo sin reducir la incertidumbre importante. El equipo sigue decidiendo qué condición de aceptación necesita y quién puede autorizar una publicación.
Failure Modes
La ambigüedad del objetivo puede producir una solución técnicamente coherente para el problema equivocado. El scope ausente facilita cambios laterales. La evidencia ausente permite una terminación imposible de revisar. Estas fallas se corrigen haciendo visibles las decisiones relevantes, sin exigir que la persona anticipe cada archivo que el agente deba leer.
Las restricciones contradictorias requieren determinar alcance y autoridad. «No agregar dependencias» y «integrar esta librería nueva» pueden ser incompatibles. Una implementación excesivamente prescrita puede impedir una solución simple cuando se descubre una capacidad existente. A su vez, una restricción técnica precisa puede ser deliberada: no corresponde descartarla por preferir otro diseño sin comprender su razón.
Los supuestos ocultos incluyen versiones, entorno, disponibilidad de credenciales y estado del repositorio. También aparece completion no verificable: «que quede profesional» sin una condición observable. Un agente puede explicar su interpretación y obtener evidencia donde sea posible; no debe presentar una preferencia propia como si fuera una condición acordada. Los prompts siguen necesitando juicio e interacción.
Formatos de producto
Los formatos siguientes fueron consultados el 2026-10-26. Son ejemplos de implementación, no un contrato de archivos del Atlas. GitHub Copilot documenta prompt files como plantillas Markdown para interacciones concretas, con variables y soporte dependiente del IDE. Su extensión y descubrimiento pertenecen a ese producto.
OpenAI documenta cómo formular encargos para Codex. Ese ejemplo ayuda a observar que contexto y comprobación pueden acompañar la solicitud; no establece un template universal. Un comando visible en un cliente también puede expandir instrucciones de una skill. La superficie de invocación no basta para decidir qué clase de artefacto hay detrás.
Relaciones y límites
repository-exploration-and-task-framing distingue la solicitud del proceso que establece su significado, alcance e incertidumbres. specification-assisted-development separa ese encargo de una referencia durable de comportamiento y del plan de ejecución. El prompt puede apuntar a ambos artefactos sin sustituirlos ni necesitar copiar todo su contenido.
coding-agent recibe encargos y puede investigar cómo realizarlos; agent-harness media contexto y ejecución. ai-assisted-software-engineering ofrece la navegación hacia instrucciones, skills y registros. Este documento mantiene Goals, Scope y Success Criteria agrupados con la solicitud de trabajo. No crea una metodología general de Prompt Engineering ni una colección de plantillas ejecutables.
Fuentes
Fuentes primarias consultadas el 2026-10-26. Definición, distinciones, ejemplos y tablas son síntesis editorial del Atlas. Los detalles de formatos pertenecen a cada implementación.