From an empty form to reviewed changes staged in your repo, in ten steps.

Before you start

• Pick a small first task: one change in one place, quick to build and easy to check.
• ACTower Premium, plus tmux, Claude Code and a git repo. actower doctor checks them.
• Keep your checkout tidy before step 9. Staging needs a checkout with no staged changes and no edits to tracked files. New untracked files are fine.

The short path: ask your agent

In Claude Code, run /autopilot-manager and describe the task in your own words. The agent launches it for you; nothing needs filling in. Ask for a schedule ("every Monday at 9") and it sets that up instead. The steps below are the same launch, by hand.

1. Open a new task

Go to Autopilot, then New task. You can:

• start from a template under Try a template (for example Add a /health endpoint);
• click Start task on a repo in the list;
• or start a Blank task.

2. Describe the task

• Task title (required): one line that says what you want, for example "Add rate limiting to the public API".
• Description (optional): the detail the developer agent needs. Say where, what "done" looks like, and what not to touch.
• Task file (optional): upload a markdown brief instead. It replaces the description.

3. Pick the repo and branch

Choose the Repo, then the Base branch the work starts from. Autopilot builds on a new branch in its own copy of the repo (a git worktree), so your checkout stays as it is. The copy starts from the base branch as committed: changes you haven't committed aren't in it.

4. Choose the mode

Leave Full dev for a first task: plan, develop, review, revise. The other modes are listed on the Autopilot page.

5. Choose reviewers

Repo reviewer is on by default. It runs in the worktree and reads your repo's CLAUDE.md. When the repo belongs to an ecosystem, its specialists appear here too, all ticked. Keep the ones whose area the task touches and untick the rest. Add from another hub brings in specialists from elsewhere.

Your own agent as the developer. By default the developer is plain Claude Code. To have one of your own agents build it:

• ask for it when you describe the task to /autopilot-manager;
• from the CLI, add --agent NAME to actower autopilot start;
• for a scheduled Dev task, pick it under Developer agent, which appears when you turn on Run on a schedule.

Model, hours budget and the Advanced timeouts can stay at their defaults. The hours budget covers the whole session; the developer also has a time limit of its own for building the change. If it runs out, the session ends as Timed out, and Resume picks it up (step 8). Equivalent CLI command shows the same launch as an actower autopilot start command.

6. Launch

Click Launch session. The session appears under Sessions with its phase: planning, developing, reviewing, and so on.

7. Watch it work (optional)

Click Open on the session. You get:

• Report: live events until the session ends, then the full report;
• Verdicts: each reviewer's verdict for each review cycle;
• Timeline: every event, with filters.

View live panes in Monitor shows the developer, planner, overseer and reviewers as cards. Open in terminal takes you to their panes.

8. Answer what comes to you

Safe steps inside the worktree are approved for you. Anything riskier that the overseer can't clear waits in the Responder: answer it there. By default, if nobody answers for 2 hours, the session ends as Timed out — awaiting human (Advanced changes the limit). Answer the question, then click Resume. The same goes for a session that ends TIMEOUT or STUCK: Resume picks it up where it stopped.

9. Read the report and stage

When the session is COMPLETE, open its report: what happened, what changed, and what the reviewers asked for. Then click Stage into dev; the button names your base branch. Autopilot applies the session's commits to your checkout as staged changes. It switches your checkout to the base branch first if it's on another one. If Stage stops, nothing was changed; the message says why.

10. Commit

Look over the staged changes (git diff --cached) and commit them yourself.

Want a second opinion first? Start a Review + revise task on the staged changes (the template Review my staged changes). Fresh reviewers look at them cold, and the developer fixes only what they flag. It works in your checkout, so leave those files alone until it finishes. Its fixes are staged with yours, and you commit.

When you no longer need the session's copy, Remove worktree cleans it up.