“Let me remove this from Waiting” sounded like a small request. A menu item, perhaps a confirmation, one less thing on the screen.
Todoista tracks who has the next move in delegated work. That makes removing an item more consequential than it looks: the action also says something about the person I was waiting for.
Disappearing is not a meaning
In the documented gap-finder run, the agent flagged a missing way to cancel a waiting item. The existing paths covered receiving the result and taking the work back. Neither explained “we no longer need this.”
Here is a reconstruction of the decision behind that finding, not a verbatim transcript:
Me: I just want this request out of Waiting.
Agent: Did the person deliver it, did you take it back, or did the request stop being needed?
Me: The project was cancelled. The person did nothing wrong.
Agent: Then should their history say the request never existed?
That last distinction changed the feature for me. An item disappearing from a list is a visual result. It does not tell us what happened.
Four outcomes, four different truths
The decision became four actions with different consequences:
| Action | Where the item goes | What the history means |
|---|---|---|
| Received | Back to My Tasks | The person successfully delivered. |
| Taken back | Back to My Tasks | I resumed the work; it is not their delivery. |
| Cancelled | Closed | The request existed, but I withdrew it. |
| Deleted | Removed | No product history, as if the item never existed. |
Imagine I asked Anna for a quotation, then cancelled the project. Cancelling the request preserves that sequence. Deleting it erases the request from the product’s history. Marking it received would record a delivery that never happened.
The map gives each outcome its own step, so the destination and history rule can be refined together. These are the product’s four choices, not a universal task-management template.
From conversation to testable cards
The gap-finder supplied the missing question. The subsequent refinement made the answers testable, and those four outcomes became criteria on the relevant cards. For cancellation, the checks include closing the waiting item, retaining that the request existed, and recording withdrawal rather than successful delivery.
That division of work is why the AI skills were useful. Gap analysis examined the lifecycle; refinement forced the language to describe observable behavior. The StoriesOnBoard MCP connection let the writing skills work on the same board. Review and read-back kept the conversation tied to what was actually recorded.
I still had to decide what each outcome meant. The agent helped me notice that I had not made those decisions yet.
Before refining your next delete story, list the reasons someone might want an item gone. Then use testable acceptance criteria to ask: what should disappear, and what should remain true afterward?
