Your first objective

Set up the team, send one message, and let the run take over. What AutoDev asks first, what it writes to .autodev/, and why closing the editor does not stop it.

The tour #

The first time the panel opens, a tour of nine steps walks through it: the composer, the thread, the run controls, your participants and a participant's lane, Needs you, the report, Memory, and check-in from a phone. Each step points at the part of the panel it describes, and draws an example there when the project has nothing of its own to show yet.

Next, Back and Skip the tour move through it, and so do the arrow keys and Escape. To see it again, run AutoDev: Show the tour from the command palette, or press Show the tour on the Config screen.

Set up the team #

AutoDev has no implicit team. A project with no team opens on team setup in the panel, and until a team exists the composer is disabled and says Set up your team to start. A team is one file per participant under .autodev/participants/, each with a provider, a model and an effort.

There are three ways to a team:

• Drag a CLI from the row of providers into the grid. One CLI is enough: it is a conversation that survives limits and restarts, and two or more talk to each other.
• Pick a template: solo, builder-reviewer or manager-builder-reviewer. The panel previews each participant's instructions and lets you choose its CLI. The participant file format says what each template writes, and autodev team template <name> does the same from a terminal.
• Start with your default team, which is copied into the project.

The panel first checks your agent CLIs and shows only what it knows. It says claude is not installed when a CLI is missing, and claude is installed but not logged in when it knows you are signed out. Requirements explains both.

Setting up the team is also how you grant AutoDev permission to work in the folder. A team that arrived with the project does not run when you open it: participant files become CLI flags and prompts, so the panel says This project came with a team, and Use this team confirms it on this machine.

Send one message #

Say what you want built. From the panel, you type it in the composer. From a terminal, you run this:

autodev send "<message>"

The first message is the objective, and every later one steers the run. AutoDev appends each message to .autodev/goal.md, newest last, under a heading with the time. The file is yours to edit. A message needs no team command and no mode: it is a post on the thread, and the participant that reads it decides what it means.

A message starts a run when no daemon is alive and the team is ready: a team exists, and this machine has confirmed it. When a run is alive, the message is queued for its next turn, and the composer says Drained at the next turn boundary — never mid-turn. Every CLI command describes autodev send, its --image and its --no-start.

What happens next #

The participants take turns on the shared thread, and the first to speak reads the objective. Every run starts with a goal.md and a memory.md, the file where the team keeps what it learned, so a later turn does not pay to learn it again. The shared thread describes a turn.

The files a person reads live in .autodev/, in your repository. What only the machine reads lives under ~/.autodev/<project>-<hash>/.

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

To start a different objective from scratch, run autodev new-run. It archives the finished run and empties goal.md and memory.md, and Every CLI command says what it keeps.

Irreversible actions #

A participant that is about to do something it cannot take back, such as a git push, a publish, a deploy or a database change, declares a gate first. By default AutoDev approves the gates it is shown: the config key gateMode is auto. Set it to gated in the Config screen and every gate stops the run until you answer. It then waits in Needs you, with Approve and Deny, or with autodev approve and autodev deny.

AutoDev does not ask this on the first use. The patterns that always approve or always deny are gateAutoApprove and gateAutoDeny, and Every config key covers all three.

Leave it running #

The daemon is detached. Closing the terminal or the editor does not stop it. After a crash a supervisor starts the daemon again, and after a reboot nothing starts by itself until you start it. The panel only watches the daemon. What survives a restart says what is kept and what starts the run again.

The VS Code status bar keeps one line, AutoDev: <status>, with · <n> needs you after it when something waits on you. That line stays visible when the AutoDev tab is closed. To hear about it on a phone as well, set notify.url, and to let the machine sleep once the run is over, turn on suspendOnCompletion. Every config key covers both.

Next, What a run looks like.