Tu configuración de operador

Lo que vas a poder hacer

entregable · lo que construyes

harness-record.md, archivo de instrucciones y registro de seguridad de la primera ejecución

• Elige un arnés (harness) para agentes, la aplicación en la que se ejecuta tu agente, y explica por qué lo elegiste.
• Instálalo desde su página oficial vigente y confirma qué versión tienes.
• Registra el arnés, la versión y la fecha en un archivo que conserves, para tener por dónde empezar si un paso falla el mes que viene.
• Anota dónde puede leer el agente, dónde puede escribir, qué comandos puede ejecutar y a qué puede acceder en línea.
• Escribe un archivo de reglas que el agente cargue en cada sesión, lo bastante breve para que no deje de leerlo.
• Ejecuta una tarea de solo lectura antes de que nada toque un archivo real.
• Aprueba una edición segura, rechaza una insegura y lee qué dice el registro sobre ambas.

Configura una vez y después ejecuta

Puedes instalar un agente en diez minutos y luego pelearte con él durante el resto del curso. La instalación rara vez es el problema. Lo que falla después es lo que nadie comprobó: un archivo de reglas que quizá se cargó o quizá no, una carpeta que dabas por prohibida, un comando que el agente puede ejecutar sin preguntarte antes.

Por eso este módulo construye la configuración por etapas y demuestra cada una antes de que la siguiente dependa de ella. Una configuración que nunca inspeccionaste es una configuración que no puedes depurar.

El Módulo 0 puso nombre al cambio: la unidad de trabajo pasó del turno de chat al bucle del agente. Aquí lo experimentas. El agente lee tu contexto, propone un plan, edita un archivo real y te informa mientras observas.

La herramienta deja de sentirse como un chatbot en cuanto dejas de escribir prompts y empiezas a configurar.

Idea claveTu forma habitual de trabajar pasa de «escribir en una caja de chat» a «configurar un agente y observar el bucle». El arnés cambiará mientras lo uses. La habilidad de configurar uno y demostrar a qué puede acceder antes de confiar en él permanece.

Media hora aquí facilita el Módulo 7. Si te apresuras, cargarás con un agente que no puedes explicar.

Paso uno: elige un arnés y después demuestra cuál tienes

El arnés es la aplicación en la que se ejecuta tu agente. Aloja el bucle, además de tu archivo de reglas, los controles de permisos y la memoria de la sesión.

El modelo es el motor. El arnés es el vehículo. El Módulo 3 profundiza en por qué el vehículo cambia tus resultados más que el motor.

Claude Code es el arnés de demostración aquí porque sus controles de permisos son fáciles de interpretar. Codex, Antigravity CLI y OpenCode ejecutan el mismo bucle con sus propios comandos y valores predeterminados, así que aplica estas comprobaciones al que elijas.

Dos arneses con el mismo modelo no se comportan igual. Un entorno aislado es una zona delimitada en la que se ejecuta el agente, y cada proveedor pone los límites en lugares distintos. Lee la guía vigente de primeros pasos de Claude Code o la guía de seguridad de OpenAI Codex, no un tutorial de hace seis meses, porque los valores predeterminados no dejan de cambiar.

Elige uno y úsalo durante todo el curso. Las herramientas cambian. El hábito de trabajar dentro de un arnés permanece.

La terminal es un muro para quienes no programan, y no porque les falte inteligencia. Es la ventana de texto en la que escribes comandos en lugar de hacer clic, y da por hecho que te resulta cómodo leer salidas sin procesar y trazas de errores. Esa lectura frena a la gente, no el hecho de teclear.

Prueba esto: si la terminal te pone nervioso, empieza por algo visual. Usa la aplicación de escritorio o un Cloud Shell en el navegador, donde la CLI ya está instalada y nada toca tu máquina. Pasa a la terminal directamente cuando el bucle ya te resulte cotidiano.

Detente en el peldaño más bajo que te permita terminar este módulo. La terminal es un destino, no el punto de partida.

Ahora instala. Abre el arnés, pega una línea de inicio de sesión y escribe un mensaje hasta que el agente responda. Ese es el mínimo.

Después viene el paso que casi todo el mundo se salta. Pregúntale al arnés qué versión estás ejecutando y anótala. Crea harness-record.md y añade cuatro cosas desde el primer día: el nombre del arnés, la cadena de versión que mostró, la fecha de hoy y dónde lo instalaste. Si te lo saltas, el paso que falle el mes que viene será un juego de adivinanzas, porque no podrás saber si cambió la herramienta o cambiaste tú.

Paso dos: escribe el archivo de contexto antes de escribir un prompt

Primero escribe el archivo de reglas del proyecto y después el prompt. Ese es el hábito más valioso con estos agentes.

El archivo se llama CLAUDE.md en Claude Code y AGENTS.md en Codex; otros arneses usan otros nombres. El nombre del archivo no es el contrato. El contrato son las reglas de detección del arnés, la lista documentada de dónde busca y en qué orden carga lo que encuentra. Consulta esa lista en la documentación vigente y nunca des por hecho que un mismo nombre de archivo se carga en todas partes.

Dentro va tu capa duradera, lo que es cierto en cada sesión: quién eres, en qué trabajas, cómo es un buen resultado y qué no debe hacer nunca el agente. En cada sesión nueva, el agente no sabe nada de eso. Sin el archivo, lo vuelves a escribir todo indefinidamente. Con él, lo escribes una vez y el arnés lo carga antes de tu primera palabra.

RecuerdaSé breve. Cada línea compite por la atención del agente, así que un archivo abultado entierra las reglas que te importan. Unas cuarenta líneas para el primero: un punto de partida que ajustas, no una regla dictada desde ningún sitio.

Un par de semanas después aparecen dos fallos, cuando el archivo ya se ha editado varias veces.

El primero es la contradicción. AGENTS.md dice una cosa y CLAUDE.md dice lo contrario, o una regla del principio queda anulada por otra cerca del final. Nada se queja. El agente elige un lado, el resultado se desvía y tú buscas un prompt mejor.

El segundo es ir poniendo parches al prompt. El agente hace algo mal, así que añades una línea para decirle que no lo repita, y el siguiente fallo añade otra. Así un archivo de cuarenta líneas se convierte en uno de cuatrocientas y el agente empeora en lugar de mejorar.

La solución es revisar. Una capa duradera, depurada a propósito y leída como código cada vez que la cambias. Cuando una regla deja de justificar su sitio, elimínala.

Cuánto ayuda el archivo depende de tu trabajo, así que mídelo. Ejecuta una tarea pequeña con él, repite la misma tarea sin él y compara. Eso vale más que cualquier porcentaje prometido.

Envía esto a tu agente. El prompt del generador de archivos de contexto te entrevista con un máximo de cinco preguntas y después redacta el archivo:

Entrevístame con un máximo de cinco preguntas para recoger mis reglas de trabajo duraderas:
mi rol y ámbito de trabajo, las herramientas que uso, qué considero un buen resultado, mis
preferencias de salida y qué no debes hacer nunca sin preguntar.

Después escribe un archivo de reglas de menos de 40 líneas, en cuatro secciones con título, usando solo
reglas que puedas aplicar. Sin biografía ni cosas opcionales. Muéstrame el archivo para
revisarlo antes de guardarlo en disco, e indícame qué nombre de archivo y
ubicación del arnés vas a usar y por qué.

Primero pega en esa conversación tu my-operator-profile.md del Módulo 0, para que el archivo se base en tu rol real desde la primera línea.

// O hazlo por tu cuenta

Abre un archivo nuevo llamado CLAUDE.md (o el nombre que documente tu arnés) en la carpeta del proyecto y escribe a mano cuatro secciones breves:

# Quién soy
# En qué trabajo
# Cómo quiero los resultados
# Nunca hagas esto sin preguntar

Completa cada una con reglas que un agente pueda seguir, no con notas para ti. «Sé útil» no es una regla, porque nadie podría comprobar si se incumplió. «Nunca escribas fuera de esta carpeta sin preguntar» es una regla, porque una persona ajena podría mirar el registro y decirte si se respetó.

Lee cada línea y elimina cualquier cosa que sea una preferencia en lugar de una regla. La estás revisando como código.

Paso tres: demuestra los límites antes de dejarle escribir

Comprueba cada etapa a la vista antes de que algo dependa de ella. Ese hábito distingue a los operadores de quienes tuvieron suerte una vez. Las configuraciones que funcionan continuamente se construyen en un orden: configuración básica, después memoria, luego skills y finalmente la conexión con tu aplicación de chat. Prueba cada pieza antes de instalar nada como servicio en segundo plano. Primero ejecútalo en primer plano, observando la salida, y configúralo para iniciarse solo únicamente cuando supere la prueba básica de funcionamiento. Un instalador que espera una respuesta puede quedarse detenido cuando no hay nadie para responder, y un servicio que nunca arrancó se ve exactamente igual que uno que arrancó y no hizo nada.

Una prueba básica de funcionamiento es la ejecución más pequeña que demuestra que algo está vivo. Primer plano significa que puedes ver lo que ocurre. Ambas cosas sirven para detectar una configuración que informa de éxito y no hace nada.

Las herramientas de agentes salen al mercado con ese fallo a la vista: un ajuste se lee correctamente del archivo de configuración, pero nunca se pasa a la llamada al modelo, así que las respuestas llegan cortadas sin que aparezca ningún error. El archivo se cargó y el comportamiento nunca cambió.

Idea claveUn ajuste que escribiste es una afirmación, no un hecho. La única prueba de que una configuración surtió efecto es un cambio de comportamiento que observaste.

Haz este laboratorio antes de realizar una edición real en cualquier lugar que importe.

1. Registra el modo de permisos predeterminado, es decir, cuánto hace tu arnés sin detenerse a preguntar.
2. Abre una carpeta de prueba segura. Es una carpeta desechable con archivos sin importancia, creada para practicar, que no contiene nada que echarías de menos.
3. Ejecuta una tarea de solo lectura en ella. Pide al agente que enumere los archivos y te diga para qué cree que sirve la carpeta.
4. Registra los límites del sistema de archivos. Qué carpetas puede leer y en cuáles puede escribir.
5. Registra los límites del entorno aislado y de la red. Si puede ejecutar comandos y si puede acceder a internet.
6. Identifica tus rutas protegidas y tus secretos. Los secretos son contraseñas y claves que permiten a un programa gastar dinero o publicar en tu nombre, y deben estar fuera de los archivos que entregas al agente.
7. Pide una edición inofensiva dentro de la carpeta de prueba.
8. Lee el plan y después apruébalo.
9. Pide una escritura fuera de la carpeta de prueba, en algún lugar al que no debería acceder.
10. Recházala.
11. Lee lo que te mostró el arnés en ambos casos y anótalo en tu registro de seguridad.

Los pasos del siete al diez son los que justifican este laboratorio. Aprobar te enseña muy poco. Rechazar muestra qué hace tu arnés en la compuerta: si pregunta con claridad, si nombra lo que quería tocar y si acepta un no o vuelve a preguntar de otra manera.

Guarda los ajustes y los secretos en archivos separados para poder copiar, compartir o incluir la configuración en el control de versiones sin llevarte una contraseña.

Una configuración no es segura porque te resulte familiar. Lee Seguridad de Claude Code y Seguridad de OpenAI Codex, y vuelve a hacerlo cada vez que tu arnés se actualice.

Todo lo que acabas de registrar es el perímetro dentro del que vas a trabajar.

Paso cuatro: ejecuta un ciclo de planificar, ejecutar y verificar

Ahora llega el momento en que el curso cobra vida. Una tarea real pequeña, y tú observas todo el bucle: leer tu contexto, proponer un plan, cambiar un archivo real e informar para que puedas comprobarlo.

El patrón se llama PEV: planificar, después ejecutar y después verificar. Sustituye a escribir un prompt y esperar que salga bien.

Elige algo pequeño y real. Un archivo de notas desordenado para dar formato, un lote de archivos para renombrar, una carpeta que nunca tuvo un README, una exportación de hoja de cálculo que nadie limpió. La tarea apenas importa. Buscas sentir cómo un agente cambia algo en el mundo en lugar de describirlo.

1. Planificar. Activa el modo de planificación (en Claude Code, Shift+Tab) y pide el enfoque antes de que se toque nada. Léelo. Este es el punto de control barato que detecta una mala idea antes de que cueste un archivo.
2. Ejecutar. Aprueba el plan y deja que trabaje. Observa cómo se realiza la edición.
3. Verificar. Abre el archivo tú mismo. ¿Hizo lo que decía el plan? Todo el mundo se salta este paso, y el curso vuelve a él una y otra vez, porque ahora el cuello de botella es la verificación, no la generación.

Esa ejecución es la compuerta de dominio: el agente planifica, edita un archivo y tú verificas, sin volver a pegar tu contexto a mitad del trabajo. Si te descubres explicando de nuevo quién eres durante la tarea, corrige el archivo, no el prompt.

AdvertenciaLos agentes parecen impecables en una demo limpia y tropiezan en cuanto crean archivos, ejecutan comandos y guardan trabajo de verdad. Una configuración que funcionó una vez, con una entrada limpia y mientras tú mirabas, es una puesta en escena. La prueba de las 7 de la mañana lo detecta: ¿volvería a funcionar mañana por la mañana sin que estuvieras? La confianza se rompe en los puntos de unión del acceso real a archivos, así que haz tu primer intento lo bastante pequeño como para poder equivocarte.

Paso cinco: cuatro hábitos desde hoy

Estás dejando que un programa edite tus archivos. Ese es el objetivo, y es la parte que puede hacer daño. Adopta los cuatro hábitos ahora, no después de la primera mala ejecución.

Guarda un punto de restauración antes de los cambios grandes. Guarda un punto al que volver antes de dejar suelto al agente sobre algo que te importe. Si usas control de versiones, una herramienta que conserva instantáneas a las que puedes volver, haz un commit primero. Si no, copia los archivos en un lugar seguro. La mayoría de los arneses también tienen una función de deshacer (Claude Code tiene rewind: pulsa Esc dos veces) para esa ejecución de la que te arrepientes a los tres segundos.

Limpia entre tareas no relacionadas. Termina un trabajo, empieza otro sin relación y ejecuta /clear entre ambos. El contexto sobrante es ruido para la siguiente tarea, y la calidad baja sin avisar. El Módulo 6 profundiza en el porqué.

Modo de planificación antes de cualquier acción destructiva. Cualquier refactorización, cambio masivo o tarea del tipo «borra todos los X» pasa primero por el modo de planificación. Tú lees y después apruebas. Ese hábito detecta la mayoría de los errores costosos cuando aún son frases.

Reinicia en lugar de discutir. Cuando una corrección no funciona, no la repitas tres veces más. Cada intento fallido acumula más contexto confuso sobre el que provocó el fallo. Dos intentos sobre un mismo problema son la señal para empezar de nuevo.

RecuerdaUna sesión que se cierra por un fallo no es un proyecto perdido. Quienes no programan entran en pánico cuando una terminal se cierra, porque creen que deben volver a explicarlo todo. No hace falta. La mayoría de los arneses reanudan la última sesión (Codex usa resume --last; otros tienen un comando de reanudación), y tus archivos y tu archivo de reglas siguen en el disco en cualquier caso.

Cómo es un buen resultado

Tu harness-record.md indica el arnés, la versión, la fecha, qué carpetas puede leer y escribir, qué comandos puede ejecutar, su política de red, su modo de permisos predeterminado y cómo reanudas una sesión interrumpida.

Tu registro de seguridad contiene una acción aprobada y una rechazada, con lo que te mostró el arnés en cada caso. Tu archivo de instrucciones contiene reglas, no una biografía, y cada línea es algo que una persona ajena podría comprobar.

Si tu arnés funciona de forma distinta a lo descrito aquí, sigue su documentación vigente y registra igualmente el arnés, la versión y la fecha. El registro es la parte que sobrevive a la herramienta.

El prompt: generador de archivos de contexto

El generador de archivos de contexto te entrevista con un máximo de cinco preguntas y escribe el archivo en cuatro secciones que puedes revisar como código. El prompt completo está en prompt-1-context-file.md.

Antes de pegarlo, abre tu my-operator-profile.md del Módulo 0 y entra en tu arnés con una carpeta de proyecto abierta. Cuando recibas el archivo, lee cada línea y elimina cualquier cosa que sea opcional en lugar de una regla real.

Una salvedad antes de seguir construyendo. Los modos de permisos, las reglas de aislamiento y los valores predeterminados de red no dejan de cambiar, y varían entre la aplicación, la web, la CLI y el editor del mismo proveedor. Compruébalos en tu propia instalación en lugar de confiar en cualquier explicación, incluida esta. Si algo de aquí no coincide con lo que ves: un arnés, una carpeta de proyecto, un archivo de reglas breve y tareas de solo lectura hasta que puedas decir de memoria cuáles son los límites del sistema de archivos y de la red.

Después de este módulo

De este módulo salen dos cosas que se quedan contigo.

Primero, el archivo de reglas ya está activo en tu proyecto. Es lo primero duradero que lee el agente al inicio de cada sesión, y seguirás editándolo durante el resto del curso.

Segundo, empieza lessons.md. Escribe una entrada: qué te sorprendió de la configuración. Quizá lo breve que fue la instalación, el momento en que el agente editó un archivo real o el hábito de seguridad que casi te saltaste. Ese archivo se convierte en tu registro continuo de lecciones aprendidas con esfuerzo, y añadirás entradas en casi todos los módulos a partir de aquí.

Añade una línea para ambos archivos en tu my-operator-profile.md, para saber qué tienes.

Siguiente: Módulo 2A: qué es realmente un agente.

// prompt

Archivo de contexto y laboratorio de seguridad

<task>
Entrevístame y después escribe un archivo de contexto de proyecto CLAUDE.md conciso que recoja cómo trabajo en forma de reglas duraderas. Haz un máximo de cinco preguntas, de una en una, esperando mi respuesta antes de la siguiente. No escribas el archivo hasta terminar la entrevista. Mantén el archivo final por debajo de cuarenta líneas.
</task>

<critical_rules>
- Haz UNA pregunta cada vez. Espera mi respuesta. Nunca agrupes todas las preguntas en un mensaje.
- Haz como máximo CINCO preguntas en total. Si my-operator-profile.md ya responde una pregunta, omítela e indícame que la omitiste.
- El archivo final contiene reglas que reviso como código, no prosa que leo una vez. Cada línea debe ser una instrucción que el agente pueda aplicar. Sin relleno, lenguaje motivacional ni obviedades repetidas.
- Mantén todo el archivo por debajo de 40 líneas. Si se alarga, elimina las reglas menos útiles; no reduzcas la fuente.
</critical_rules>

<about_me>
[Pega aquí tu my-operator-profile.md del Módulo 0. Si todavía no lo tienes, pega unas líneas sobre tu rol, tu ámbito de trabajo y el principal tipo de trabajo en el que quieres que te ayude el agente.]
</about_me>

<interview_instructions>
Lee primero about_me. Después hazme hasta cinco preguntas, de una en una, para recoger las reglas duraderas que se indican a continuación. Extrae directamente de about_me todo lo que puedas y omite la pregunta correspondiente.
1. Mi ámbito de trabajo y el tipo de tareas que el agente hará principalmente para mí.
2. Mis herramientas y dónde está mi trabajo (qué aplicaciones, formatos de archivo, carpetas y si uso control de versiones).
3. Mis requisitos irrenunciables: los estándares o restricciones que siempre deben respetarse.
4. Mis preferencias de salida: formato, longitud, tono y estructura que quiero por defecto.
5. Lo que el agente NUNCA debe hacer (acciones irreversibles, temas, formatos, cualquier cosa prohibida).

Después de cada respuesta, si es vaga, haz una pregunta breve de seguimiento para concretarla. «Hazlo bien» no es una regla. «Sigue la voz de my-voice.md y nunca uses rayas» es una regla. Detente a las cinco preguntas aunque quieras hacer más; podrás ajustar el archivo después.
</interview_instructions>

<output_format>
Cuando termine la entrevista, escribe el archivo en un único bloque de código delimitado que pueda copiar en CLAUDE.md, con exactamente estas cuatro secciones y nada más:

# CLAUDE.md

# Quién soy
[2-4 líneas: rol, ámbito de trabajo y lo que más necesito.]

# Cómo trabajo
[3-6 líneas: herramientas, dónde está el trabajo y el bucle que prefiero (planificar antes de ejecutar, verificar después).]

# Reglas de salida
[3-6 líneas: formato, longitud, tono y estructura predeterminados. Cada línea debe ser medible cuando sea posible.]

# Nunca hacer
[2-5 líneas: límites estrictos y acciones irreversibles que se deben evitar sin preguntar antes.]

Después del bloque de código, enumera cualquier regla sobre la que tengas dudas y pídeme que la confirme o elimine. No rellenes el archivo para que parezca completo.
</output_format>

<reminders>
- Una pregunta cada vez. Máximo cinco preguntas. Espera cada respuesta.
- Archivo final de menos de 40 líneas, solo cuatro secciones, cada línea una regla aplicable.
- Esto es código que revisaré y depuraré, no prosa. Mejor conciso que exhaustivo.
</reminders>

Usa la documentación vigente del 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, la 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>
Entrevístame y escribe un archivo breve de instrucciones para el arnés que elegí. Después genera una lista de comprobación de seguridad para la primera ejecución. No realices ninguna edición real.
</task>

<about_me>
[Pega aquí my-operator-profile.md.]
</about_me>

<harness>
Arnés: [nombre]
Versión: [versión]
Fecha de comprobación: [YYYY-MM-DD]
Enlace oficial de instalación o seguridad: [URL]
</harness>

<rules>
Haz como máximo cinco preguntas, de una en una.
Usa las reglas vigentes de detección del arnés.
No des por hecho que CLAUDE.md o AGENTS.md se carga en otro arnés.
No inventes comandos ni controles equivalentes.
Mantén el archivo de instrucciones por debajo de 40 líneas.
Incluye las rutas protegidas, los secretos, las necesidades de aprobación y las acciones prohibidas.
</rules>

<output_format>
Devuelve cuatro secciones:

1. Archivo de instrucciones, listo para copiar.
2. Registro del arnés con campos de sistema de archivos, comandos, entorno aislado, red, MCP y reanudación.
3. Laboratorio de seguridad con una tarea de solo lectura, una edición segura aprobada y una acción insegura rechazada.
4. Lista de comprobación de verificación.
</output_format>

Con fecha de referencia del 15 ago 2026, lee Seguridad de Claude Code y Seguridad de OpenAI Codex.

Si tu arnés es diferente, sigue su documentación vigente. Registra el arnés, la versión y la fecha.

compuerta de dominio

• ▸Registré el arnés, la versión y la fecha
• ▸Completé una tarea de solo lectura
• ▸Aprobé una edición segura
• ▸Rechacé una acción insegura
• ▸Puedo indicar los límites del sistema de archivos y de la red