Task

What it is

A task is a single piece of work: a bug to fix, a feature to add, a question to research. It's filed as a description, usually with a bit of structure like acceptance criteria and a priority, and it moves through a sequence of stages until it's done. The task itself gets assigned, never a person or a machine. That's why a different agent can pick up the same task at a later stage without anything about it changing.

Why it matters to you

How well a task is written is the single biggest lever on whether the result matches what you actually wanted. A vague task gets a vague answer; a task with clear acceptance criteria gives the agent, and the person reviewing it, something concrete to check the result against. This is the one skill worth learning even if you never touch a line of code, and it transfers directly from writing a good brief for a human contractor.

How it works in CodeHerder

In CodeHerder, a task is filed with a type and a description, plus whatever required fields that type carries. It's the thing that flows through workflow stages: plan → code → review → merge → verify. A task also carries its own history, all in one place instead of scattered across chat threads: comments, the fields set at each stage, plus eventually the pull request that closed it. Writing tasks an agent can actually build, including how to fill in acceptance criteria well, is covered in the writing tasks doc.

• Writing tasks →

What people get wrong

A task isn't a chat message and an agent isn't going to ask clarifying questions the way a person might mid-conversation. Say what you want up front, including what "done" looks like, rather than expecting a back-and-forth to fill in the gaps later. The other common mistake is writing a task the size of an entire project. A task that's actually one clear, checkable unit of work moves faster and gets a far more careful review than one trying to describe a whole quarter's worth of change.