Writing a task

The main job of a task is removing ambiguity. An agent can carry a task to the end when what "done" means is unambiguous. When it isn't, the agent guesses, and you spend the review discovering it guessed wrong.

This page is about writing the task so that doesn't happen.

What a good task carries

The outcome, not the implementation. "Product images on the PLP load slowly on mobile" beats "add loading=lazy to the PLP grid." You know the symptom; the agent is better placed to choose the fix, and will explain what it picked.

Where to look. The page, the URL, the component, the route. An agent that has to find the right file first spends its budget on the search instead of the fix.

How you'll know it worked. The acceptance criteria. "LCP under 2.5s on the PLP, measured on mobile" is checkable. "Make it faster" is not.

What it must not touch. Constraints are cheap to write and expensive to discover in review. Checkout, a third-party script, a page mid-campaign.

What you don't need to write

You don't need to pick an agent, choose a model, or describe how the work should be done. You declare the outcome and the system chooses the skills and tools.

Steering it mid-flight

Comment on the task. A comment is the control surface: it corrects the agent, adds the context it was missing, and triggers another run. You don't need to close a task and open a new one because the first attempt missed.

Because the exchange lives on the task, the next person to open it sees why the work is the way it is — including the correction you made.

When it comes back

Look at the preview, not the diff, first. The preview is the change running; the diff is how it was achieved. If the preview is right and the diff is strange, say so in a comment — that's exactly the kind of correction that improves the next run.