Lo que vas a poder hacer
entregable · lo que construyes
Un flujo de trabajo guardado y un registro de reanudación de sesión
- Nombra las seis cosas que te da un arnés y di qué falla cuando falta cada una.
- Convierte un prompt que vuelves a escribir en un flujo de trabajo que ejecutas por su nombre.
- Encuentra los controles de planificación, aprobación, registro y reanudación del arnés que usas.
- Ejecuta la misma tarea con dos configuraciones de arnés y registra cuál dio el mejor resultado.
- Distingue una función duradera del botón que casualmente la activa este mes.
Piezas duraderas
Algunas personas vuelven a elegir modelo cada vez que uno nuevo encabeza una clasificación y pasan la semana leyendo comparaciones en lugar de trabajar. Mientras tanto, una persona con un archivo de reglas, cuatro comandos guardados y el hábito de reanudar sesiones entrega más que ellas.
El mismo modelo en ambos lados. Lo que las separó fue el programa en el que trabajan y lo que habían configurado en él.
Ese programa es el arnés (harness), la aplicación en la que se ejecuta tu agente. Aloja el bucle del agente del Módulo 2A, delega trabajo a subagentes y te da las seis cosas siguientes. Claude Code es un arnés. Codex es un arnés. Antigravity CLI es un arnés, y Gemini CLI sigue funcionando para usuarios empresariales y de API de pago.
El modelo predice texto. El arnés es todo lo que construiste a su alrededor, y es la parte que conservas cuando sustituyes el modelo que hay debajo. Puede darte seis cosas:
| La pieza | Qué te da | Qué falla sin ella |
|---|---|---|
| Un archivo de reglas o contexto | Un archivo que lee al arrancar, para que el agente ya sepa quién eres y cómo trabajas | Vuelves a explicarte en cada sesión y el agente rellena los huecos con suposiciones |
| Acceso a archivos y herramientas | Los archivos que puede leer y cambiar, y las herramientas que puede invocar | O no puede acceder al trabajo en absoluto o accede a mucho más de lo que pretendías |
| Controles de planificación y aprobación | Una parada antes de actuar, en la que dices sí, no o así no | La primera vez que te interpreta mal, ya hay diez archivos cambiados |
| Flujos de trabajo guardados | Un prompt escrito una vez, guardado con un nombre y ejecutado por ese nombre desde entonces | Vuelves a escribir la misma preparación cada semana y sale distinta cada vez |
| Estado de la sesión | Volver a abrir la conversación en la que estabas, con el contexto intacto | Una ventana cerrada significa empezar la explicación desde cero |
| Registros e informes | Un registro de lo que realmente hizo, que puedes leer después | Sabes que algo salió mal, pero nunca en qué paso |
Los nombres y las ubicaciones varían según el arnés. Las funciones, no.
La configuración puede cambiar mucho los resultados, y por eso existe este módulo. No significa que el arnés siempre importe más que el modelo; encontrarás tareas en las que solo un modelo diferente cambie el resultado. La afirmación más acotada se sostiene: dos configuraciones del mismo modelo son dos sistemas distintos, y nunca has medido el tuyo.
Así que mídelo. Ejecuta dos veces una tarea que realmente hagas, en dos arneses o en uno con dos configuraciones de permisos y herramientas, y anota qué cambió. Ese registro vale más que cualquier comparación publicada por otra persona.
Ejemplos de proveedores
Estos comandos proceden de dos arneses concretos y se quedan desactualizados. Consulta qué hace hoy tu arnés en Uso de la CLI de Claude Code o en OpenAI Developers.
| Función duradera | Qué hace por ti | Un ejemplo actual | Cómo encontrarla en tu arnés |
|---|---|---|---|
| Activar un plan antes de actuar | El agente propone, tú apruebas o corriges y después ejecuta | Shift+Tab en Claude Code o Codex |
Busca en la documentación de tu arnés el modo de planificación o de aprobación |
| Limpiar el contexto entre trabajos | La tarea anterior deja de competir con la nueva | /clear |
Busca las opciones de limpiar, reiniciar o crear una sesión nueva |
| Reanudar la última sesión | La conversación y su contexto vuelven después de un cierre o un fallo | resume --last |
Busca las opciones de reanudar, continuar o consultar el historial de sesiones |
Deja los comandos de cada proveedor fuera de tu compuerta de dominio. «Puedo encontrar y usar el control de planificación del arnés que uso» sigue siendo válido aunque cambie la combinación de teclas. «Sé que se hace con Shift+Tab» caduca la próxima vez que alguien cambie un atajo.
Laboratorio de flujos de trabajo guardados
Este es el entregable del módulo: un prompt que vuelves a escribir, convertido en un archivo que el arnés carga por su nombre. Tu agente puede hacerlo. Abre prompt-3-slash-workflow.md, pega un prompt que hayas escrito más de dos veces y deja que lo generalice, dé nombre al comando y te indique la ruta donde guardarlo.
// O hazlo por tu cuenta
- Elige un prompt que repitas.
- Marca los campos que cambian en cada ejecución.
- Sustituye esos campos por marcadores con nombre entre corchetes.
- Añade las entradas esperadas, el formato de salida que quieres y una comprobación de finalización que indique cómo sabrías que la ejecución tuvo éxito.
- Guárdalo donde la documentación de tu arnés indique que van los flujos de trabajo guardados.
- Reinicia el arnés y ejecútalo por su nombre con un caso de prueba, es decir, una entrada ficticia pequeña que controles en lugar de trabajo real.
- Registra la ruta del archivo, la invocación y la salida.
El paso cuatro es el que la gente se salta y el que hace que valga la pena guardar el archivo. Un prompt sin comprobación de finalización devuelve algo. Un prompt con ella te dice si ese algo sirve.
Laboratorio de reanudación
- Empieza una tarea pequeña y deja que el agente avance parte del trabajo.
- Detén la sesión a propósito, como ocurriría con un fallo.
- Usa el procedimiento de reanudación documentado de tu arnés para recuperarla.
- Si tu arnés no tiene reanudación, reconstruye la sesión a partir del plan guardado y del archivo de progreso.
- Registra qué estado sobrevivió y cuál no.
El paso cinco es el objetivo. Reanudar rara vez recupera todo. La mayoría de los arneses devuelven la conversación y su contexto. Casi ninguno devuelve una edición a medio hacer que nunca llegó al disco ni un comando que murió con la ventana. Saber dónde está ese límite evita que confíes a la reanudación trabajo que no puede conservar.
Eso convierte el paso cuatro en una habilidad. Escribe el plan y el progreso en un archivo a medida que avanzas y la sesión será reemplazable. Guárdalos solo en la conversación y una ventana cerrada será un proyecto perdido.
Sin exigir una flota de agentes
No esperes que un principiante supervise varios agentes desde una pantalla.
Dirigir bien un agente es una habilidad relacionada con el trabajo. Dirigir varios es una habilidad relacionada con tu atención: saber cuál está bloqueado esperando por ti y cuál se desvió mientras leías otra ventana. Si añades la segunda demasiado pronto a la primera, tendrás cuatro ejecuciones confusas en lugar de una buena. El Módulo 11 lo trata como opción. Consigue primero un agente, un flujo de trabajo guardado y una sesión recuperada.
Nota final sobre el arnés
Si tu arnés es diferente, sigue su documentación vigente. Registra el arnés, su versión y la fecha en tu entregable.
Explicación en profundidad
El Módulo 2A te enseñó que el agente es un bucle. Esto trata de aquello en lo que vive el bucle y del hecho de que puedes programarlo.
Qué hay realmente dentro
Tres de las seis piezas merecen una mirada más cercana de la que les dio la tabla.
- El bucle. Leer contexto, planificar, actuar sobre archivos y comandos, verificar e informar. El arnés lo ejecuta.
- Tu archivo de reglas. El CLAUDE.md o AGENTS.md que lee al arrancar. Cada línea es una suposición que el agente ya no tiene que hacer. Construirás el tuyo más adelante en el curso. Se carga sin esfuerzo en cada sesión, sea bueno o malo.
- Subagentes. Trabajadores que envías a hacer una tarea que genera mucho contexto, como una búsqueda amplia o una revisión independiente, en su propia ventana de contexto. Devuelven el resultado sin todo el ruido.
Modo de planificación más comandos guardados más reanudación de sesiones: esa es la diferencia entre usar una herramienta de línea de comandos y trabajar habitualmente en ella.
Los operadores más avanzados ejecutan procedimientos escritos y largas listas de comandos en dos arneses a la vez, enviando cada tarea al que mejor la resuelve. No construirás eso este mes, pero conocer el techo fija las expectativas. Quienes van por delante programan su arnés en lugar de buscar uno mejor.
La configuración es lo que conservas
Cuando alguien pregunta «qué IA debería usar», se refiere a qué modelo. Poco recorrido, poco beneficio.
El modelo suele ser una pieza intercambiable. No siempre. Tu ruta, tus permisos y las herramientas que admite el arnés limitan lo que puede arreglar un cambio, y ningún cambio repara una herramienta que el arnés no puede invocar. Aun así, de las piezas que tocas a diario, es la que cambia con menos esfuerzo.
Idea clave: estás eligiendo una base de operaciones y amueblándola, y los muebles son lo que conservas. Dos personas que mantienen abiertos un arnés de Claude y otro de Codex a la vez, enviando cada tarea al que mejor la resuelve, no están siendo indecisas. Están tratando el modelo como un consumible y la configuración como el activo.
Así nunca tienes por qué sentirte rezagado cuando sale un modelo nuevo. Lo que deja la verdadera pregunta: qué significa «configurarlo bien». Casi nunca es un panel de ajustes.
El verdadero activo es el contexto que escribiste
Desmonta una base de operaciones bien gestionada y aparecerá la misma estructura en casi todos los ámbitos donde se usan agentes.
El agente investiga, extrae, redacta, puntúa y da formato. Todo a partir de archivos que tú escribiste: una guía de voz, una descripción del cliente al que vendes, un archivo de reglas, una lista de lo que contiene un buen resultado, una lista de problemas conocidos y un procedimiento guardado. Tú te encargas de las decisiones, el criterio y la compuerta para cualquier cosa que se publique, se envíe o implique gasto. Esos archivos son el activo, no el prompt que escribiste ni el modelo que lo respondió.
Tres ejemplos. Un equipo de contenido reconstruye su proceso de actualización con skills guardadas, porque el paso de redacción necesita tener abiertos a la vez el artículo actual, la investigación, la guía de estilo y los borradores anteriores. Cada paso guarda un archivo y el equipo conserva todas las decisiones editoriales. Un editor de boletines construye lo mismo con siete archivos escritos: bibliotecas de prompts, comprobaciones, una guía de estilo, una taxonomía y un registro de problemas conocidos. Después, una breve revisión humana antes de publicar nada. Una comprobación de voz lee la guía antes que el borrador, cita el texto problemático en lugar de reescribirlo y devuelve aprobado, en espera o rechazado.
Contexto escrito al principio, generación en medio y un lugar donde el trabajo se detiene. Esa última parte es la que omiten los principiantes. Un sistema que solo puede generar no puede decir «no pude hacer esto correctamente». Responde con seguridad en lugar de negarse. Por eso los sistemas que se sostienen tienen una vía de rechazo: un estado de espera, una bandeja de revisión, una omisión o una salida que indica qué comprobación falló.
Un matiz, porque esa división del trabajo es una regla por defecto, no una ley. Ya se están desplegando agentes autónomos autorizados. Algunas plataformas publicitarias permiten a un agente responder a clientes o cambiar pujas sin intervención humana en cada ocasión, de forma deliberada y con permiso concedido de antemano. Así que la regla trata del riesgo, no de ideología. La compuerta humana es obligatoria cuando una acción es costosa o irreversible, y se ajusta al daño que puede causar.
Y la compuerta debe estar en un lugar real. Que un modelo diga que preguntará antes de enviar no es una compuerta. Una compuerta es un flujo de trabajo que se niega a avanzar hasta que haya una aprobación en los registros del propio sistema, comprobada por código que se detiene en lugar de adivinar cuando hay dudas. Esa es la diferencia entre un sistema que puedes dejar funcionando y una demo que observas.
Cada archivo nombrado aquí es uno que alguien se sentó a escribir, y el arnés los carga por ti en cada sesión sin que se lo pidas. Eso es lo que significa base de operaciones.
Cuatro hábitos que hacen que valga la pena trabajar en él
La ventana de chat parecía más fácil porque bastaba con escribir. El arnés empieza a compensar cuando adoptas cuatro hábitos.
1. Modo de planificación antes de cualquier acción destructiva. Lee el plan antes de que edite, elimine o reescriba, y después apruébalo o corrígelo. Cuesta segundos. Te evita ver cómo el agente hace correctamente lo equivocado en todos los archivos a la vez.
2. Limpia el contexto entre trabajos no relacionados. El trabajo antiguo que queda en la sesión es ruido al que el agente sigue volviendo. Un comando deja todo limpio.
3. Convierte los prompts repetidos en flujos de trabajo guardados. Un prompt que vuelves a escribir con pequeños cambios está esperando a que lo guardes. Es el que más rinde por minuto de los cuatro, y tu entregable de hoy.
4. Reanuda una sesión interrumpida en lugar de empezar de nuevo. Lo que más temen quienes no programan es tener que empezar otra vez, y normalmente no hace falta. Aprende el procedimiento una vez con una sesión que no te importe y el miedo desaparece.
Aplico los cuatro cada día. No por disciplina. Cada uno elimina una forma concreta en la que antes perdía una tarde.
El muro que frena a quienes no programan
Advertencia: el mayor muro para quienes no programan no son esos cuatro hábitos. Es leer la salida del intérprete de comandos y las trazas de errores. La terminal da por hecho que te sientes cómodo leyendo lo que pasa por la pantalla y no explica nada. Si es tu caso, empieza por un entorno visual: una aplicación de escritorio o una terminal en la nube donde el arnés ya esté instalado e inicies sesión desde un navegador. Pasa a la terminal cuando el bucle te resulte familiar. Es algo a lo que llegas con la práctica, no por donde empiezas.
Varios agentes, una pantalla
Ninguna función anterior justifica por sí sola la curva de aprendizaje. Lo que suman entre todas, sí.
Ejecutar varios agentes a la vez se adueñó de mis días. Uno investigando, otro escribiendo y otro detenido por un fallo en una esquina, esperando a que me diera cuenta. Entre un montón de pestañas de terminal es insoportable, porque averiguar qué agente te necesita cuesta más que el propio trabajo. Las vistas de flota en una sola pantalla lo reúnen en una ventana con una cola de lo que espera por ti, y los operadores de contenido ganan tanto como los ingenieros, porque el cuello de botella que eliminan es la atención, no el código.
Esa es la razón honesta para avanzar hacia la línea de comandos. Dejas de gestionar una conversación y empiezas a supervisar un equipo pequeño.
La ventana de chat no puede hacer eso. Un hilo, una tarea, una cosa a la vez.
Prueba esto: antes de construir tu flujo de trabajo guardado, cuenta cuántas veces esta semana abriste un chat nuevo y volviste a escribir la misma preparación. Esa cifra es tu impuesto semanal. El flujo de trabajo que construyes a continuación te lo devuelve.
El prompt: generador de flujos de trabajo con comandos de barra
Trae un prompt real que repitas, como «escribe una actualización semanal a partir de estas notas» o «convierte esta transcripción en un esquema». Nada hipotético, porque el paso de generalización necesita variaciones reales para encontrar los campos que cambian.
Pégalo en el marcador de prompt-3-slash-workflow.md y ejecútalo. Obtendrás un archivo de comando con marcadores entre corchetes, una descripción de una línea y la ruta exacta donde guardarlo.
Después de este módulo
Crea my-stack.md en tu sistema de memoria. Anota el arnés que elegiste, una línea honesta sobre el motivo y el nombre y propósito del flujo de trabajo que acabas de guardar.
Añade una línea en tu índice MEMORY.md que apunte a él, como my-stack.md para saber qué arnés uso y qué flujos de trabajo tengo guardados. Lo ampliarás cada vez que construyas una skill, un subagente o un hook más adelante en el curso. Es tu primer archivo de contexto escrito, así que es la primera pieza del activo.
Después confirma la compuerta. Ejecutaste tu comando guardado por su nombre y recuperaste una sesión tras cerrarla. Si cualquiera de las dos cosas te resultó insegura, repítela ahora, cuando solo están en juego archivos de prueba. Las sesiones son largas en los módulos de pago, y empezar de nuevo cuesta una tarde.
Siguiente: Módulo 4: la mecánica de los modelos, en su justa medida.
// prompt
Laboratorio de flujos de trabajo guardados
<task>
Convierte un prompt que vuelvo a escribir a menudo en un comando de barra guardado y reutilizable para mi arnés. No te limites a pulir mi prompt: generalízalo para que el mismo comando funcione siempre e indícame exactamente dónde guardar el archivo para que mi arnés lo cargue automáticamente.
</task>
<repeated_prompt>
[Pega el prompt completo que escribes a menudo, exactamente como sueles escribirlo. Incluye cualquier contexto de ejemplo que pegues normalmente, para poder ver qué partes son estructura reutilizable y cuáles cambian cada vez.]
</repeated_prompt>
<my_harness>
[Nombra el arnés en el que trabajas habitualmente, por ejemplo, Claude Code, Codex o Antigravity CLI. Si no lo sabes, di «no estoy seguro» y te daré las dos ubicaciones de guardado más habituales.]
</my_harness>
<instructions>
1. Lee mi prompt repetido e identifica las partes que permanecen iguales siempre (las instrucciones reutilizables) y las que cambian cada vez (las entradas).
2. Sustituye cada parte variable por un [marcador entre corchetes] con un nombre claro, por ejemplo, [transcripción], [tema], [audiencia]. Usa pocos marcadores y que sean evidentes.
3. Convierte las instrucciones reutilizables en pasos en imperativo. Elimina el relleno. No añadas personajes de adorno ni fórmulas como «eres un experto». Cada línea debe justificar su lugar.
4. Dale al comando un nombre breve y fácil de recordar en kebab-case (por ejemplo, weekly-update, outline-from-transcript) y escribe una descripción de una línea de lo que hace.
5. Devuelve el comando como un archivo completo de comando de barra: la descripción de una línea arriba y después el cuerpo del prompt generalizado con marcadores.
6. Indícame la ruta y el nombre de archivo exactos para guardarlo en el arnés que indiqué, de modo que se cargue automáticamente como comando de barra en la siguiente sesión. Si indiqué «no estoy seguro», da las dos ubicaciones más habituales y cómo saber cuál corresponde.
7. Termina con una instrucción de prueba: una invocación de ejemplo que muestre cómo llamaría al comando por su nombre y qué pondría en cada marcador.
</instructions>
<output_format>
Devuelve exactamente estas cuatro secciones, en orden, con estos títulos:
# Nombre del comando
[el nombre en kebab-case y la descripción de una línea]
# Archivo del comando de barra
[un único bloque de código delimitado con el contenido completo del archivo que debo guardar]
# Dónde guardarlo
[la ruta y el nombre de archivo exactos para mi arnés y una línea sobre cómo confirmar que se cargó]
# Pruébalo
[una invocación de ejemplo por nombre con cada marcador completado, para poder ejecutarlo de inmediato]
</output_format>
<rules>
Generaliza, no te limites a dar formato: si la salida solo funciona para mi ejemplo, has fallado. No uses más marcadores de los necesarios. No uses rayas en ninguna parte de la salida. Si mi prompt repetido es demasiado específico para generalizarlo bien, dilo e indícame qué falta en lugar de inventar una estructura.
</rules>Usa la documentación vigente de tu arnés para la detección de archivos, los permisos, la invocación, el acceso a herramientas y el comportamiento de aprobación. Registra el arnés, su versión, la fecha y el evento o comando exacto que probaste. Un ejemplo de un proveedor no es un contrato universal. No envíes, gastes, elimines, publiques ni cambies producción durante este laboratorio, salvo que la compuerta del módulo indique explícitamente que una persona debe aprobar una acción reversible sobre los archivos de prueba.
<task>
Convierte una tarea repetida en un flujo de trabajo guardado para el arnés que elegí. Después crea un registro de reanudación. No lo ejecutes sobre datos de producción.
</task>
<harness>
Nombre: [arnés]
Versión: [versión]
Documentación: [enlaces vigentes sobre flujos de trabajo, aprobación, registros y reanudación]
</harness>
<task_input>
[Pega el prompt repetido y describe el caso de prueba.]
</task_input>
<instructions>
Extrae los campos variables y sustitúyelos por marcadores.
Añade un contrato claro de entrada y de salida, un punto de aprobación y una comprobación de finalización.
Usa la ruta documentada de tu arnés.
Identifica cada comando específico del arnés.
No uses un único comando de un proveedor como condición para aprobar.
Indica qué hacer si no está disponible la reanudación.
</instructions>
<output_format>
Devuelve:
1. Texto del flujo de trabajo guardado.
2. Archivo o ubicación esperados.
3. Prueba con datos de prueba.
4. Pasos de reanudación o reconstrucción.
5. Evidencias y límites conocidos.
</output_format>Si tu arnés es diferente, sigue su documentación vigente. Registra el arnés, su versión y la fecha.
compuerta de dominio
- ▸Guardé un flujo de trabajo repetible
- ▸Reanudé o reconstruí una sesión siguiendo la documentación de mi arnés
- ▸Puedo mostrar aprobaciones y registros