subagent-watchdog-stall-on-ui-template-tracklisted

Recognise the failure mode where a `general-purpose` (or similar) subagent dispatched to do UI/template-heavy work stalls and gets killed by the no-streamed-output watchdog (~600s of silence → terminate). Use when: (1) you dispatched a subagent for UI work (new page route + Jinja/template authoring + per-step iterative tests + small CSS), (2) the agent reports `failed: Agent stalled: no progress for 600s (stream watchdog did not recover)` with a partial result fragment like "Now let me look at the routes..." indicating it died mid-investigation, (3) the worktree contains uncommitted changes (the agent edited files before going silent and the work is salvageable), (4) you're considering re-dispatching with the same prompt or a "tighter" version — DON'T, because the stall is structural to dispatching this shape of work, not the prompt's fault. The fix is to switch to inline execution for the remainder of THIS task and bias toward inline for future UI/template tracks even though they cost more main-context token
wan-huiyan/agent-traffic-control · ★ 2 · AI & Automation · score 79

Install: claude install-skill wan-huiyan/agent-traffic-control

# Subagent watchdog stall on UI/template tracks ## Problem You dispatched a `general-purpose` subagent (or any agent running in the background via the Agent tool) to write a new UI screen — a route + Jinja template + a few tests. The agent reads existing patterns, plans template structure, drafts the template, iterates on test failures... and stalls. You get: ``` status: failed summary: Agent "Phase C: Screen 03 live workspace" failed: Agent stalled: no progress for 600s (stream watchdog did not recover) result: "Now let me look at the routes I'll consume (render, bundle, upload) and existing templates." ``` The result fragment shows it was mid-investigation. The worktree may contain partial edits. ## Context / Trigger Conditions Recognise this trap when: - The dispatched task is UI/template-heavy. Specifically: lots of file reads (template patterns, view models, helpers) + Jinja/HTML/CSS authoring + iterative test-write → run → fix → repeat loops. - The agent's last reported output is "Now let me ..." or similar — i.e. a tool-call prefix, not a result. - Total elapsed time before stall is in the 10-15 minute range. - Re-running the same prompt produces the same stall (verified on the S16 Phase C retry — second attempt died at "Now let me look at the routes I'll consume..."). - Comparable backend-only subagents in the same session completed successfully (e.g. Phase B render path took ~16 minutes and emitted 101 tool uses without stalling). ## Why the