Sections
On this page
Execute a task
Statuses, comments as the agent's memory, the commit, and the rule of leaving it in testing rather than done.
Execution is not only code. It is code plus a trail from which the next agent does not start at zero. The second half matters just as much: between sessions the agent remembers nothing, and anything not written into the node is lost.
How to start
/execute-task AF-TASK-42You don't have to name the skill. It is picked up from the sense of the request, so in practice people write something shorter — and it works the same:
take AF-TASK-42finish AF-PLAN-7, three tasks left in itWhat happens
Context is pulled before any work
The agent reads the task description and every comment — earlier decisions live there. Then it pulls the surrounding knowledge by meaning: similar tasks, decisions already taken, neighbouring modules. The ticket does not repeat what the project already records; the agent finds it.
The task is claimed
The status moves to "in progress", so the board shows what the agent is working on right now, and you do not learn it after the fact.
Work proceeds in tracked steps
At every meaningful step the agent leaves a comment:
| Mark | What it means |
|---|---|
[progress] | what was done and with what result |
[decision] | a non-obvious choice and why that one |
[blocker] | what is blocking and what would unblock it |
[done] | the summary: what was built, where, how to verify |
The value lives in [decision]. Code shows what was done; nothing but such a note
shows why this option and not the one next to it.
Closing
The task moves to "testing", the commit hash is written into it, and a [done] comment
explains how to verify the result.
Honest statuses
A parent's progress is computed from the statuses of the tasks inside it, so a wrong status distorts the picture of the whole tree.
- in progress — right now, not "started a month ago".
- blocked — with a
[blocker]comment naming what exactly is in the way. A blocked task without a reason is indistinguishable from an abandoned one. - testing — built, under verification.
- regression — verification found problems.
What you do
Check against the acceptance criteria, not against the volume of work. The criteria are in the task — if they are missing, that is the first question, not the last.
Read the [decision] notes. If a decision looks wrong, arguing about it now is
cheaper than reconstructing it from code in a month.
Move it to "done" — or to "regression" with what is wrong.
Next
- Strict mode — when closing requires updating the spec
- Code reviews