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. このスキルを実行するエージェント／ランタイムの $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 です。読み取り専用の全機能（イベント、会場、アトラクション、分類、候補検索）に加え、FTS 検索、名前付きウォッチリスト、レジデンシーの集約、販売開始フラグ付きのツアービュー、Markdown ブリーフを備えたローカル SQLite ストアを提供します。これらは、実際のユーザーがスクリプトを作成して対応していたワークフローです。

この CLI を使う場面

ユーザーが「<会場／都市圏>で何が開催されるか」「<アーティスト>はどこで公演するか」「今週末のコンサートは何か」と尋ねた場合に、この CLI を使ってください。厳選した会場／アーティストのウォッチリストに対する繰り返しの問い合わせ（この場合はオフラインの FTS が便利です）、レジデンシー中心の会場（オペラ、ブロードウェイ、コメディー）、およびコンパクトな JSON 出力でトークン使用量を抑えたいエージェントのコンテキストに適しています。チケットの購入が必要な場合は使わないでください。購入には Commerce API が必要ですが、この CLI は対応していません。

この CLI を使わない場面

作成、更新、削除、公開、コメント、賛成票の追加、招待、注文、メッセージの送信、予約、購入、リモート状態の変更が必要なリクエストには、この CLI を有効にしないでください。この CLI で利用できるのは、確認、エクスポート、同期、分析の読み取り専用コマンドです。

独自の機能

これらの機能は、この API に対応する他のツールでは利用できません。

ローカルストアの集計

• events upcoming — 会場 ID のファイルまたはリストを対象に検索し、重複を除去して日付順に並べた統合イベント一覧を返します。厳選した会場の「自分の会場で何が開催されるか」というワークフローの基盤となる機能です。

  気になる会場をまとめたリストがあり、イベント情報を一つにまとめたフィードが必要な場合に使います。会場ごとに検索する手作業のスクリプトに代わる機能です。

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

• events residency — 同じ名前と会場のイベントが続く場合、それらを 1 つのレジデンシー行にまとめ、first_date、last_date、night_count、id_list を表示します。これにより、16 夜にわたるオペラシーズンが 16 件ではなく 1 件として表示されます。

  ブロードウェイの公演、オペラシーズン、コメディーのレジデンシーなど、今後のイベントを一覧表示すると類似した行が多数並んでしまう場合に使います。

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

• events by-classification — イベントと分類をローカルで結合し、セグメントとジャンルごとに集計します。各末端分類について、イベント数とイベントの例を 3 件表示します。ニュースレターの作成者や地域のイベントを追跡する人が使う、分類別の一覧です。

  「今月の開催情報」を音楽、演劇、コメディー、スポーツなどに分けてまとめる場合に使います。

  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 — イベントの最適な公式購入 URL を表示します。販売中または名前付きの先行販売を優先します。--launch を追加すると URL を開きます。このコマンドが在庫を確保したり、無人で購入したりすることはありません。

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

エージェント向けの連携機能

• events dedup — 標準入力またはローカルストアからイベントの JSON 配列を読み込み、重複排除戦略（名前＋会場＋日付、またはツアー公演単位）を適用して、重複を除いたストリームを標準出力に書き込みます。上流の任意のコマンドと組み合わせて使えます。

  複数のクエリやソースの結果を統合し、エージェントで処理する前に重複を取り除く場合に使います。

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

• events brief — 分類ラベルと価格帯を付け、夜ごと → 会場ごと → イベントごとにまとめた「開催イベント」レポートを Markdown 形式で生成します。ニュースレター、Obsidian、iMessage、エージェントのコンテキストに適しています。

  チャット、ニュースレター、LLM のコンテキストにそのまま貼り付けられるイベント概要が必要な場合に使います。

  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 は少なくとも 1 件一致したことを示します。終了コード 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'

今後開催されるツアー公演すべてについて、都市、会場、および1週間以内に販売開始となる公演のフラグを返します。--select を使うと、深くネストされた Discovery のペイロードからエージェントに必要な情報だけに絞り込めます。

都市圏の週末イベント概要

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

2週間後に一般販売が開始されるロックイベントをスキャンし、アラート用スクリプトにパイプで渡します。

認証の設定

認証には Ticketmaster Discovery API のコンシューマーキーを1つ使用し、すべてのリクエストで apikey クエリパラメーターとして渡します。https://developer-acct.ticketmaster.com に登録し、My Apps ダッシュボードから Consumer Key をコピーしてください。シェル環境に TICKETMASTER_API_KEY を設定します。無料プランでは、1日あたり5,000リクエスト、1秒あたり5リクエストが許可されます。

設定を確認するには、ticketmaster-pp-cli doctor を実行してください。

エージェントモード

任意のコマンドに --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 を参照してください。人が読める N results (live) の概要は、stdout がターミナルで、かつ機械可読形式のフラグ（--json、--csv、--compact、--quiet、--plain、--select）が設定されていない場合に限り、stderr にのみ出力されます。パイプやエージェントの利用者、および出力形式を明示した実行では、stdout に純粋な JSON が出力されます。

パスと状態

エージェントは、CLI のパスリゾルバーをランタイム契約の一部として扱ってください。

• 1 回の実行では --home <dir> を使用するか、TICKETMASTER_HOME=<dir> を設定して、4 種類すべてのパスを 1 つのルートの下に移動します。

• 特定の種類だけを別の場所にする必要がある場合に限り、種類ごとの環境変数を使用します。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-context は、解決済みディレクトリが必要なエージェント向けに、スキーマ v4 の paths ブロックを公開します。

• MCP では、MCP ホストの設定を通じて移動先を指定します。MCP バイナリは CLI フラグを継承しません。

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

フリートでの優先順位：継承された種類ごとの環境変数は、その種類について明示的な --home より優先されます。フリート全体に適用する設定には TICKETMASTER_HOME または種類ごとの変数を使い、--home は 1 回の実行に限って使用します。環境変数の設定を解除しても、移動は元に戻りません。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.

プレイブックと Notes は、リソースごとのパスとは独立しています。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（トップレベル）：1 つのクエリエンティティが複数の正規名に解決されました（例：「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 & を実行する

学習は無条件です。ストアでは回答できなかったクエリを解決した後、最終的なリソースの対応付けをバックグラウンドで学習させてください。呼び出し回数のしきい値はなく、学習する価値があったかどうかを判断する必要もありません。学習はループの要です。プレイブックのないファミリーではプレイブックの合成を促し、同じ指示対象を表す言い回しは 1 つのファミリーにまとめられるため、重複に近い学習によってストアが断片化することもありません。ユーザー向けの回答を組み立てた後、出力する前に、シェルの & を付けて実行してください。これにより呼び出しはすぐに戻ります。

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：プレイブック — 省略可能なフラグ、自動合成

セッションにプレイブックが「必要」かどうかを判断する必要はありません。プレイブックのないファミリーに対して教え込みを行うと、セッションのジャーナルから playbook_candidate が自動合成され、次のセッションで確認または却下されます。明示的なプレイブックフラグを付けるのは、記録する価値のある手順をすでに把握している場合に限ってください。たとえば、CLI では表面化しなかった回避策（黙って破棄されるフラグ、ドキュメントにないパラメーター、ページネーションの工夫、ペイロードの落とし穴など）です。統合されたワンコール形式を優先してください。リソースの学びとプレイブックを、同じ teach 呼び出しで記録します。

# 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

プレイブックファイルは、steps、entity_slots、expected_tool_calls を含む JSON 形式です。ノートファイルは、落とし穴をそのまま記載した Markdown 形式です。ファイルを使用しない呼び出し元（MCP 専用エージェント）は、同じ内容をインラインで渡します。統合 teach 形式では --playbook-json と --playbook-notes を、teach-playbook では --playbook-json と --notes を使用します。統合 teach 形式ではプレイブックフラグは省略可能です。リソースのみを教え込む場合は、フラグをすべて省略してください。単独の teach-playbook 形式では、プレイブックフラグとノートフラグのうち少なくとも一方を指定する必要があります。両方が空の場合は拒否されます。プレイブックは構造上のクエリファミリー（エンティティを除去したもの）に基づいてキー付けされるため、あるエンティティ形状のクエリから教え込まれた手順は、同じ形状を持つほかのすべてのクエリに適用されます。呼び出し時には slots_resolved が、実行中のクエリの正規形を対応付けます。

今後の呼び出しでプレイブックが見つかった場合は、それを信頼できる情報として扱ってください。slots_resolved による置換を適用して手順を再実行し、すでに手順に記載されている調査は省略し、どの手順を実行する前にも notes を読んでください。

ステップ 6：デバッグ応答で修正点が特定されたら playbook amend &

デバッグプロトコルへの応答で、ノートやプレイブックに記録すべき具体的な修正点（回避策、ドキュメントにないエンドポイントの形式、古いフィールド名、観測されたスキーマの変更、空のペイロードに対するフォールバックなど）が特定された場合は、ユーザー向けの応答を出力する前に 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} にラップされている、ドキュメントの説明より 2 階層深くペイロードがネストされているなど）。
• 観測されたスキーマの変更（フィールド名の変更、シーズン間でのインデックスのずれ、API が返すカテゴリラベルの小文字化など）。

ノートに記載すべきでないもの：

• ユーザーの質問に対する、年やエンティティに固有の回答。それは応答であり、学びではありません。
• プレイブックが実行時にすでに取得する、チーム、選手、行ごとのデータ。
• 既存のノートの内容を言い換えただけの記述。

amend コマンドは、ファミリーの既存のノートにタイムスタンプ付きのマーカー（[amend YYYY-MM-DDTHH:MMZ]: <text>）を付けて追記します。複数回の amend は蓄積され、監査証跡を確認できます。ファミリーにプレイブックがまだ存在しない場合、amend はノートのみのプレイブックを作成するため、初回の修正も記録されます。

amend ノートにおける PII の取り扱い

playbook amend のノートは、Printing Press の将来のバージョンで共有ナレッジとして上流に流れる可能性を想定して設計されています。ユーザーを特定できる情報を含めないでください。これにより、後から情報を削除しなくても上流への貢献経路を確保できます。

• 埋め込まないでください：ユーザーのファイルシステムへのパス、個人用 API キーやトークン、ユーザーのメールアドレス、ユーザーの GitHub ハンドル、特定のユーザーにひも付いたクエリ履歴。
• 記載してよい情報：エンドポイントの形式、ドキュメントにないフィールド名、API の注意点、観測されたスキーマの変更、CLI インターフェースへの回避策、汎用化できるページネーションや再試行の手法。

修正内容がユーザー固有のコンテキストでのみ意味を持つ場合は、プレイブックの amend ではなく、個人用ノートに記載してください。

ループの効果測定

ticketmaster-pp-cli learnings stats は、ローカルの learn_events テーブルから、再利用ヒット率、教えた内容の再利用率、プレイブック解決率、候補の確定／却下件数を報告します。分母がない間、率は null です。データはすべてこのマシン上に保存されます。この CLI でループの効果が得られているかを確認するために使用します。

学習の無効化

• 1 回のコマンドに --no-learn を指定すると、recall と teach の書き込み処理の両方がスキップされます。蓄積した学習内容の影響を受けてはならない、決定論的なエージェントのフローやテストで使用してください。
• 環境変数に TICKETMASTER_NO_LEARN=true を設定すると、パイプラインが全体的に無効になります。

エージェントのフィードバック

この 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 されることはありません。デフォルトの動作はローカルのみです。

バグ報告ではなく、意外だったことを書いてください。短く、具体的に、1 行で記録します。積み重なっていくのは、その部分です。

出力の配信

すべてのコマンドで --deliver <sink> を指定できます。出力は標準出力に加えて（または標準出力の代わりに）指定したシンクに送られるため、エージェントはコマンド結果を手作業でパイプに渡すことなく振り分けられます。次の 3 つのシンクに対応しています。

シンク	効果
stdout	デフォルト。標準出力のみに書き込みます
file:<path>	出力を <path> にアトミックに書き込みます（tmp + rename）
webhook:<url>	出力本文を URL に POST します（--compact の場合は application/json または application/x-ndjson）

不明なスキームは、対応しているスキームの一覧を示す構造化エラーとともに拒否されます。Webhook に失敗すると、ゼロ以外の終了コードが返され、URL と HTTP ステータスが stderr に記録されます。

名前付きプロファイル

プロファイルは、保存したフラグ値のセットで、呼び出しをまたいで再利用できます。スケジュール実行または定期実行されるエージェントが、実行ごとに異なる入力を受け取りながら、同じ保存済みフラグを再利用する場合に使用します。

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 に一覧表示するため、情報を調べるエージェントは実行時にそれらを検出できます。

終了コード

コード	意味
0	成功
2	使用方法のエラー（引数が正しくありません）
3	リソースが見つかりません
4	認証が必要です
5	API エラー（上流の問題）
7	レート制限中（待ってから再試行してください）
10	設定エラー

引数の解析

$ARGUMENTS を解析します。

1. 空、help、または --help → ticketmaster-pp-cli --help の出力を表示します
2. install で始まる → mcp で終わる場合は → MCP のインストール。それ以外の場合は → 上記の「前提条件」を参照してください
3. その他 → 直接使用（--agent を指定して CLI コマンドとして実行します）

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。