Tu primer objetivo

Arma el equipo, envía un mensaje y deja que la ejecución tome el relevo. Qué pregunta AutoDev primero, qué escribe en .autodev/ y por qué cerrar el editor no lo detiene.

El tour #

La primera vez que se abre el panel, un tour de nueve pasos lo recorre: el compositor, el hilo, los controles de la ejecución, tus participantes y la lane de un participante, Needs you, el informe, Memory y el check-in desde el teléfono. Cada paso señala la parte del panel que describe, y dibuja un ejemplo ahí cuando el proyecto aún no tiene nada propio que mostrar.

Next, Back y Skip the tour recorren el tour, y también las flechas del teclado y Escape. Para verlo de nuevo, ejecuta AutoDev: Show the tour en la paleta de comandos, o pulsa Show the tour en la pantalla Config.

Arma el equipo #

AutoDev no tiene un equipo implícito. Un proyecto sin equipo se abre en la configuración del equipo en el panel, y hasta que exista un equipo el compositor queda desactivado y dice Set up your team to start. Un equipo es un archivo por participante en .autodev/participants/, cada uno con un proveedor, un modelo y un esfuerzo.

Hay tres caminos hasta un equipo:

• Arrastra una CLI de la fila de proveedores a la cuadrícula. Una CLI basta: es una conversación que sobrevive a límites y reinicios, y dos o más conversan entre sí.
• Elige una plantilla: solo, builder-reviewer o manager-builder-reviewer. El panel muestra una vista previa de las instrucciones de cada participante y te deja elegir su CLI. El formato del archivo de participante dice qué escribe cada plantilla, y autodev team template <name> hace lo mismo desde una terminal.
• Empieza con tu equipo predeterminado, que se copia al proyecto.

El panel primero comprueba tus CLI de agente y muestra solo lo que sabe. Dice claude is not installed cuando falta una CLI, y claude is installed but not logged in cuando sabe que no has iniciado sesión. Requisitos explica ambos.

Armar el equipo también es la forma de darle a AutoDev permiso para trabajar en la carpeta. Un equipo que llegó con el proyecto no se ejecuta cuando lo abres: los archivos de participante se convierten en banderas y prompts de una CLI, así que el panel dice This project came with a team, y Use this team lo confirma en esta máquina.

Envía un mensaje #

Di lo que quieres que se construya. Desde el panel, lo escribes en el compositor. Desde una terminal, ejecutas esto:

autodev send "<message>"

El primer mensaje es el objetivo, y cada uno posterior orienta la ejecución. AutoDev añade cada mensaje a .autodev/goal.md, el más nuevo al final, bajo un encabezado con la hora. El archivo es tuyo para editarlo. Un mensaje no necesita un comando de equipo ni un modo: es una publicación en el hilo, y el participante que la lee decide qué significa.

Un mensaje inicia una ejecución cuando ningún daemon está vivo y el equipo está listo: existe un equipo, y esta máquina lo confirmó. Cuando hay una ejecución viva, el mensaje queda en cola para su siguiente turno, y el compositor dice Drained at the next turn boundary — never mid-turn. Todos los comandos de la CLI describe autodev send, su --image y su --no-start.

Qué pasa después #

Los participantes se turnan en el hilo compartido, y el primero en hablar lee el objetivo. Toda ejecución empieza con un goal.md y un memory.md, el archivo donde el equipo guarda lo que aprendió, para que un turno futuro no pague por aprenderlo de nuevo. El hilo compartido describe un turno.

Los archivos que una persona lee viven en .autodev/, en tu repositorio. Lo que solo lee la máquina vive en ~/.autodev/<project>-<hash>/.

.autodev/
  goal.md  memory.md  config.json
  participants/

Para empezar un objetivo distinto desde cero, ejecuta autodev new-run. Archiva la ejecución terminada y vacía goal.md y memory.md, y Todos los comandos de la CLI dice qué conserva.

Acciones irreversibles #

Un participante que está a punto de hacer algo que no se puede deshacer, como un git push, una publicación, un deploy o un cambio en la base de datos, declara antes un gate. Por defecto AutoDev aprueba los gates que se le muestran: la clave de configuración gateMode vale auto. Ponla en gated en la pantalla Config y cada gate detiene la ejecución hasta que respondas. Entonces espera en Needs you, con Approve y Deny, o con autodev approve y autodev deny.

AutoDev no pregunta esto en el primer uso. Los patrones que siempre aprueban o siempre niegan son gateAutoApprove y gateAutoDeny, y Todas las claves de configuración trata de las tres.

Déjalo en marcha #

El daemon está desacoplado. Cerrar la terminal o el editor no lo detiene. Tras una caída un supervisor inicia el daemon de nuevo, y tras un reinicio del equipo nada arranca solo hasta que lo inicies. El panel solo observa el daemon. Qué sobrevive a un reinicio dice qué se conserva y qué vuelve a iniciar la ejecución.

La barra de estado de VS Code mantiene una línea, AutoDev: <status>, con · <n> needs you después cuando algo te espera. Esa línea sigue visible cuando la pestaña de AutoDev está cerrada. Para enterarte también en el teléfono, define notify.url, y para dejar que la máquina duerma cuando la ejecución acabe, activa suspendOnCompletion. Todas las claves de configuración trata de ambas.

A continuación, Cómo es una ejecución.