Summary
When a kanban worker calls the clarify tool, the call always times out because there is no live user on the other end — the worker runs headless. The task remains in running status with no visible indicator that it is waiting, and no notification reaches the operator.
This is a silent productivity drain: the task is effectively stranded but looks "in progress".
Steps to Reproduce
- Create a kanban task that requires a human decision
- The worker agent calls
clarify() instead of kanban_block()
- The clarify call blocks for
clarify_timeout (default ~120s)
- After timeout, the agent receives no answer and either retries or hallucinates
- The task stays in
running — the operator has no way to know it needs input
Observed in production: a kanban worker called clarify asking "Want me to promote to production, or check staging first?" The clarify timed out, the agent produced a confused fallback response, and the task sat in "running" for hours.
Expected Behavior
Kanban workers should never call clarify. Instead, they should:
kanban_comment(body="...") with full contextkanban_block(reason="<specific decision needed>") to transition to blocked status
This way the operator sees the task in blocked on the board and can act on it.
Fix Locations
Two levels:
-
agent/prompt_builder.py — The auto-injected KANBAN_GUIDANCE system prompt should include an explicit "Do NOT use clarify" bullet in the ## Do NOT section. This is the canonical guidance every kanban worker sees.
-
skills/kanban-worker/SKILL.md — The shipped kanban-worker skill should have an explicit "Never call clarify" rule. (Local workaround: patched in user's local copy.)
Related Issues
Additional Context
The kanban-worker skill already documents the kanban_comment + kanban_block pattern for asking human questions. Adding a "never use clarify" rule closes the gap where a worker might choose clarify over block.
Summary
When a kanban worker calls the
clarifytool, the call always times out because there is no live user on the other end — the worker runs headless. The task remains inrunningstatus with no visible indicator that it is waiting, and no notification reaches the operator.This is a silent productivity drain: the task is effectively stranded but looks "in progress".
Steps to Reproduce
clarify()instead ofkanban_block()clarify_timeout(default ~120s)running— the operator has no way to know it needs inputObserved in production: a kanban worker called
clarifyasking "Want me to promote to production, or check staging first?" The clarify timed out, the agent produced a confused fallback response, and the task sat in "running" for hours.Expected Behavior
Kanban workers should never call
clarify. Instead, they should:kanban_comment(body="...")with full contextkanban_block(reason="<specific decision needed>")to transition toblockedstatusThis way the operator sees the task in
blockedon the board and can act on it.Fix Locations
Two levels:
agent/prompt_builder.py — The auto-injected KANBAN_GUIDANCE system prompt should include an explicit "Do NOT use clarify" bullet in the
## Do NOTsection. This is the canonical guidance every kanban worker sees.skills/kanban-worker/SKILL.md — The shipped kanban-worker skill should have an explicit "Never call clarify" rule. (Local workaround: patched in user's local copy.)
Related Issues
Additional Context
The kanban-worker skill already documents the
kanban_comment + kanban_blockpattern for asking human questions. Adding a "never use clarify" rule closes the gap where a worker might choose clarify over block.