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: INLINECODE0
Script: INLINECODE1
Target example: INLINECODE2
Notifier example: INLINECODE3
Default state path: INLINECODE4

Operating model

Treat the workflow as three layers:

1. INLINECODE5

- fetch page text or consume backend data

2. INLINECODE6

- decide whether the change is meaningful

3. INLINECODE7

- 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:

CODEBLOCK0

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
INLINECODE11: only meaningful changes worth notifying
INLINECODE12: short human-readable summary

Each alert should contain enough information to route downstream:

- INLINECODE13
INLINECODE14
INLINECODE15
INLINECODE16
INLINECODE17
INLINECODE18

Configuration guidance

Prefer official detail pages over generic search pages.

Use:

- require_all for identity words that must be present
INLINECODE20 for actionable signal words
INLINECODE21 for the strongest signals

Examples of strong signals:

- INLINECODE22
INLINECODE23
INLINECODE24
INLINECODE25
INLINECODE26
INLINECODE27
INLINECODE28
INLINECODE29
INLINECODE30

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.

票务信号监控

本技能用于可靠的票务通知，而非自动结账。

适用场景：

- 用户希望监控票务开售或补货信号
后端已有票务数据，需要可推送的事件格式
希望OpenClaw检查官方页面、搜索页面或其他文本来源以获取票务信号

文件

- 技能根目录：{baseDir}
脚本：{baseDir}/scripts/watchticketpages.py
目标配置示例：{baseDir}/config/targets.example.json
通知器配置示例：{baseDir}/config/notifiers.example.json
默认状态文件路径：{baseDir}/state/state.json

运行模式

将工作流程视为三个层级：

1. 采集器

- 获取页面文本或消费后端数据

2. 信号引擎

- 判断变化是否具有意义

3. 通知器

- 将结果事件推送到OpenClaw频道、Webhook或其他下游系统

理想的生产环境配置：

- 优先使用后端数据（如有）
仅在必要时回退到页面检查
保持采集与通知的解耦

输出预期

脚本应生成：

- results：每个目标的检查结果
alerts：仅包含值得通知的有意义变化
summary：简短易读的摘要

每个告警应包含足够的信息以供下游路由：

- name（名称）
platform（平台）
url（网址）
signalhits（信号命中数）
signallevel（信号等级）
alert_reasons（告警原因）

配置指导

优先使用官方详情页面而非通用搜索页面。

使用：

- requireall：必须存在的身份关键词
matchany：可操作性的信号词
signal_keywords.high：最强信号

强信号示例：

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

防护措施

- 不要将通用页面变化视为开售信号。
搜索页面的可靠性低于详情页面。
在高频轮询前添加冷却、去重和抖动机制。
如果某个平台开始返回反爬页面或验证页面，请明确标记而非声称成功。
本技能仅用于通知工作流程；不得暗示其能够安全地自动完成结账。

ticket-signal-watch票务信号监控