HyperTeamsYour first task
What you will learn This is a chapter for doing, not reading. We hand over a first task in a safe order.
The safe order
Do not let it edit files from the start. Climb through three stages.
graph TD
A["Stage 1: plan only<br/>no execution"] --> B["Stage 2: read-only work"]
B --> C["Stage 3: work that edits files"]Stage 1 — ask for a plan only
From a registered working directory card, create a new task and set autonomy to plan only.
What to check
- A plan appears and no files change
- Whether it actually read the project structure to answer
- Whether the suggestions fit your situation
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.
Stage 2 — read-only work
If the plan looks reasonable, move to real work. Start with reading and summarising only.
What to check
- Whether progress appears in real time
- Whether the files it read are shown
- Whether the result matches reality (verify one or two yourself)
The third matters. Verifying the result is how you calibrate how far to trust this tool.
Stage 3 — work that edits files
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.
What to check
- Whether the files it changed are shown
- Whether you can see the changes on screen
- Whether it respected the scope (did only README change?)
Commit before you start. If you use git, undoing is easy. Keeping that safety net for the first few runs is worthwhile.
What you set when handing over a task
| Item | Description |
|---|---|
| Working directory | which folder to work in |
| Autonomy level | in detail in the next chapter |
| The instruction | what to do |
The Tasks tab. Work you hand over stacks as cards with its status.
Several at once
With several cards 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.
If you do not like the result
The same as what you learned in “Your first try” — keep talking.
Common mistakes
Starting with a big task
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.
Skipping the plan-only stage
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.
Not verifying the result
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.
Check yourself
1. Why start with the "plan only" stage?
Answer
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?
Answer
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 cards at once?
Answer
They run together without waiting on each other. The dashboard shows each one's progress, which is why it is called a control room.
Now autonomy levels in detail → Deciding how much to hand over