A coding-agent task is not done when the agent says “done”
A coding agent can finish a run, report a branch, and still leave the team with work to do. Someone must inspect the result. A pull request might remain open. A merged commit might not be deployed. Treating those events as one “done” state makes handoffs look faster than they are.
A useful task workflow gives each event its own name and owner. Consider a small, invented example: a game's health bar overlaps a phone notch in landscape mode. Here is how to move that issue from observation to accepted work without losing track of what actually happened.
Capture the problem before writing the agent prompt
The person who sees the overlap can record a short request: which screen is affected, which orientation shows it, and an image if sharing it is authorized. That is enough to bring the issue to a reviewer. It is not yet enough to tell an agent which code to change.
The reviewer first checks whether a task already covers the issue. If it does, attach the request to that work instead of opening a duplicate. If it needs new work, prepare a private task brief. This is the point to name the repository, the relevant screen, the expected behavior, and the boundaries of the change.
The distinction matters because a reported symptom and an executable instruction have different standards. “The bar overlaps the notch” is a useful observation. “Use the existing safe-area helper, change only the combat HUD, and verify these viewport sizes” is a bounded implementation task.
Give the agent and the human different jobs
A good agent brief says what to inspect, what may change, what evidence to return, and when to stop. For this example, it might ask the agent to:
- Find the existing safe-area handling used elsewhere in the interface.
- Apply it to the combat HUD without changing unrelated layout code.
- Add or update a deterministic layout check if the project supports one.
- Report the files changed, checks run, and any unresolved viewport behavior.
- Stop and ask for help if the shared helper conflicts with an authored HUD anchor.
The human runbook is shorter. It tells the person supervising the work which repository to open, which device sizes to inspect, what visual proof to capture, and who will judge the result. The human supplies access and judgment; the agent handles the bounded implementation.
This is one practical test for the best project management tool for coding agents: can it preserve those two responsibilities and the evidence between them, or does it collapse everything into a single prompt and a single checkbox?
Separate the transitions
For the health-bar fix, these statements mean different things:
| State | What it establishes |
|---|---|
| Open | The prepared task is available to an eligible runner. |
| Claimed | One runner owns this attempt. |
| Delivered | The runner has reported an outcome and supplied required evidence. |
| Accepted | A reviewer has judged that outcome sufficient. |
| Merged | Repository evidence shows the delivered branch landed on its base. |
| Deployed | A release system shows the revision reached an environment. |
Delivery is a report, not a verdict. The report might honestly say the fix failed on one viewport. A reviewer can send it back to the same runner with a specific correction, or reopen it for someone else. Acceptance records a review decision. Even after acceptance, a protected branch or failing check can block a merge; a successful merge still does not prove deployment.
Wagglet's request-to-delivery workflow describes these states, including its private Draft stage and separate repository merge state. In Wagglet, that Draft is already the task record: publishing it changes its visibility rather than copying it into a new ticket.
Keep the receipt useful
At the end of the invented health-bar example, a reviewer should be able to answer four plain questions: What was requested? What did the runner actually deliver? Who accepted it, and on what evidence? What does the repository say happened to the branch?
A team can start with a request, create a prepared task directly, or connect the work to a larger plan. The route can vary. The meanings of delivery, acceptance, merge, and deployment should stay precise. That is what lets the next person trust the status without reconstructing the whole conversation.