Guide

Writing a good task

AI writes a spec for every task, but the spec is only as good as the task. A clear task gets a clear spec, which gets a mergeable PR.

State the outcome, not the implementation

Describe what should be true when the task is done: the behavior, the endpoint, the fix. Let the spec and the solver choose how. 'Add a /version endpoint returning the build SHA' beats 'edit main.py'.

Give concrete acceptance criteria

List what 'done' looks like: inputs, outputs, edge cases, and anything that must NOT change. These become the spec's acceptance criteria and the bar the PR is judged against.

Keep it scoped

One coherent change per task. A task that touches three subsystems is three tasks. Smaller scope means a sharper spec, a tighter workspace file-set, and a faster merge.

Point at the relevant files

If you know where the change lives, say so. Koduo scopes the workspace to the files the spec expects to touch, and naming them up front makes both AI and developer faster.

Size the bounty to the work

The bounty signals effort and complexity to developers. Trivial fixes attract fast claims; deep work needs a bounty that's worth a developer's afternoon.

Next: pushing a good PR →