Use tasks

Use a task when agent work needs a record a human can read later.

A prompt is enough for a quick question. A task is better when the work has intent, a plan, a diff, checks, review comments, or handoff between people and agents.

Create the task before the brew

A useful task is short, but it is not empty. Include:

• The problem or request.
• The expected outcome.
• Important constraints.
• Links, screenshots, or file paths when they matter.
• The checks that should run before review.

Do not write a task that says only “fix this.” That just moves the guessing into the agent session.

Keep the scope small

One task should usually produce one reviewable stream of work.

Split the task when:

• The work has unrelated outcomes.
• Different agents need different branches.
• The checks are different enough to review separately.
• One part can ship without the other.

Do not split just to create busywork. Split when it makes review easier.

Link the brew to the task

Start the brew from the task when you want the session to inherit the task context and leave a trail back to it.

For an agent, that record usually includes:

• The task description.
• The implementation plan.
• Session logs.
• Review comments.
• Final checks and follow-up.

That is the point of the task surface: the next person should not need to reconstruct the work from terminal memory.

Use plans as a checkpoint

Ask for a plan before risky edits. Read it for direction:

• Does it solve the task?
• Does it avoid out-of-scope areas?
• Does it name the right files?
• Does it name the right checks?
• Does it surface a risk before the diff exists?

If the plan is wrong, fix the plan before implementation. It is easier to change direction before files move.

Use logs for handoff

A good session log says what happened, not just that the work is complete.

Useful logs mention:

• Files changed.
• Commands run.
• Checks that failed or were skipped.
• Review comments addressed.
• Follow-up still needed.

Avoid vague logs like “implemented successfully.” That gives reviewers nothing to trust.

Close the loop

When the work is done, leave the task in a state that matches reality:

• Done when the change is reviewed and no required work remains.
• In progress when another pass is needed.
• Blocked when a real external dependency is stopping the work.
• Canceled when the branch or direction is intentionally dropped.

The task should tell the truth even when the agent sounded confident.

Next: tasks, plans, and logs for the model, or review agent work for the review order.