Your first task
The unit of work in W1 is an outcome, not an instruction. Here is how to state one, and what happens after you press send.
Ask for an outcome, not a step#
The single biggest difference between a good W1 session and a frustrating one is what you put in the box.
A step is "open server.ts and add a try/catch around line 40". W1 will do it, and you have spent a prompt to save yourself a keystroke. An outcome is "the server crashes when the upstream API times out — make it fail gracefully and prove it with a test". Now W1 has something to work towards, something to check itself against, and something to report honestly about.
| Instead of | Ask for |
|---|---|
| "Write a function that parses the CSV" | "Load sales-2026.csv into the report page and show the monthly totals" |
| "Explain this error" | "Find out why npm test fails on main and fix it" |
| "Make a table of these numbers" | "Compare these three quotes and tell me which is cheapest over 24 months, with the working" |
Say what "done" looks like. If a change has to keep something else working, say so — that sentence becomes the check W1 runs before it claims to be finished.
Point at real things.
File names, folder names, URLs, error text pasted verbatim. W1 can find things on its own, but a specific starting point costs one read instead of six searches — and you get the answer sooner.
What you will see while it works#
A run is a live thing, not a spinner. As it goes you will see:
- Narration — a short line saying what it is about to do and why.
- Tool steps — each read, search, edit and command, with the arguments it used and what came back.
- Approval cards — when a step needs your say-so. You can approve it once, or allow that whole class of action for the session. See Permissions and access.
- Questions — if something is genuinely ambiguous and guessing would waste the run, W1 asks rather than picking for you.
- A stop control — always. You can interrupt a run at any point.
You do not have to watch. The thread holds everything, so you can read it back afterwards in the same order it happened.
Reading the result#
When a run ends, read three things before you trust it:
- The terminal state
W1 distinguishes "I finished" from "I stopped". A run that hit a wall says so, names the wall, and does not dress it up as a summary of work completed.
- The checks
If the task involved code, W1 runs the checks that matter for it and reports what the command actually returned. A failing test is reported as a failing test. See How a run works.
- The file list
Every file the run touched is listed. If something is on that list you did not expect, that is your signal — and rewind puts it back.
Keep going in the same thread#
Follow-ups belong in the same thread. W1 carries the context of what it already read and did, so "now do the same for the other two endpoints" costs a fraction of what starting over costs — in time and in your budget.
Start a new thread when the subject genuinely changes. A thread that has drifted through four unrelated jobs carries all four in its context, and you pay for that on every turn. See Projects and threads.
A good first task#
If you want a safe one to start on, try this in a project you know:
Read this project and explain what it does, how it starts up,
and the three files I should understand first.It is read-only, it takes a minute, and it tells you a great deal about how W1 explores a codebase before you ask it to change one.