What you will learn This is a chapter for doing, not reading. We hand over a first task in a safe order.
Do not let it edit files from the start. Climb through three stages.
HyperTeamsgraph TD
A["Stage 1: plan only<br/>no execution"] --> B["Stage 2: read-only work"]
B --> C["Stage 3: work that edits files"]Pick a registered working directory in the list on the far left, press New task in the sidebar, and set autonomy to plan only.
The purpose of this stage is not the output but seeing what it intends to do. If the plan is off, the instruction was insufficient — and you want to know that before execution.
If the plan looks reasonable, move to real work. Start with reading and summarising only.
The third matters. Verifying the result is how you calibrate how far to trust this tool.
Now let it actually change something. Start with something small and easy to undo.
That is the four parts of a good instruction applied directly.
Commit before you start. If you use git, undoing is easy. Keeping that safety net for the first few runs is worthwhile.
| Item | Description |
|---|---|
| Working directory | which folder to work in |
| Autonomy level | in detail in the next chapter |
| The instruction | what to do |
Work you hand over stacks up in the sidebar's Tasks section and opens as a workbench tab when you press it. The list is grouped by status — finished but unread, or waiting for an approval or reply, goes to Needs attention at the top; running work to In progress; the rest to Recent.
With several working directories you can hand a different task to each simultaneously.
They all run together and the dashboard shows each one's progress. That is why we call it a control room.
The same as what you learned in “Your first try” — keep talking.
Start with "refactor the whole codebase" and you can neither confirm what it did nor undo it. Start small and build trust is the right order.
Execute straight away and you find out "why did it touch that?" after the fact. For the first few runs, seeing the plan is much faster.
For the first few, check the result yourself. You need a feel for where it is right and where it goes wrong before you can decide how much to hand over.
1. Why start with the "plan only" stage?
To see what it intends to do before execution. If the plan is off, the instruction was insufficient — and you want to know that before any file changes.
2. Why verify the result yourself at stage 2?
To calibrate how far to trust it. Only by verifying can you judge how much to hand over.
3. What do you gain by handing tasks to several folders at once?
They run together without waiting on each other. The dashboard shows each one's progress, which is why it is called a control room.
See how tasks run internally and how results are visualized → Task Execution Principles and Dashboard Rendering
Now autonomy levels in detail → Deciding how much to hand over
Understand the structure of this project, and plan what you wouldchange to improve the README and how.Do not actually modify anything.List the files in this project that have no tests.Give me a table of the file path and a one-line description of what it does.Do not modify any files.[Goal]Bring the "Installation" section of README.md up to date.[Scope]- Modify README.md only- Do not touch other files[Done condition]- Matches the scripts currently in package.json- Commands are in a form you can copy and run directly[Context]- This project uses pnpm (not npm)shop-api → "list files with no tests"shop-frontend → "find unused components"docs-cleanup → "turn 3 meeting notes into a table"Add a "last modified" column to the table.And exclude the test files themselves from the list.