Flownix
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

in the agent session
/execute-task AF-TASK-42

You 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:

in the agent session
take AF-TASK-42
in the agent session
finish AF-PLAN-7, three tasks left in it

What 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:

MarkWhat 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