Convex Monitor

Rather than sitting in a polling loop, convex-monitor blocks on the next thing worth reacting to in a Convex app. One call to `wait_for_event` races three sources: local dev error logs, deployment subscriptions, and Sentinel rows for production errors. Whichever fires first comes back as a typed event (convex_error, prod_error, feature_request, or a quiet heartbeat), so the agent knows exactly what to fix or build next. It's most useful when you want an agent to babysit a dev session or triage live errors without you watching the dashboard. The honest catch: prod events only work if your app is deployed to Convex cloud and you've wired up Sentinel, so it's a poor fit for purely local projects. On harnesses without blocking MCP support, like Copilot cloud, it falls back to a poll loop with the same event contract.

skills.sh installs: 41K
GitHub stars: 69
last updated: Oct 26, 2026

View on GitHub

Install

$ npx -y skills add convex/agent-skills --skill convex-monitor --agent claude-code

Installs into .claude/skills of the current project.

Files

Watch for the next thing to react to

Block on the next typed event instead of polling. Races local error logs, deployment subscriptions, and Sentinel prod-error rows; returns the first to fire (or a quiet heartbeat).

Workflow

Call wait_for_event with {project_dir, event_kinds, timeout_ms}.
On kind=convex_error/next_error: decode and fix it. On kind=prod_error: triage (see sentinel) and fix. On kind=feature_request: build it. On kind=quiet: loop.
Where a harness has no blocking MCP (e.g. Copilot cloud), the pack runs a poll loop with the SAME event contract — same behavior, different mechanism.

Rules

Prefer the blocking tool; fall back to a poll loop only where blocking MCP is weak.
The event schema is fixed and versioned — the same trigger yields the same typed event.
Prod events (kind=prod_error) require a deployed cloud app plus Sentinel.

SKILL.md on GitHub