← ClaudeAtlas

watch-patternslisted

Correct construction of watchers for long-running operations. TRIGGER when: arming observation of a long-running operation (CI run, deploy, transfer, GC/prune, log stream), writing poll/until loops, or using the Monitor tool. SKIP: defining production alerts/metrics (use monitoring-observability); log formatting (use logging-standards).
komluk/scaffolding · ★ 15 · AI & Automation · score 78
Install: claude install-skill komluk/scaffolding
# Watch Patterns Skill ## Purpose How to observe long-running operations correctly. Anyone can run a loop — the value is a watcher that **never lies**: it terminates, it detects failure as reliably as success, and its silence is never mistaken for progress. Key architectural fact: a subagent cannot hold a long-lived observation. Notifications from an armed `Monitor` land in the conversation that armed it; a subagent finishes and dies. Observation is therefore always armed by the main loop — this skill is loadable anywhere for exactly that reason. ## Auto-Invoke Triggers - Watching a CI run, deployment, file transfer, GC/prune job, or log stream - Writing any poll/`until` loop over a remote or local state - Using the `Monitor` tool or `Bash(run_in_background)` for observation --- ## Decision Tree — Choose the Mechanism FIRST The single most common failure is picking the wrong mechanism. Decide BEFORE writing any script: | Situation | Mechanism | |-----------|-----------| | "Is it done *now*?" — answerable immediately | **One-shot check.** Single command, no loop, no monitor. | | ONE notification when a condition becomes true (deploy finished, download complete, GC done) | **`Bash(run_in_background)` + `until` loop** with a terminal condition and a bounded iteration count. NOT `Monitor`. | | REPEATING events, each occurrence matters (every error line, every restart) | **`Monitor` tool** with a filter covering ALL terminal states. | | CI run status (Gitea Actions) | **MCP