Tasks, plans, and logs

Use tasks, plans, and logs when agent work needs to survive past one terminal session.

A plain brew is fine for a quick local question. A task-linked brew is better when the work needs review, handoff, or a record a teammate can read later.

Tasks are the unit of intent

A task is where the work starts. It should tell the agent and the reviewer what matters.

A useful task includes:

  • The problem or request.
  • The expected outcome.
  • Important constraints.
  • Links, screenshots, or product context where needed.
  • The checks that should pass before review.

Keep the task focused. If the description needs three unrelated goals, split it before launching agents.

Plans are for checking the route

An implementation plan captures how the agent intends to approach the work. Read it before the agent edits risky code.

A good plan names:

  • Files or subsystems likely to change.
  • The smallest implementation path.
  • Tests, lint, or manual checks.
  • Known risks.
  • Out-of-scope work.

The point is not to predict every line of code. The point is to catch bad direction early.

Session logs are for handoff

A session log records what happened during a brew. It is most useful when it is short and concrete:

  • What changed.
  • Why it changed.
  • What checks ran.
  • What failed.
  • What the next reviewer should inspect.

Do not use logs as a place for vague status. "Implemented the feature successfully" tells nobody what to trust.

The review path

For task-linked work, review in this order:

  1. Read the task description.
  2. Read the latest implementation plan.
  3. Read the relevant session logs.
  4. Inspect the diff in the editor.
  5. Run or review the checks.
  6. Leave follow-up on the task or send it back to the agent.

That order keeps you grounded. If you start from the final agent summary, you inherit the agent's framing before you have seen the work.

When to skip the task surface

Skip tasks for disposable work:

  • Asking an agent to explain a file.
  • Running a one-off command.
  • Trying a throwaway local experiment.
  • Inspecting a project before you know what task to create.

Once the work creates a branch, review, or teammate handoff, move it into a task.

Team habit

Treat the task as the source of truth. Prompts are temporary. Terminal output scrolls. A clear task, a checked plan, and a useful session log give the team something stable to review.

Next: review agent work.

On this page