Skills ticket-signal-watch

Name: ticket-signal-watch
Author: openclaw

Monitor ticket pages or backend ticket data for sale, restock, presale, or status-change signals; emit structured alerts that can be pushed to OpenClaw channels, webhooks, or other notification backends. Use when users want reliable ticket notifications rather than automated checkout.

install

source · Clone the upstream repo

git clone https://github.com/openclaw/skills

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/armysheng/ticket-signal-watch" ~/.claude/skills/openclaw-skills-ticket-signal-watch && rm -rf "$T"

OpenClaw · Install into ~/.openclaw/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/openclaw/skills "$T" && mkdir -p ~/.openclaw/skills && cp -r "$T/skills/armysheng/ticket-signal-watch" ~/.openclaw/skills/openclaw-skills-ticket-signal-watch && rm -rf "$T"

manifest: skills/armysheng/ticket-signal-watch/SKILL.md

Ticket Signal Watch

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:

```
collector
```
- fetch page text or consume backend data
```
signal engine
```
- decide whether the change is meaningful
```
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

alerts

is empty, do not send a notification.

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.