# Task brief

If you give vague instructions, you'll get vague results. Every task follows the same pattern. Copy the box, fill it in, and paste it into your agent. Or save it as a file in your project and say "Do the task in tasks/[file].md".

```
Task: [ONE SENTENCE: WHAT THIS IS]

What exists: [THE PART OF THE APP THIS TOUCHES, AND THE FILES IF YOU
KNOW THEM]

Requirements:
1. [SPECIFIC THING]
2. [SPECIFIC THING]
3. [SPECIFIC THING]

Don't change: [THE PARTS THAT MUST STAY EXACTLY AS THEY ARE]

Done when: [HOW I'LL CHECK IT, e.g. "on my phone, the list wraps and
fills the screen"]

First, read the relevant files and give me a short plan: which files
you'll change and how. Wait for me to say go. When you're done, run it,
check it against "done when", and commit.
```

## Plan first, always

Most agents have a plan mode. Where they don't, the last paragraph of the brief does the same job. When the plan comes back, check:

- [ ] It's changing the files I expected, and not a dozen others.
- [ ] It isn't adding a package I didn't ask for.
- [ ] It understood "don't change".
- [ ] It's the size of change I had in mind. If it's bigger, split the task.

## Sizing tasks

| Too big for one task | Split into |
| --- | --- |
| Add accounts | 1. Sign-up page. 2. Log in and log out. 3. Show only my own data |
| Redesign the app | 1. Colours and fonts. 2. The header. 3. The main list |
| Make it work offline | Ask for a plan only, then turn each step into its own task |

## Running several tasks at once

Once single tasks feel easy: write several briefs, then have the agent work through them one by one with a commit after each. Some agents can run tasks side by side, in separate branches or in the cloud. Only do that when the tasks touch different files, or you'll spend the time you saved sorting out clashes.

This week's tasks:

1.
2.
3.