loop-onlisted

# /loop-on — Monitor-driven event loop (alternative to cron) ## Why this exists Cron loops fire on a schedule regardless of state. For "wait until the build finishes," "watch for a PR comment," "react when a log line appears," — cron is the wrong primitive. It either fires too often (burning tokens on no-ops) or too rarely (latency between event and reaction). `Monitor` is Claude Code's event-stream primitive — each stdout line from a watched command becomes a notification. `/loop-on` wraps Monitor in the same lifecycle as `/loop`: registered in history, listable via `/loops`, stoppable via `/loop-stop`, integrated with TaskList. ## Argument parsing ``` /loop-on <condition> [then: "<prompt>"] [until: "<stop-condition>"] /loop-on <condition> watch-cmd: "<shell-cmd>" then: "..." ``` Two ways to specify the watched condition: ### Pre-defined condition shortcuts | Condition | What it watches | Underlying Monitor cmd | |---|---|---| | `pr-merged:<repo>:<pr-num>` | GitHub PR state change to merged | poll-loop using `gh api` | | `ci-status:<repo>:<branch>` | GitHub Actions run reaches success/failure | poll-loop using `gh run list` | | `file-changed:<path>` | inotify event on path | `inotifywait -m <path>` | | `log-line:<path>:<pattern>` | tail -f emits matching line | `tail -F <path> \| grep --line-buffered <pattern>` | | `cron-job-state:<id>:<new-state>` | a tracked cron transitions to specified state | poll-loop using CronList | | `task-completed:<task-id>` | TaskList tas