Day-to-day work

The situation

The project exists, the tree exists, work is happening. Tasks are executed by an agent — sometimes one, sometimes several across different days. Between sessions the agent remembers nothing.

That is the central problem of working with agents daily, and a smarter model does not solve it: context simply does not survive the end of a session. What solves it is where the knowledge is kept.

What you do

Hand over a task by slug, rather than retelling it. The context is already in the node.

Read the [decision] notes. That is where the agent explains a non-obvious choice. Arguing about a decision now is cheaper than reconstructing it from code in a month.

Move it to "done" — or to "regression" with what is wrong. The agent leaves the task in "testing" and goes no further: building and verifying are different roles.

What the agent does

/execute-task AF-TASK-42

What sits behind that:

1. get_node(slug: "AF-TASK-42") — the description and every comment: earlier decisions live there.
2. get_dependencies — if a blocker is open, the agent doesn't start; it says so.
3. rag_context — the surrounding context: similar tasks, decisions already taken, neighbouring modules. What the ticket doesn't repeat but the project records.
4. update_node_status(status: "in_progress") — the board shows what it is doing.
5. add_comment as it goes: [progress] for what was done, [decision] for why this way, [blocker] for what is in the way.
6. update_node_status(status: "testing") with the commit hash and a [done] note on how to verify.

Verification can go to an agent too — a second pass, one that didn't write this code:

/review-work AF-TASK-42

It walks the acceptance criteria one by one and routes the task to done or back to regression with a list of what doesn't hold.

When there's more than one task and the order is known, run the whole plan — the skill walks the child tasks in dependency order:

/execute-task AF-PLAN-7

What comes out

A cycle where knowledge is not lost. The next agent picking up a neighbouring task reads the previous one's comments and continues rather than restarting. A month later you open a task yourself and see not only what was done but why that option was chosen.

Parent progress is recomputed from the statuses of the tasks inside — the tree shows the real state, not what somebody remembered to update.

Limits

The discipline rests on skills, not on good intentions. An agent without execute-task will do the work and leave no trail. Check that it has the skills and that they are current: sync-skills compares them against the server.

A status lies if nobody moves it. A task sitting "in progress" for a month distorts the progress of the whole tree. That is a working habit, not a technical problem.

The agent will not settle a contested question for you. It leaves a [blocker] and stops. That is the right behaviour, but it requires somebody to read blockers.

Tokens and duration are not always visible. The presence panel shows who is working on what; the token counter needs a separate reporter (installation), and without it the panel honestly says the reporter is not connected rather than drawing a zero.

Next

• Execute a task — step by step
• Strict mode — when documentation must keep up