Parallel Monitor
Run recurring web monitors that alert when prices, filings, or competitor pages change without manual checking.
Overview
Parallel Monitor is an agent skill most often used in Idea (also Validate, Grow) that creates and manages recurring web change monitors via parallel-cli until you delete them.
Install
npx skills add https://github.com/parallel-web/parallel-agent-skills --skill parallel-monitorWhat is this skill?
- Long-running server-side monitors that re-check the web until deleted, unlike one-shot search skills
- CLI actions: create, list, events, get, update, simulate, event-group, delete
- Optional webhooks on each change event for automation hooks
- Requires parallel-cli ≥ 0.3.0 with Bash(parallel-cli:*) tool access
- User-invocable with argument hints for monitor lifecycle management
- Requires parallel-cli version 0.3.0 or newer for the monitor command
- Documented CLI actions include create, list, events, get, update, simulate, event-group, and delete
Adoption & trust: 6.9k installs on skills.sh; 56 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need ongoing alerts when something on the public web changes but one-off searches do not keep watching for you.
Who is it for?
Solo builders tracking competitor pricing, product pages, or public filings who already use or can install parallel-cli.
Skip if: Builders who need a fully self-hosted crawler inside their repo without Parallel’s CLI and cloud monitors, or offline-only workflows.
When should I use this skill?
User asks to monitor, track changes to, watch, or alert when something on the web changes, or to list, inspect, update, or delete existing monitors.
What do I get? / Deliverables
A persistent monitor runs on your cadence, surfaces change events you can list or inspect, and can optionally notify via webhook when updates occur.
- Created or updated monitor configuration
- Event listings and monitor inventory from list/events/get commands
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Competitive and market change tracking most often starts in Idea when validating what rivals and markets are doing before you commit to a build. Monitor create/list/events flows map directly to watching competitor pricing, filings, and public pages on a cadence.
Where it fits
Create a monitor on a rival’s pricing page to catch moves before you finalize positioning.
Simulate monitor events to see whether filing or price signals justify narrowing MVP scope.
List active monitors and review event history after a launch to adjust pricing or messaging.
How it compares
Use for durable change-tracking jobs via parallel-cli, not as a replacement for one-shot Parallel search or deep research skills.
Common Questions / FAQ
Who is parallel-monitor for?
Indie builders and small teams who want agent-driven setup of recurring web monitors and event review through parallel-cli.
When should I use parallel-monitor?
In Idea or Validate when watching competitor pricing or filings; in Grow when maintaining alerts on market or competitor page changes; whenever you need list, update, or delete on existing monitors.
Is parallel-monitor safe to install?
It grants Bash access to parallel-cli and requires internet; review Security Audits on this page and your Parallel account data policies before use.
SKILL.md
READMESKILL.md - Parallel Monitor
# Web Monitor Action: $ARGUMENTS > Requires `parallel-cli` ≥ 0.3.0 (the `monitor` command was added in 0.3.0). If `parallel-cli monitor` errors with `no such command` or similar, tell the user to run `parallel-cli update` (or `pipx upgrade parallel-web-tools` if installed via pipx), then retry. ## What this skill does Monitors are long-running, server-side jobs that re-check the web on a cadence and emit events when something changes. Unlike search/research/findall (one-shot lookups), monitors persist until deleted and can optionally fire a webhook on each event. ## Decide the action Parse the user's request and pick one: | Intent | Action | |---|---| | "Track / watch / monitor / alert me when X" | **create** | | "What am I monitoring?" / "List monitors" | **list** | | "What changed?" / "Show me events for monitor X" | **events** | | "Show monitor X" / "Get details for X" | **get** | | "Change cadence / query / webhook for X" | **update** | | "Test the webhook" / "Fire a test event" | **simulate** (requires a webhook on the monitor) | | "Show me the full payload for event group X" | **event-group** | | "Stop / delete monitor X" | **delete** (always confirm before deleting) | ## Create a monitor ```bash parallel-cli monitor create "<query>" --cadence daily --json ``` Cadence options: `hourly`, `daily` (default), `weekly`, `every_two_weeks`. Match cadence to how often the source actually changes — hourly for prices/news, weekly for filings/staffing. Optional flags: - `--webhook https://example.com/hook` — POST events to a URL as they happen - `--metadata '{"team":"competitive-intel"}'` — attach JSON metadata for your own bookkeeping - `--output-schema '<json>'` — structure the event payload (advanced) Parse the JSON to extract the `monitor_id`. Tell the user: - The monitor has been created with its ID - The cadence (so they know when to expect first event) - That events accumulate server-side — they can run `parallel-cli monitor events $MONITOR_ID` later to see what changed If they configured a webhook, suggest testing it: ```bash parallel-cli monitor simulate "$MONITOR_ID" ``` `simulate` requires a webhook to be configured on the monitor. Without one it errors with `Webhook not configured for this monitor` — do not run it on monitors created without `--webhook`. ## List monitors ```bash parallel-cli monitor list -n 10 --json ``` Default to `-n 10` — accounts with many historical monitors can return megabytes of JSON otherwise. Raise the limit only if the user explicitly asks for "all" or a larger set. Present as a table: ID, query (truncated), cadence, created. > Note: `monitor list` is not guaranteed to be sorted newest-first, so a monitor you just created may not appear in the first page of results. If a user is verifying creation, prefer `monitor get $MONITOR_ID` (using the ID returned by create) over scanning the list. ## View events for a monitor ```bash parallel-cli monitor events "$MONITOR_ID" --lookback 10d --json ``` Lookback format: `Nd` (days) or `Nw` (weeks). Default `10d`. For deeper detail on a specific event group: ```bash parallel-cli monitor event-group "$MONITOR_ID" "$EVENT_GROUP_ID" --json ``` Summarize for the user: count of events in the period, then a bulleted list of what changed with timestamps. Cite source URLs from the event payload. ##