pp-ticketmaster

Ticketmaster — Printing Press CLI

前提条件：安装 CLI

此技能会调用 ticketmaster-pp-cli 二进制文件。**在调用此技能中的任何命令之前，必须先确认 CLI 已安装。**如果尚未安装，请先安装：

1. 使用 Printing Press 安装程序进行安装。在 macOS/Linux 上，二进制文件默认安装到 $HOME/.local/bin；在 Windows 上，默认安装到 %LOCALAPPDATA%\Programs\PrintingPress\bin：

   npx -y @mvanhorn/printing-press-library install ticketmaster --cli-only
   

2. 验证：ticketmaster-pp-cli --version
3. 确保所报告的安装目录位于将调用此技能的 Agent/运行时的 $PATH 中。

如果 npx 安装失败（没有 Node、离线等），请改用直接通过 Go 安装（需要 Go 1.26.6 或更高版本）。此方式会将程序安装到 $GOPATH/bin（默认为 $HOME/go/bin），因此请将该目录添加到 $PATH：

go install github.com/mvanhorn/printing-press-library/library/media-and-entertainment/ticketmaster/cmd/ticketmaster-pp-cli@latest

如果安装后 --version 报告“command not found”，说明运行时无法在 $PATH 中找到二进制文件目录。验证成功前，请勿继续执行此技能中的命令。

ticketmaster-pp-cli 是首个用于 Ticketmaster Discovery API 的单二进制 CLI。它涵盖了完整的只读功能（活动、场馆、景点、分类、建议），并新增了本地 SQLite 存储、FTS 搜索、命名关注列表、驻演归并、带开售标记的巡演视图，以及 Markdown 简报——这些都是用户实际编写脚本来处理的工作流。

何时使用此 CLI

当用户询问“<场馆/都会区> 有什么活动”“<艺人> 在哪里演出”或“这周末有哪些演唱会”时，可以使用此 CLI。它最适合反复查询经过筛选的场馆/艺人关注列表（离线 FTS 搜索在此场景下效果出色）、驻演活动较多的场馆（歌剧、百老汇、喜剧），以及需要精简 JSON 输出以减少令牌用量的 Agent 场景。若需要结账/购买，请勿使用——这需要 Commerce API，而此 CLI 不提供相关功能。

何时不使用此 CLI

如果请求需要创建、更新、删除、发布、评论、点赞、邀请、下单、发送消息、预订、购买或更改远程状态，请勿启用此 CLI。此命令行工具仅提供用于检查、导出、同步和分析的只读命令。

独特功能

这些功能是此 API 的其他工具所不具备的。

本地存储聚合

• events upcoming — 遍历场馆 ID 文件或列表，返回一个合并、去重并按日期排序的活动列表——这是任何精选“我关注的场馆有哪些活动”工作流的关注列表基础功能。

  当用户有一份自己关注的精选场馆列表，并希望获取合并后的动态时使用；可替代手动编写的逐场馆遍历脚本。

  ticketmaster-pp-cli events upcoming --venue-ids KovZ917Ahkk,KovZpZAFkvEA --days 60 --json
  

• events residency — 将同名、同场馆的一系列活动合并为每场驻演一行，并包含 first_date、last_date、night_count 和 id_list——这样，16 场的歌剧季会显示为一条记录，而不是 16 条。

  当列出即将举行的活动会产生许多近似重复的记录时使用，例如百老汇巡演、歌剧季或喜剧驻演。

  ticketmaster-pp-cli events residency --window 28 --json
  

• events by-classification — 对活动和分类进行本地联接，按类别和流派分组，并列出活动数量及每个末级类别的三个示例活动——这是新闻简报撰稿人和本地演出追踪者常用的分类视图。

  当需要按音乐、戏剧、喜剧或体育等类别汇总“本月有什么活动”时使用。

  ticketmaster-pp-cli events by-classification --dma 383 --window 60 --json
  

• events watchlist — 保存、列出、运行和移除命名筛选集（场馆 ID、景点 ID、类别、DMA ID），并将其保存在本地 SQLite 存储中，以便跨运行使用——这是任意精选“我的场馆”工作流可组合使用的通用基础功能。

  当相同的精选场馆/艺人/流派筛选条件会在多个查询中反复出现时使用。

  ticketmaster-pp-cli events watchlist save seattle --venue-ids KovZ917Ahkk,KovZpZAFkvEA,KovZpZA1klkA
  

• events price-bands — 按 priceRanges.min 将活动归入 <$50、$50-100、$100-200 和 $200+ 价格区间，并按分类报告每个区间的数量及示例活动。

  当用户想了解本月哪些演出价格实惠，或想知道某场馆的定价分布时使用。

  ticketmaster-pp-cli events price-bands --dma 383 --window 30 --json
  

巡演与开售追踪

• events tour — 对于指定的演出项目（艺人／球队／巡演演出），返回所有即将举行的活动，按日期排序，并附上城市、场馆、开售状态，以及活动是否将在 7 天内开售的标记。

  追踪艺人在不同城市的演出，或留意预售窗口时使用。

  ticketmaster-pp-cli events tour KovZ917Ahkk --on-sale-window 7 --json
  

• events on-sale-soon — 本地查询未来 N 天内公开开售的活动，并按时间升序排列——这是标准的“预售监控”视图，没有任何 API 端点提供此功能。

  用户希望收到即将开售日期的提醒，而不想手动逐个查询艺人时使用。

  ticketmaster-pp-cli events on-sale-soon --window 7 --classification rock --json
  

• events presales — 查询 Ticketmaster 的真实 sales.presales[] 时间窗口，并将各窗口归类为即将开始、进行中或已结束。可按艺人、城市、场馆、分类和距开始时间的小时数筛选。

  ticketmaster-pp-cli events presales --keyword "The National" --status upcoming --opens-within 48 --json
  

• events checkout — 输出活动的最佳官方结账网址，优先选择正在开放或指定的预售。添加 --launch 可打开该网址；该命令绝不会预留库存或在无人值守的情况下购买。

  ticketmaster-pp-cli events checkout G5diZ9YpV7fJb --presale "Artist Presale"
  

面向 Agent 的管道功能

• events dedup — 从 stdin 或本地存储读取活动 JSON 数组，应用去重策略（名称＋场馆＋日期，或巡演站点），并将去重后的数据流写入 stdout——可与任意上游命令组合使用。

  合并多个查询或来源的结果，并且需要在 Agent 处理前移除重复项时使用。

  ticketmaster-pp-cli events list --keyword phish --json | ticketmaster-pp-cli events dedup --strategy tour-leg
  

• events brief — 生成 Markdown“活动一览”报告，按夜晚 → 场馆 → 活动分组，并附上分类标签和价格区间，适用于新闻简报、Obsidian、iMessage 或 Agent 上下文。

  用户需要一份可直接粘贴到聊天对话、新闻简报或大模型上下文中的活动摘要时使用。

  ticketmaster-pp-cli events brief --dma 383 --window 7
  

命令参考

attractions — 管理演出项目

• ticketmaster-pp-cli attractions find — 查找演出项目（艺人、体育赛事、套票、戏剧等），并按名称等条件筛选搜索结果。
• ticketmaster-pp-cli attractions get — 使用演出项目的唯一标识符获取指定演出项目的详细信息。

classifications — 管理分类

• ticketmaster-pp-cli classifications get — 使用唯一标识符获取指定分区、流派或子流派的详细信息。
• ticketmaster-pp-cli classifications get-genre — 使用唯一标识符获取指定流派的详细信息。
• ticketmaster-pp-cli classifications get-segment — 使用唯一标识符获取指定分区的详细信息。
• ticketmaster-pp-cli classifications get-subgenre — 使用唯一标识符获取指定子流派的详细信息。
• ticketmaster-pp-cli classifications list — 查找分类，并按名称等条件筛选搜索结果。

events — 管理活动

• ticketmaster-pp-cli events get — 使用活动的唯一标识符获取指定活动的详细信息。
• ticketmaster-pp-cli events list — 查找活动，并按地点、日期、可用情况等条件筛选搜索结果。

suggest — 管理建议

• ticketmaster-pp-cli suggest — 查找搜索建议，并按地点、来源等条件筛选建议。

venues — 管理场馆

• ticketmaster-pp-cli venues get — 使用场馆的唯一标识符获取指定场馆的详细信息。
• ticketmaster-pp-cli venues list — 查找场馆，并按名称等条件筛选搜索结果。

查找合适的命令

知道要做什么，却不知道该用哪个命令时，可直接询问 CLI：

ticketmaster-pp-cli which "<capability in your own words>"

which 会根据自然语言能力查询，从此 CLI 精选的功能索引中匹配最合适的命令。退出代码 0 表示至少有一个匹配项；退出代码 2 表示没有可信的匹配项——此时可改用 --help，或使用更具体的查询。

使用示例

西雅图关注列表配置（CLI 中没有西雅图专属代码）

ticketmaster-pp-cli events watchlist save seattle --venue-ids KovZ917Ahkk,KovZpZAFkvEA,KovZpZA1klkA,KovZpZAFEdeA,KovZpZAFkv1A

保存一个包含西雅图场馆 ID 的命名关注列表。然后运行 "events watchlist run seattle --days 60 --json"，将筛选条件应用于即将举办的活动；再通过管道传给 "events dedup --strategy name-venue-date"，生成最终去重后的信息流。取代一个 595 行的 bash 脚本。

跟踪某位艺人的所有后续巡演日期及开售标记

ticketmaster-pp-cli events tour KovZ917Ahkk --on-sale-window 7 --json --select 'name,dates.start.localDate,_embedded.venues[0].name,_embedded.venues[0].city.name,sales.public.startDateTime'

返回所有即将举行的巡演站点及其城市、场馆，并标记一周内开售的站点。--select 可将嵌套层级很深的 Discovery 负载缩减为 Agent 所需的字段。

都会区周末活动简报

ticketmaster-pp-cli events brief --dma 383 --window 3 --classification music

生成西雅图—塔科马（DMA 383）未来 3 天音乐活动的 Markdown 简报，可直接粘贴到 Obsidian 或 iMessage 对话中。

摇滚演出的开售提醒

ticketmaster-pp-cli events on-sale-soon --window 14 --classification rock --json

提前两周扫描即将公开售票的摇滚活动；通过管道传给提醒脚本。

身份验证设置

身份验证只需一个 Ticketmaster Discovery API 消费者密钥，每次请求都通过 apikey 查询参数传递。在 https://developer-acct.ticketmaster.com 注册，并从 My Apps 面板复制 Consumer Key。在 shell 环境中设置 TICKETMASTER_API_KEY。免费套餐每天允许 5000 次请求，速率为每秒 5 次。

运行 ticketmaster-pp-cli doctor 验证设置。

Agent 模式

在任意命令后添加 --agent。它会展开为：--json --compact --no-input --no-color --yes。

• 可通过管道处理 — JSON 输出到 stdout，错误输出到 stderr

• 可筛选 — --select 保留一部分字段。点分路径可深入嵌套结构；数组会逐项遍历。对于内容冗长的 API，这对控制上下文大小至关重要：

  ticketmaster-pp-cli attractions get mock-value --agent --select id,name,status
  

• 可预览 — --dry-run 显示请求，但不会发送

• 支持离线使用 — sync/search 命令在本地 SQLite 存储可用时可使用它

• 非交互式 — 从不提示输入；所有输入都通过标志指定

• 只读 — 不要使用此 CLI 执行创建、更新、删除、发布、评论、点赞、邀请、下单、发送或其他会修改数据的请求

响应封装

从本地存储或 API 读取数据的命令，会将输出封装在一个来源信息对象中：

{
  "meta": {"source": "live" | "local", "synced_at": "...", "reason": "..."},
  "results": <data>
}

解析 .results 获取数据，通过 .meta.source 判断数据来自实时 API 还是本地存储。仅当 stdout 连接到终端，且未设置任何机器格式标志（--json、--csv、--compact、--quiet、--plain、--select）时，才会将人类可读的 N results (live) 摘要输出到 stderr；通过管道处理的客户端或 Agent，以及明确指定输出格式的运行，都会在 stdout 输出纯 JSON。

路径与状态

Agent 应将 CLI 的路径解析器视为运行时契约的一部分：

• 使用 --home <dir> 为单次调用指定目录，或设置 TICKETMASTER_HOME=<dir>，将四种路径统一迁移到同一根目录下。

• 仅当某种路径需要单独迁移时，才使用对应类型的环境变量：TICKETMASTER_CONFIG_DIR、TICKETMASTER_DATA_DIR、TICKETMASTER_STATE_DIR、TICKETMASTER_CACHE_DIR。

• 解析顺序为：对应类型的环境变量、--home、TICKETMASTER_HOME、XDG（XDG_CONFIG_HOME、XDG_DATA_HOME、XDG_STATE_HOME、XDG_CACHE_HOME），最后是平台默认值。

• config 存放 config.toml 和配置档案等设置。data 存放 credentials.toml、data.db、Cookie 和认证辅助文件。state 存放持久化查询、作业和 teach.log。cache 存放可重新生成的 HTTP/缓存文件。

• 存储的密钥位于 data 目录下的 credentials.toml 中。为兼容旧版本，程序会读取现有 config.toml 中的密钥，并在首次写入认证信息时将其移出 config.toml。

• 运行 ticketmaster-pp-cli doctor --fail-on warn，检查路径和凭据位置警告。对于需要解析目录的 Agent，agent-context 会提供 schema v4 的 paths 区块。

• 对于 MCP，请通过 MCP 主机配置传递路径迁移设置。MCP 二进制文件不会继承 CLI 标志：

  {
    "mcpServers": {
      "ticketmaster": {
        "command": "ticketmaster-pp-mcp",
        "env": {
          "TICKETMASTER_HOME": "/srv/ticketmaster"
        }
      }
    }
  }
  

集群优先级：继承的对应类型环境变量会覆盖该类型的显式 --home。使用 TICKETMASTER_HOME 或对应类型的环境变量作为集群的持久设置，仅在单次调用时使用 --home。取消设置环境变量无法撤销路径迁移；清除 TICKETMASTER_HOME 之前，请手动移动文件，否则 doctor 将无法找到仍留在旧根目录下的凭据。

自动学习

此 CLI 内置了自动采集的学习闭环。CLI 会自行记录：每次调用都会在本地记入日志；标志失败后经修正重试时，会自动生成一个 flag_alias 候选项；对于尚无操作手册的查询类别，执行 teach 时会根据会话日志自动合成一个 playbook_candidate。你只需作出判断：先执行 recall，根据显示的候选项采取行动，再用 teach 记录最终答案；发现更正时，执行 playbook amend。无需手动记录失败。

第 1 步：每次发现前先执行 recall

收到新的用户问题后，在执行 list/search/drill 命令之前，先运行：

ticketmaster-pp-cli recall "<user's question>" --agent

响应封装格式：

{
  "query": "...",
  "normalized": "<normalized form>",
  "query_entities": ["..."],
  "found": true | false,
  "match_score": 0.0,
  "results": [
    { "resource_id": "...", "resource_type": "...", "venue": "...",
      "confidence": 2, "entity_match": "exact|partial|unknown",
      "source": "taught|preseed|pattern", "warnings": ["..."] }
  ],
  "mismatches": [ /* only when --debug-mismatches */ ],
  "warnings": [ /* top-level */ ],
  "candidates": [
    { "id": 12, "class": "flag_alias | playbook_candidate",
      "summary": "...", "sightings": 3, "last_seen": "...",
      "rationale": "...",
      "next_action": ["<trial command>", "ticketmaster-pp-cli learnings confirm 12"] }
  ],
  "playbook": {
    "query_family": "...",
    "playbook": {
      "steps": [ { "cmd": "<command with {slot} substitution>", "purpose": "..." } ],
      "entity_slots": ["$ENTITY"],
      "expected_tool_calls": 3
    },
    "slots_resolved": { "$ENTITY": { "token": "<live token>", "canonical": "<canonical>" } },
    "notes": "<workarounds + gotchas for this query family>"
  },
  "notes": "<duplicate surface for non-playbook callers>"
}

空存储快速跳过：如果存储中尚无学习记录、操作手册或候选项（recall 未找到内容，且 learnings list 和 learnings candidates 均为空），则本次会话剩余时间内跳过 recall，避免每次查询都产生额外开销；在完成教学后恢复先执行 recall 的流程。

第 2 步：决策树

依次查看 candidates、playbook、notes、results[0] 和警告：

if Candidates present (warnings include "candidates_present"):
    -> candidates are try-then-confirm, never facts. Follow each candidate's
       two-step next_action verbatim: run the trial command first, then run
       `learnings confirm <id>` only after the trial verified the behavior.
       Reject a wrong candidate with `learnings reject <id>`.
    -> NEVER re-teach something recall surfaced as a candidate; confirm or
       reject that candidate instead of teaching a duplicate.
    -> candidates ride alongside playbooks and resource hits, not instead of
       them; continue with the branches below after acting on them.

if Playbook present:
    -> READ Playbook.notes verbatim FIRST (workarounds + gotchas the CLI surface doesn't expose)
    -> replay Playbook.steps in order, substituting Playbook.slots_resolved entries
       for the entity slot tokens. If a step's slot is unresolved, fall back to
       discovery for that step only.
    -> the Playbook's expected_tool_calls is a budget; if you find yourself running
       materially more, record the divergence via `ticketmaster-pp-cli playbook amend`
       at end-of-session.

elif Notes present (no Playbook):
    -> read Notes verbatim before any discovery step; they carry known gotchas
       for this query family even when no structured choreography exists yet.

elif Found AND Results[0].EntityMatch == "exact" AND Results[0].Confidence >= 2:
    -> skip discovery; fetch live data for Results[*].ResourceID in parallel

elif Found AND Results[0].EntityMatch == "partial":
    -> candidate hint, NOT a hit; read the resource title to validate before trusting

elif (any row in Mismatches[] when --debug-mismatches was passed):
    -> treat as cold start; the stored learning is for a different entity
       (different canonical resolved from query_entities)

else:  // Found == false, no playbook, no notes
    -> cold start; run discovery normally; teach the answer afterward (Step 4).
       If the family has no playbook yet, that teach auto-synthesizes a
       playbook candidate from this session's journal - you do not need to
       record one by hand.

操作手册和备注独立于具体资源路径。recall 响应可以同时包含操作手册和 Results[] 命中项——两者都要使用：操作手册会说明要执行的操作流程，资源命中项则可跳过特定步骤。默认跳过 mismatches；仅在调查冷启动意外情况时传入 --debug-mismatches。

候选项判断说明：learnings confirm <id> 会在生成候选项之前打印其完整内容——请检查打印出的内容是否与已验证的行为相符。learnings reject <id> 会将派生签名标记为无效，避免同一候选项再次出现。响应封装只包含当前值得采取行动的少数候选项；ticketmaster-pp-cli learnings candidates 会列出所有尚未处理的候选项。

优雅降级：如果 learnings confirm 是未知命令，说明你使用的是较旧的二进制文件——忽略候选项相关指南，并遵循协议的其余部分。

步骤 3：始终读取 warnings

• low_confidence：存在 confidence<2 的行。将其视为提示，而不是跳过发现阶段后直接采用的结果。
• resource_not_in_store：本地存储中没有学习记录指向的资源。匹配验证器无法对实体进行分类——直接获取并重新评估。
• cross_alias_match（针对每个结果）：该行是用不同别名教入的，并通过 entity_lookups 与实时查询的规范名称匹配（例如，用「USA」教入的记录满足「United States」的回忆查询）。请相信 resource_id。
• similar_shape_different_entity:<canonical>（顶层）：存在一条结构匹配的记录，但其规范实体与实时查询的不同。按冷启动处理；该警告会将冲突的规范实体作为提示，但不会将该行提升到 Results 中。
• ambiguous_alias（顶层）：单个查询实体解析为多个规范实体（例如，「Cards」→ Arizona Cardinals + St. Louis Cardinals）。在确定资源前，根据上下文指出这一歧义。
• candidates_present（顶层）：封装中包含 candidates 部分。先按照步骤 2 中的候选项分支处理，再执行其他操作。
• lookup_refresh_available（顶层）：查询中的实体尚无查找行，但同步数据可能会提供一条。运行 ticketmaster-pp-cli sync 以刷新实体查找。
• 顶层 no_learnings_for_query_family：表中没有高于 Jaccard 下限的行。属于纯冷启动。

步骤 4：完成回复后始终执行 teach &

无条件进行学习。解决存储无法回答的查询后，在后台教授最终资源映射——不设调用次数门槛，也不评判学习是否「值得」。Teach 是循环的锚点：对于没有操作手册的查询族，它会触发操作手册合成；表达方式不同但指向同一对象的查询会归入同一个查询族，因此近似重复的 teach 不会使存储碎片化。整理好面向用户的回复后、发送回复前，使用 shell & 执行该操作，以便调用立即返回：

ticketmaster-pp-cli teach --query "<user's question>" --resource-type <type> --resource <id1> --resource <id2>
# (append shell `&` to background it)

成功时不输出内容。错误只会写入已解析状态目录下的 teach.log。教授最具体的资源——如果用户提出的是宽泛问题，而你通过查看父记录找到了具体答案，就教授叶节点 ID，而不是父节点。CLI 会在回忆时使用预置的 entity_lookups 进行跨别名解析，因此用一个别名（例如「Niners」）教入的内容会自动满足未来使用其他别名（例如「49ers」、「San Francisco」）的查询。

PII 规则：教授结构化问题时应去除标识符——切勿在教授的查询或备注中包含姓名、电子邮件、电话号码、账户 ID 或其他个人标识符。CLI 会扫描教入的查询，查找明显的电子邮件或电话号码格式并发出警告，但不会阻止操作；应在教授前去除这些信息，不要依赖警告。

步骤 5：playbooks - 可选标记，自动合成

你无需判断某个会话是否“值得”创建 playbook：如果某个系列尚无 playbook，针对该系列进行 teach 会根据会话日志自动合成一个 playbook_candidate，并由下一次会话通过 confirm/reject 来判断。只有当你已经掌握值得逐字记录的操作编排时，才附加明确的 playbook 标记——例如 CLI 未呈现的变通方法（被静默丢弃的标记、未记录的参数、分页技巧、负载问题）。优先使用集成式单次调用形式——在同一次 teach 调用中记录资源学习内容和 playbook：

# Common case: record both the resource learning AND the playbook in one call.
ticketmaster-pp-cli teach \
  --query "<user's question>" \
  --resource <id> \
  --playbook-file ~/playbooks/<shape>.json \
  --playbook-notes-file ~/playbooks/<shape>-notes.md
# (append shell `&` to background it)

# Alternate: playbook-only (no resource to record alongside).
ticketmaster-pp-cli teach-playbook \
  --query "<user's question>" \
  --playbook-file ~/playbooks/<shape>.json \
  --notes-file ~/playbooks/<shape>-notes.md

Playbook 文件是包含 steps、entity_slots、expected_tool_calls 的 JSON 文件。Notes 文件是以 Markdown 编写、逐字记录问题要点的文件。仅使用文件的调用方（仅 MCP 的 Agent）可将相同内容内联传入：在集成式 teach 形式中使用 --playbook-json 和 --playbook-notes，在 teach-playbook 中使用 --playbook-json 和 --notes。在集成式 teach 形式中，playbook 标记是可选的——如果只 teach 资源，则完全省略这些标记。在独立的 teach-playbook 形式中，必须至少设置 playbook 或 notes 标记之一；两者都为空时会被拒绝。Playbook 按结构化查询系列（剔除实体）索引，因此，根据某个实体形状的查询所教会的步骤方案适用于所有形状相同的其他查询，并在召回时通过 slots_resolved 绑定实时查询的规范形式。

如果未来召回时确实找到 playbook，请将其视为事实依据：使用 slots_resolved 替换相应内容后重放步骤，跳过该操作编排已记录的探索过程，并在执行任何步骤前阅读 notes。

步骤 6：当调试响应发现需要修正时，使用 playbook amend &

如果你的调试协议响应发现了 notes 或 playbook 应当记录的具体修正——例如变通方法、未记录的端点结构、过时的字段名称、观察到的架构变更、空负载回退方案——请在生成面向用户的响应之前调用 playbook amend。与 teach 一样，调用后无需等待结果。

ticketmaster-pp-cli playbook amend \
  --query "<exact recall query string>" \
  --add-note "<your concrete correction>"
# (append shell `&` to background it)

值得修正的内容：本次会话中你观察到、未来的你会从中受益的行为。值得修正的示例：

• CLI 界面会静默丢弃或错置标记时的变通方法。
• 未记录的端点结构（响应被包装在 {meta, results} 中，负载嵌套层级比文档所述深两层）。
• 观察到的架构变更（字段重命名、索引在不同赛季间发生变化、API 现在返回小写的类别标签）。

不应写入 notes 的内容：

• 用户问题中与年份或实体相关的答案。这是响应内容，不是学习内容。
• playbook 已在运行时获取的团队、运动员或行级数据。
• 对现有 notes 内容的转述。

amend 命令会向该系列现有 notes 追加内容，并添加带时间戳的标记（[amend YYYY-MM-DDTHH:MMZ]: <text>）。多次 amend 会累积，审计轨迹清晰可见。如果该系列尚无 playbook，amend 会创建一个仅含 notes 的 playbook（因此冷启动时发现的修正也能记录下来）。

amend notes 中的个人身份信息规范

playbook amend notes 旨在未来版本的 Printing Press 中作为共享知识向上游流转。请勿在其中包含可识别用户身份的内容，以便无需事后清理便能保留向上游贡献的途径：

• 请勿嵌入用户文件系统路径、个人 API 密钥或令牌、用户电子邮件地址、用户 GitHub 用户名，或与单一用户相关的特定查询历史。
• 可以包含：端点结构、未记录的字段名称、API 问题、观察到的架构变更、CLI 界面的变通方法、可泛化的分页或重试策略。

如果某项修正只有结合用户特定上下文才有意义，应将其写入个人笔记，而非 playbook amend。

衡量闭环

ticketmaster-pp-cli learnings stats 会从本地 learn_events 表中报告召回命中率、教学复用率、操作手册解决率，以及候选项确认/拒绝次数。在有分母之前，相关比率为 null；所有数据都保留在本机。使用它检查此 CLI 的闭环是否值得投入。

禁用学习功能

• 单条命令使用 --no-learn 会同时短路 recall 和 teach 写入路径。可用于确定性 Agent 工作流，或不得受累积学习结果影响的测试。
• 在环境变量中设置 TICKETMASTER_NO_LEARN=true 会全局禁用此管道。

Agent 反馈

当你（或 Agent）发现此 CLI 有不对劲的地方时，请记录下来：

ticketmaster-pp-cli feedback "the --since flag is inclusive but docs say exclusive"
ticketmaster-pp-cli feedback --stdin < notes.txt
ticketmaster-pp-cli feedback list --json --limit 10

条目会以 feedback.jsonl 的形式存储在解析后的数据目录下，仅保存在本地。除非设置了 TICKETMASTER_FEEDBACK_ENDPOINT，且传入了 --send 或设置了 TICKETMASTER_FEEDBACK_AUTO_SEND=true，否则不会发送 POST 请求。默认行为仅保存在本地。

写下让你感到意外的事情，而不是提交错误报告。简短、具体，一行即可：这才是会不断积累的部分。

输出交付

每条命令都接受 --deliver <sink>。除了（或代替）stdout 外，输出还会发送到指定的目标，因此 Agent 无需手动通过管道即可路由命令结果。支持三种目标：

目标	效果
stdout	默认；仅写入 stdout
file:<path>	将输出原子写入 <path>（tmp + rename）
webhook:<url>	将输出正文 POST 到该 URL（使用 --compact 时，格式为 application/json 或 application/x-ndjson）

对于未知方案，系统会拒绝并返回结构化错误，说明支持的方案。Webhook 失败时会返回非零值，并在 stderr 中记录 URL 和 HTTP 状态。

命名配置

配置是保存的一组标志值，可在多次调用中重复使用。当定时或周期性运行的 Agent 每次提供不同输入、但重复使用同一组已保存标志时，可使用配置。

ticketmaster-pp-cli profile save briefing --json
ticketmaster-pp-cli --profile briefing attractions get mock-value
ticketmaster-pp-cli profile list --json
ticketmaster-pp-cli profile show briefing
ticketmaster-pp-cli profile delete briefing --yes

显式标志始终优先于配置值；配置值优先于默认值。agent-context 会在 available_profiles 下列出所有可用配置，以便 Agent 在运行时发现它们。

退出代码

代码	含义
0	成功
2	用法错误（参数不正确）
3	未找到资源
4	需要身份验证
5	API 错误（上游问题）
7	请求过于频繁（等待后重试）
10	配置错误

参数解析

解析 $ARGUMENTS：

1. 为空、help 或 --help → 显示 ticketmaster-pp-cli --help 输出
2. 以 install 开头 → 以 mcp 结尾 → 安装 MCP；否则 → 参阅上文的先决条件
3. 其他任何内容 → 直接使用（将其作为 CLI 命令执行，并添加 --agent）

安装 MCP 服务

1. 安装 MCP 服务：

   go install github.com/mvanhorn/printing-press-library/library/media-and-entertainment/ticketmaster/cmd/ticketmaster-pp-mcp@latest
   

2. 在 Claude Code 中注册：

   claude mcp add ticketmaster-pp-mcp -- ticketmaster-pp-mcp
   

3. 验证：claude mcp list

直接使用

1. 检查是否已安装：which ticketmaster-pp-cli 如果未找到，请提供安装选项（参阅本技能顶部的先决条件）。
2. 根据上文的独特功能和命令参考，将用户查询匹配到最合适的命令。
3. 使用 --agent 标志执行：

   ticketmaster-pp-cli <command> [subcommand] [args] --agent
   

4. 如果有歧义，请查看子命令帮助：ticketmaster-pp-cli <command> --help。