Ticket Signal Watch

Monitor ticket pages or backend ticket data for sale, restock, presale, or status-change signals; emit structured alerts that can be pushed to OpenClaw chann...

Security Scan

The skill's code, instructions, and requirements are consistent with a ticket-monitoring notifier: it only needs python3, reads a targets config, fetches target URLs, keeps a local state file, and emits structured alerts.

Purpose & Capability

Name/description match the included files: the script fetches pages, looks for ticket-related keywords, tracks state, and emits structured results. Requiring python3 and providing example configs is proportionate.

Instruction Scope

SKILL.md and the script stay within the stated purpose. The script fetches arbitrary URLs listed in the targets config and writes a state JSON. That behavior is expected, but be aware it will make outbound requests to any URL you place in targets (including internal endpoints if run in a networked/cloud environment). The script does not read other system files or environment variables.

Install Mechanism

This is an instruction-only skill with no install steps; no external packages or downloads are performed. Lowest-risk install footprint.

Credentials

The skill declares no required credentials or env vars. Example notifier config shows webhook URLs and Authorization headers — those are user-provided values you may store in config files. Storing secrets in plain JSON files has usual operational risks; the skill itself does not require or exfiltrate credentials.

Persistence & Privilege

always is false and the script only writes its own state JSON (and would write to any file path you configure). It does not modify other skills or system settings.

Assessment

This skill appears coherent for monitoring ticket pages. Before running: inspect and control the targets.json you feed it (don't include internal-only URLs if running in a shared/cloud agent), ensure the state and notifier paths are writable and stored where you want data retained, and avoid placing secret tokens in plain text files unless you accept that risk. Note the example notifier shows webhook headers but the script does not automatically POST alerts — you'll need to wire notifications yourself (or extend the script). Also respect terms of service and anti-bot protections of target sites; the script will flag anti-bot pages but does not bypass them.

This skill is for reliable ticket notifications, not automated checkout.

Use it when:

• a user wants to monitor ticket sale or restock signals
• a backend already has ticket data and needs a push-ready event format
• you want OpenClaw to check official pages, search pages, or other text sources for ticket signals

Files

• Skill root: {baseDir}
• Script: {baseDir}/scripts/watch_ticket_pages.py
• Target example: {baseDir}/config/targets.example.json
• Notifier example: {baseDir}/config/notifiers.example.json
• Default state path: {baseDir}/state/state.json

Operating model

Treat the workflow as three layers:

1. collector
   • fetch page text or consume backend data
2. signal engine
   • decide whether the change is meaningful
3. notifier
   • push the resulting event to OpenClaw channels, webhooks, or another downstream system

The ideal production setup is:

• use backend data if available
• fall back to page checks only when needed
• keep collection and notification decoupled

Recommended usage

Run the script with a target config and a writable state file:

python3 "{baseDir}/scripts/watch_ticket_pages.py" \
  --config "{baseDir}/config/targets.example.json" \
  --state "{baseDir}/state/state.json" \
  --json

If alerts is empty, do not send a notification.

If alerts is non-empty, forward the structured result to:

• an OpenClaw channel
• a webhook
• a file/queue processor

Output expectations

The script should produce:

• results: per-target check results
• alerts: only meaningful changes worth notifying
• summary: short human-readable summary

Each alert should contain enough information to route downstream:

• name
• platform
• url
• signal_hits
• signal_level
• alert_reasons

Configuration guidance

Prefer official detail pages over generic search pages.

Use:

• require_all for identity words that must be present
• match_any for actionable signal words
• signal_keywords.high for the strongest signals

Examples of strong signals:

• 立即购买
• 立即预订
• 可选座
• 有票
• 开售
• 预售中
• 补票
• 回流
• 加场

Guardrails

• Do not treat generic page changes as sale signals.
• Search pages are weaker than detail pages.
• Add cooldown, dedupe, and jitter before high-frequency polling.
• If a platform starts returning anti-bot pages or challenge pages, mark that explicitly instead of claiming success.
• This skill is for notification workflows; do not imply that it can safely complete checkout automatically.