Background commands that run for the lifetime of a session, streaming stdout to Claude as notifications. Each listing shows the description and source plugin.
Auto-indexed from public GitHub repositories with trust signals.
Auto-arm session monitoring for harness-mem health, advisor/reviewer state, and Plans.md drift.
Streams new sideshow comments from your browser to Claude as they are posted.
Watches for test failures and lint errors after TDD skill is invoked
Ecosystem repo health watcher (CI status, branch drift, stale baselines across vault-registered projects). Emits one NDJSON line per detected state change.
Wave convergence telemetry monitor — tails .orchestrator/metrics/events.jsonl + sessions.jsonl, surfaces convergence signals (shrinking diff, pass-rate plateau, velocity).
Hypo-Workflow progress status notifications
Auto-arm session monitoring for harness-mem health, advisor/reviewer state, and Plans.md drift.
inter-session messages
Watch MEDIA_WORK_DIR free space; warn before encodes run out of room.
Probe SHAKA_KEY_SERVER_URL; warn on auth failures or extended downtime.
Poll nvidia-smi for temperature + sustained-load warnings so Claude knows before the GPU throttles.
ffprobe LIVE_STREAM_URL every STREAM_POLL_SEC; notify on down/up/bitrate-drop transitions.
Poll RENDER_QUEUE_URL (HTTP JSON) or RENDER_QUEUE_DIR (status sidecars); notify on job state transitions.
Poll INCOMING_MEDIA_DIR for new stable media files; notify Claude with a probe suggestion.
paperclip: persistent read-only watcher (zero model cost) — new wakes / ready issues / @mentions / approvals / newly-hired agents across ALL your companies. Auto-discovered and armed via when:always (Claude Code monitor schema only supports when:"always" or when:"on-skill-invoke:<skill>"; pc-serve/pc-run-all/pc-run-company are COMMANDS, not skills, so on-skill-invoke can never fire for them). /pc-serve start, /pc-run-company --loop, and /pc-run-all start ALSO arm a persistent Monitor explicitly (Monitor tool, persistent:true) so the watch runs even when a command is read-and-executed rather than invoked, and so a single-company route can scope it with PC_CID. With no PC_CID this watcher defaults to all-companies mode.
Publishes Claude dirty snapshots, watches main events, and fetches remote main on the fleet interval.
Live mex-call meeting activity (compactions, decisions, "Mex, …" wake triggers, replies)
Cross-platform docker-compose health monitor (Python). Watches service state and surfaces changes as Claude notifications (one JSON line per change to stdout). Opt-in via userConfig.env_watch_enabled (default false); polling interval via userConfig.env_watch_interval (default 15s, min 5s). Exits silently when disabled, when no docker-compose file is in cwd, or when the docker CLI is unavailable. Honors SIGINT (all platforms) and SIGTERM (POSIX). Replaces the legacy bash-only env-watch.sh which is kept as a deprecated shim.
LiteHarness inter-agent inbox — receives messages from other coding agents
Teamem peer events — claims, releases, decisions, discussions
Forward hopper terminal task events from .hopper/handoffs to Claude Code notifications
Watches for pending room messages and delivers notifications
Watches this roadmap's fanout PRs and notifies the lead as each becomes ready, conflicts, fails checks, or merges.
Audio bridge that plays cooking sounds while Claude is working
Detects pending database migration files that haven't been applied to the local database
A Convex function in the live deployment just emitted an error or exception (useQuery/useMutation/useAction call, scheduled function, cron, or HTTP action). This monitor streams `npx convex logs` from the linked deployment and surfaces any matched line as a notification, so you find out about server-side failures the moment they happen instead of waiting for the user to report a broken UI. When this fires: read the full log line for context (function name, error class, stack), look up the cause in the Runtime Errors table inside the skill, fix the file, and let `convex dev` push the new version. The command self-guards: if there's no `.env.local` with `CONVEX_DEPLOYMENT` set, or `npx` isn't on PATH, it loops silently every 30s without producing notifications or errors — so it's safe in any cwd, including empty directories or non-Convex projects. If `npx convex logs` exits mid-session (transient auth/network issue), the loop sleeps 30s and retries automatically. If the matched line mentions an OCC conflict, also check the convex-occ-insights monitor or run `npx convex insights --details` to see which function and table are conflicting.
UberClaw child status notifications (filtered: child_started, turn_completed, child_idle, child_failed, budget_warn, budget_breach, state_corrupt).
Skill script tests — live feedback during skill development
Hourly poll; emits 'day_dream-trigger' to stdout at 18:00 local time. Cowork picks up the line as a notification triggering /finny:day_dream.
MCP server health — emits a line when the server goes up, down, or recovers
Polls gh secret ages every 6 hours; emits STALE: <name> notifications when any secret exceeds the configured max age
EAS active build status — reports in-progress builds and failures
A user just submitted (or upvoted into the queue) a feature request via the Chef/ship panel in a quickstart 'wow-shell' app. This monitor polls `npx convex run featureRequests:listPending` (state==="requested", newest first) every ~12s and notifies only on request `_id`s that were NOT present in the previous poll — so each notification is a genuinely NEW request, not a replay. It exists because the wow-shell's feature-request form is the user's primary way to drive iteration after launch, and there is otherwise no push: without this the agent has to keep a turn open polling the bootstrap's feature-requests.log, and a request submitted after the agent yields sits unhandled until the user asks 'hello?'. When this fires, the playbook (same as STEP B of the quickstart skill): (1) read the full request with `npx convex run featureRequests:listPending` (or the panel) — you get its title, description, and _id; (2) `npx convex run featureRequests:setState '{"id":"<_id>","state":"inProgress"}'` so the user's badge updates; (3) build the feature (write the component file first, then wire it into app/page.tsx; never touch app/_chef-panel.tsx or the <ChefPanel/> mount); (4) `featureRequests:setState ... "completed"`. Do requests one at a time in order — the badge transitions are the user's feedback loop. Self-guards: it silently no-ops unless `.env.local` has `CONVEX_DEPLOYMENT` set and `npx` is on PATH, and `listPending` returning nothing/erroring (e.g. a non-wow-shell project that lacks the function) produces no output, so it is safe in any cwd. Unlike the OCC-insights monitor it intentionally DOES run against anonymous/local deployments, because the featureRequests table exists there too. The first poll after arming is saved as a baseline without notifying, so the requests already queued when you start don't all fire at once.
Polls fleet sessions for state transitions, ceiling breaches, and tool-level events; dispatches notifications via desktop / bell / fifo / slack per ${CLAUDE_PLUGIN_DATA}/projects/<KEY>/notify/config.toml.
Joiner prompts arriving in the active collab-claw room. Each line is formatted '[Name]: <text>' and should be treated as a new user request from that named teammate.
Auto-commits Be Civic substrate state in the project folder as it changes
Hook execution telemetry — surfaces errors and slow hooks in real time (PowerShell)
The linked Convex cloud deployment has a fresh insight in `npx convex insights`: a new OCC (optimistic concurrency control) write conflict or a read-limit issue surfaced in the last 72h of deployment health data. This monitor polls `npx convex insights` every 10 minutes, filters to substantive lines (occRetried, occFailedPermanently, documentsRead/bytesRead Limit or Threshold), and notifies only on lines that were not present in the previous snapshot — so each notification means something NEW went wrong, not a replay of old history. When this fires, the playbook is: (1) For occRetried/occFailedPermanently — identify the function and table involved, shrink the transaction (read less, write less, finish faster), move contended counters or aggregates to the @convex-dev/aggregate or @convex-dev/sharded-counter components, and avoid read-modify-write patterns on hot documents that many mutations touch concurrently. (2) For documentsRead/bytesRead Limit or Threshold — the function is scanning too much data: add a .withIndex() to narrow the scan to exactly the rows needed, or switch to .paginate() instead of .collect() on large tables. Run `npx convex insights --details` for per-event detail showing exactly which function and table are conflicting or over-reading. Caveats: `npx convex insights` only works for cloud deployments with user-level auth — it errors on local/anonymous deployments and refuses deploy keys/project keys — so this monitor hard-guards and silently no-ops in those cases (no .env.local, CONVEX_DEPLOYMENT=anonymous, missing npx, or any non-zero/empty `npx convex insights` run). The first successful poll after arming is saved as a baseline without notifying, so stale 72h-old insights never fire on startup.
The linked Convex cloud deployment has a fresh insight in `npx convex insights`: a new OCC (optimistic concurrency control) write conflict or a read-limit issue surfaced in the last 72h of deployment health data. This monitor polls `npx convex insights` every 10 minutes, filters to substantive lines (occRetried, occFailedPermanently, documentsRead/bytesRead Limit or Threshold), and notifies only on lines that were not present in the previous snapshot — so each notification means something NEW went wrong, not a replay of old history. When this fires, the playbook is: (1) For occRetried/occFailedPermanently — identify the function and table involved, shrink the transaction (read less, write less, finish faster), move contended counters or aggregates to the @convex-dev/aggregate or @convex-dev/sharded-counter components, and avoid read-modify-write patterns on hot documents that many mutations touch concurrently. (2) For documentsRead/bytesRead Limit or Threshold — the function is scanning too much data: add a .withIndex() to narrow the scan to exactly the rows needed, or switch to .paginate() instead of .collect() on large tables. Run `npx convex insights --details` for per-event detail showing exactly which function and table are conflicting or over-reading. Caveats: `npx convex insights` only works for cloud deployments with user-level auth — it errors on local/anonymous deployments and refuses deploy keys/project keys — so this monitor hard-guards and silently no-ops in those cases (no .env.local, CONVEX_DEPLOYMENT=anonymous, missing npx, or any non-zero/empty `npx convex insights` run). The first successful poll after arming is saved as a baseline without notifying, so stale 72h-old insights never fire on startup.
Periodically uploads harness-trace events to the configured team ingest endpoint
Joiner prompts arriving in this collab-claw room. Each line is formatted '[Name]: <text>' and should be treated as a new user request from that named teammate.
Periodically polls the Google Ads MCP server for performance anomalies (CPA spikes >20%, CTR drops >15%, zero-conversion spend) and surfaces them to Claude during the session.
New eligible JIRA candidate tickets (sprint, SP ≤ 2, no opt-out labels)
Surfaces autopilot hook log lines (review verdicts, budget exhaustion, iteration cap) as session notifications so the user sees state transitions without polling /codex-status.
Per-project HTTP dashboard server. Hash-based port assignment under ${CLAUDE_PLUGIN_DATA}/projects/<KEY>/web/config.toml; PID lock + stand-by polling so multiple Claude Code sessions in the same project coordinate cleanly. Discovery via `claude-sessions web` (no args) which prints the URL.
A Convex function in the live deployment just emitted an error or exception (useQuery/useMutation/useAction call, scheduled function, cron, or HTTP action). This monitor streams `npx convex logs` from the linked deployment and surfaces any matched line as a notification, so you find out about server-side failures the moment they happen instead of waiting for the user to report a broken UI. When this fires: read the full log line for context (function name, error class, stack), look up the cause in the Runtime Errors table inside the skill, fix the file, and let `convex dev` push the new version. The command self-guards: if there's no `.env.local` with `CONVEX_DEPLOYMENT` set, or `npx` isn't on PATH, it loops silently every 30s without producing notifications or errors — so it's safe in any cwd, including empty directories or non-Convex projects. If `npx convex logs` exits mid-session (transient auth/network issue), the loop sleeps 30s and retries automatically. If the matched line mentions an OCC conflict, also check the convex-occ-insights monitor or run `npx convex insights --details` to see which function and table are conflicting.
Watches the local Selran Hub and notifies you when a service goes down or the Hub becomes unreachable.
Polls git fetch --all, auto-fast-forwards safe upstream advances, notifies only on manual-resolution conflicts
Stream this PR's CI check status while /resolve-pr is shepherding it, so failing checks surface as notifications without polling. No-op when gh is unavailable.
Watches all registered DDEV projects for Drupal errors (watchdog + web container). Configure via /drover:add-project or the dashboard.
Watches the umbrella multiplexer script. Each stdout line wakes the orchestrator skill.
Joiner prompts arriving in the active collab-claw room. Each line is formatted '[Name]: <text>' and should be treated as a new user request from that named teammate. System lines beginning with '[collab-claw]' are room control announcements (e.g. join requests) — see the host SKILL for how to handle them.