pp-ticketdata

TicketData — Printing Press CLI

前提条件：CLI をインストールする

このスキルは ticketdata-pp-cli バイナリを使用します。このスキルのコマンドを実行する前に、CLI がインストールされていることを必ず確認してください。インストールされていない場合は、まずインストールしてください。

1. Printing Press インストーラーを使ってインストールします。バイナリのインストール先は、macOS/Linux では $HOME/.local/bin、Windows では %LOCALAPPDATA%\Programs\PrintingPress\bin がデフォルトです。

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

2. 確認します：ticketdata-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/ticketdata/cmd/ticketdata-pp-cli@latest

インストール後に --version が「command not found」と表示された場合、ランタイムからバイナリのディレクトリを $PATH 経由で参照できません。確認が成功するまで、スキルのコマンドを実行しないでください。

TicketData は、各イベントの get-in 価格（各マーケットプレイスにおける手数料込み再販価格の最安値）、価格履歴全体、予測、3／7／14／30 日間の変動を追跡します。この CLI はそのすべてをスクリプトから利用できるエージェントネイティブな JSON として提供し、価格の生データ系列をローカルの SQLite に保存します。そのため、stats では過去の最安値や変動率を計算でき、drift では価格の下限が目標価格まで下がったときにアラートを出し、board ではウォッチリスト全体を順位付けし、compare では最安の日付を選べます。これらはいずれもウェブサイトでは確認できません。

この CLI を使用する場面

特定のイベント、出演者、会場について、TicketData の get-in 価格、価格履歴、予測、または N 日間の変動を確認したい場合に、この CLI を使用してください。特に、イベントのセットを継続的に追跡したり、過去の価格統計を計算したり、価格下落のアラートを設定したり、イベントを比較したりする場合に適しています。すべてオフラインでスクリプトから実行できます。「このチケットは今安いか」「いつ買うべきか」「この日程の中でどれが最安か」といった質問に答えるエージェントに最適です。

使用しない場面

次の場合は、この CLI を使用しないでください。

• チケットの購入、販売、出品には使用しないでください。TicketData は価格追跡ツールであり、マーケットプレイスではありません。events get のマーケットプレイス購入リンクを使い、購入手続きを行ってください。
• カテゴリ内のすべてのイベントを閲覧したり見つけたりするためには使用しないでください。TicketData には一覧／閲覧 API がないため、この CLI では、すでに把握しているイベント ID や出演者／会場のスラッグ、または名前から解決したものを使用します。
• 一般販売でのチケット購入や座席選択には使用しないでください。マーケットプレイスまたはチケット売り場を利用してください。

独自の機能

この API で、ほかのツールでは利用できない機能です。

データを蓄積するローカル価格ストア

• watch — イベントのセットをローカルで追跡し、同期時にそれらすべての現在価格を再取得します。

  まずはこれを使いましょう。以降の処理（board、drift、stats、compare）は、CLI が同期するウォッチリストを読み取ります。

  ticketdata-pp-cli watch add 22323960
  

• board — 追跡中の全イベントを一覧にした、並べ替え可能なテーブルです。get-in 価格、N 日間の変動、予測の方向、今日の価格がそれぞれの価格履歴のどこに位置するかを確認できます。

  ウォッチリスト全体の状況を確認する場合に使用します。前回の同期から何が変わったかを確認するには drift、1 つのイベントの価格分布を確認するには stats を使用してください。

  ticketdata-pp-cli board --sort change --agent
  

• drift — 追跡中の各イベントについて、最新 2 件のスナップショットを比較し、しきい値を超えて価格下限が変動した場合に通知するとともに、価格目標への到達を通知します。

  前回の同期から何が変わったかを確認したり、「この価格になったら購入する」というアラートを設定したりする場合に使用します。

  ticketdata-pp-cli drift --threshold 10 --target 22323960=150 --agent
  

サイトのチャートでは分からない価格情報

• stats — ローカルの価格系列から、過去の最安値・最高値、中央値、現在のパーセンタイル、変動率、および通常最安値になる曜日を確認できます。

  1つのイベントについて、今日の入場最低価格が実際に安いのか、どの曜日が最安になりやすいのかを判断するのに使います。

  ticketdata-pp-cli stats 22323960 --agent
  

• compare — 複数のウォッチ対象イベント、または1人の出演者のウォッチ対象イベントすべてを、入場最低価格と変化率で順位付けします。

  最も安い都市や日付を選ぶのに使います。1つのイベントの履歴を見るには stats を使います。

  ticketdata-pp-cli compare --performer ariana-grande --agent
  

• zones — イベントの各ゾーンを、現在の入場最低価格と、各ゾーンの過去の価格からの下落幅で順位付けし、割安なセクションを見つけます。

  価格に見合ったセクションを選ぶのに使います。セクション名の一覧だけを確認するには events sections を使います。

  ticketdata-pp-cli zones 22323960 --agent
  

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

• search — 同期済みのイベント、出演者、会場を対象にローカルで全文検索し、複数の一致候補を返します。

  オフラインで一致候補を調べるのに使います。名前から正式な情報を1件だけ特定するには performers search または venues search を使います。

  ticketdata-pp-cli search "ariana" --type performers --agent
  

HTTP トランスポート

この CLI は、ブラウザー向けエンドポイントに Chrome 互換の HTTP トランスポートを使用します。通常の API 呼び出しに、常駐するブラウザープロセスは必要ありません。

コマンドリファレンス

events — チケットイベント、入場最低価格、価格履歴、セクション一覧を確認します

• ticketdata-pp-cli events get — イベントの現在の入場最低価格、予測、N 日間の変化、マーケットプレイスへのリンク、会場と出演者の詳細を取得します
• ticketdata-pp-cli events history — イベントの入場最低価格の全時系列（数百件のデータポイント）に加え、ゾーンごとの系列と販売開始日・先行販売日を取得します
• ticketdata-pp-cli events sections — イベントに登録されているセクション名を一覧表示します

performers — 出演者（アーティスト、チーム）を調べ、名前から正式な出演者ページを特定します

• ticketdata-pp-cli performers get — 出演者の統計情報（今後のイベント、入場最低価格の平均・最小・最大）と、転売・ソーシャルのリンクを取得します
• ticketdata-pp-cli performers search — 検索クエリから、最も一致する出演者を特定します

venues — 会場を調べ、名前から正式な会場ページを特定します

• ticketdata-pp-cli venues get — 会場の統計情報（今後のイベント、所在地）を取得します
• ticketdata-pp-cli venues search — 検索クエリから、最も一致する会場を特定します

適切なコマンドを見つける

何をしたいかは分かっていても、どのコマンドを使えばよいか分からない場合は、CLI に直接尋ねてください。

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

which は、自然言語の機能クエリを、この CLI の厳選された機能インデックスから最も一致するコマンドに対応付けます。終了コード 0 は1つ以上の候補が見つかったことを示し、終了コード 2 は確信を持てる候補がないことを示します。その場合は --help を使うか、より具体的なクエリを指定してください。

使用例

このチケットは今、安いですか？

ticketdata-pp-cli watch add 22323960 && ticketdata-pp-cli sync && ticketdata-pp-cli stats 22323960 --agent

イベントを追跡し、価格履歴を取得して、今日の入場最低価格がイベント自身の価格分布のどこに位置するかを確認します。

最低価格が希望額まで下がったら通知する

ticketdata-pp-cli drift --target 22323960=150 --threshold 8 --agent

目標価格に達した場合と、前回の同期以降に最低価格が8%を超えて変動した場合にフラグを立てます。

このアーティストの公演日はどれが最安ですか？

ticketdata-pp-cli compare --performer ariana-grande --agent

出演者のウォッチ対象イベントすべてを、入場最低価格と変化率で順位付けします。

エージェント向けにイベントの大きなレスポンスを絞り込む

ticketdata-pp-cli events get 22323960 --agent --select tickets.get_in_price,tickets.number_of_listings,forecast_value,price_trend.direction

ドット区切りの select パスを使って、詳細なイベントレスポンスから判断に必要なフィールドだけを取得します。

最もお得なセクションを見つける

ticketdata-pp-cli zones 22323960 --agent

イベントの各ゾーンを、現在の入場最低価格と、各ゾーンの過去の価格からの下落幅で順位付けします。

認証の設定

アカウントや API キーは不要です。TicketData の公開データ API はオープンで、この CLI は API から直接データを取得します。

ticketdata-pp-cli doctor を実行して、セットアップを確認してください。

エージェントモード

任意のコマンドに --agent を追加します。次のオプションに展開されます：--json --compact --no-input --no-color --yes。

• パイプで利用可能 — stdout には JSON、stderr にはエラーが出力されます

• フィルタリング可能 — --select でフィールドの一部を抽出できます。ドット区切りのパスはネストされた構造をたどり、配列では各要素を走査します。レスポンスの冗長な API でコンテキストを小さく保つうえで重要です：

  ticketdata-pp-cli events get mock-value --agent --select id,name,status
  

• プレビュー可能 — --dry-run を指定すると、送信せずにリクエストを表示します

• オフラインでも利用可能 — 同期／検索コマンドでは、利用可能な場合にローカルの 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> を使用するか、TICKETDATA_HOME=<dir> を設定して、4 種類すべてのパスを 1 つのルート配下に移動します。

• 特定の種類のパスだけを分ける必要がある場合に限り、種類ごとの環境変数 TICKETDATA_CONFIG_DIR、TICKETDATA_DATA_DIR、TICKETDATA_STATE_DIR、TICKETDATA_CACHE_DIR を使用します。

• 解決順序は、種類ごとの環境変数、--home、TICKETDATA_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 から移動されます。

• ticketdata-pp-cli doctor --fail-on warn を実行すると、パスと認証情報の保存場所に関する警告を確認できます。agent-context は、解決済みのディレクトリを必要とするエージェント向けに、スキーマ v4 の paths ブロックを公開します。

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

  {
    "mcpServers": {
      "ticketdata": {
        "command": "ticketdata-pp-mcp",
        "env": {
          "TICKETDATA_HOME": "/srv/ticketdata"
        }
      }
    }
  }
  

フリートでの優先順位：継承された種類ごとの環境変数は、その種類に対して明示的に指定された --home より優先されます。フリート全体で継続的に使用する設定には TICKETDATA_HOME または種類ごとの環境変数を使い、--home は 1 回の呼び出しにのみ使用してください。環境変数を解除しても、パスの移動は元に戻りません。TICKETDATA_HOME を解除する前に手動でファイルを移動してください。そうしないと、doctor は以前のルートに残された認証情報を見つけられません。

自動学習

この CLI には、学習内容を自動記録するループが組み込まれています。CLI が記録管理を行います。すべての呼び出しがローカルに記録され、誤ったフラグの後に修正した再試行を行うと flag_alias 候補が自動生成され、プレイブックのないクエリ種別で teach を実行すると、セッションの記録から playbook_candidate が自動生成されます。あなたの役割は判断だけです。まず recall を実行し、提示された候補に対応し、最終的な回答を teach で教え、修正に気づいたら playbook amend を実行します。失敗を手作業で記録する必要はありません。

ステップ 1：探索の前に recall を実行

新しいユーザーの質問について、list/search/drill コマンドを実行する前に、次を実行します：

ticketdata-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>", "ticketdata-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 `ticketdata-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.

Playbook と Notes は、リソースごとの経路とは独立しています。想起レスポンスには Playbook と Results[] のヒットの両方が含まれることがあります。両方を活用してください。Playbook は実行する手順を示し、リソースのヒットは特定のステップを短絡します。デフォルトでは mismatches をスキップしてください。コールドスタート時の予想外の挙動を調査する場合に限り、--debug-mismatches を渡します。

候補の判断に関する詳細：learnings confirm <id> は候補を登録する前に、その完全なペイロードを出力します。出力されたペイロードが、検証した挙動と一致することを確認してください。learnings reject <id> は導出シグネチャをトゥームストーン化し、同じ候補が再び表示されないようにします。エンベロープには、今対応する価値のある候補だけが含まれます。未処理の候補全体は ticketdata-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（トップレベル）：クエリ内のエンティティにルックアップ行がありませんが、同期データから取得できる可能性があります。ticketdata-pp-cli sync を実行してエンティティルックアップを更新してください。
• トップレベルの no_learnings_for_query_family：Jaccard のしきい値を超える行がテーブルにありません。純粋なコールドスタートです。

ステップ 4：回答を確定した後、必ず teach & を実行します

Teaching は無条件です。ストアで回答できなかったクエリを解決した後は、呼び出し回数のしきい値や、学習する「価値」があったかどうかの判断にかかわらず、最終的なリソースの対応関係をバックグラウンドで学習させてください。Teach はこのループの要です。Playbook のないファミリーでは Playbook の合成をトリガーし、同じ参照先を指す異なる表現は 1 つのファミリーにまとめられるため、よく似た teach によってストアが断片化するのを防ぎます。ユーザー向けのレスポンスを組み立てた後、それを出力する前に、シェルの & を付けて実行してください。そうすると呼び出しはすぐに戻ります。

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

成功時は何も出力されません。エラーは、解決済みの状態ディレクトリにある teach.log にのみ記録されます。最も具体的なリソースを teach してください。ユーザーが広範な質問をし、具体的な回答を見つけるために親レコードをたどった場合は、親ではなくリーフ ID を teach してください。CLI は想起時のエイリアス横断解決にシード済みの entity_lookups を使用するため、あるエイリアス（例：「Niners」）での teach は、別のエイリアス（例：「49ers」、「San Francisco」）を使った今後のクエリも自動的に満たします。

PII ルール：識別子を取り除いた構造的な質問を teach してください。名前、メールアドレス、電話番号、アカウント ID、その他の個人識別子を、teach するクエリやノートに含めてはいけません。CLI は teach クエリをスキャンして、明らかなメールアドレスや電話番号の形式を警告しますが、処理はブロックしません。警告に頼らず、teach する前に取り除いてください。

ステップ 5：プレイブック — オプションのフラグ、自動合成

セッションにプレイブックが「ふさわしい」かどうかを判断する必要はありません。プレイブックがないファミリーに対して teach を実行すると、セッションのジャーナルから playbook_candidate が自動合成され、次のセッションで確認または却下されます。明示的なプレイブックフラグを付けるのは、そのまま記録する価値のある手順をすでに把握している場合に限ります。CLI では見つからなかった回避策（気付かれずに破棄されるフラグ、未公開のパラメーター、ページネーションの工夫、ペイロードに関する注意点など）が該当します。統合された一度の呼び出し形式を優先してください。リソースに関する学習内容とプレイブックを、同じ teach 呼び出しで記録します。

# Common case: record both the resource learning AND the playbook in one call.
ticketdata-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).
ticketdata-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 と同様に、実行後の完了を待たずに進めます。

ticketdata-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 の取り扱い

将来の Printing Press のバージョンで、playbook amend のノートが共有知識として上流に提供される可能性があります。遡及的な削除を行わずに上流への提供を続けられるよう、ユーザーを特定できる情報を含めないでください。

• 含めてはいけないもの：ユーザーのファイルシステム上のパス、個人用の API キーやトークン、ユーザーのメールアドレス、ユーザーの GitHub ハンドル、単一ユーザーに紐付いた特定のクエリ履歴。
• 含めてもよいもの：エンドポイントの形式、未公開のフィールド名、API の注意点、確認されたスキーマの変化、CLI の仕様に対する回避策、汎用的なページネーションや再試行の方法。

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

ループの測定

ticketdata-pp-cli learnings stats は、ローカルの learn_events テーブルから、再利用率、教示からの再利用率、プレイブック解決率、候補の承認／却下数を報告します。分母がない間、率は null です。すべてこのマシン内に保持されます。この CLI でループが役に立っているかを確認するために使用してください。

学習の無効化

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

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

この CLI に何か問題があると気づいたら（あなた自身でも、エージェントでも）、記録してください。

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

エントリーは、解決済みのデータディレクトリにある feedback.jsonl にローカル保存されます。TICKETDATA_FEEDBACK_ENDPOINT が設定され、かつ --send が指定されているか、TICKETDATA_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 ステータスを標準エラー出力に記録します。

名前付きプロファイル

プロファイルは、保存されたフラグ値のセットで、呼び出しごとに再利用できます。スケジュールされたエージェントが毎回同じ設定で同じコマンドを呼び出す場合に使用します。これは HeyGen の「Beacon」パターンです。

ticketdata-pp-cli profile save briefing --json
ticketdata-pp-cli --profile briefing events get mock-value
ticketdata-pp-cli profile list --json
ticketdata-pp-cli profile show briefing
ticketdata-pp-cli profile delete briefing --yes

明示的に指定したフラグは常にプロファイルの値より優先され、プロファイルの値はデフォルトより優先されます。agent-context は available_profiles の下にすべての利用可能なプロファイルを一覧表示するため、内容を調べるエージェントは実行時にそれらを検出できます。

終了コード

コード	意味
0	成功
2	使用方法のエラー（引数が不正）
3	リソースが見つかりません
5	API エラー（上流の問題）
7	レート制限中（待ってから再試行）
10	設定エラー

引数の解析

$ARGUMENTS を解析します。

1. 空、help、または --help → ticketdata-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/ticketdata/cmd/ticketdata-pp-mcp@latest
   

2. Claude Code に登録します。

   claude mcp add ticketdata-pp-mcp -- ticketdata-pp-mcp
   

3. 確認します。claude mcp list

直接使用

1. インストールされているか確認します。which ticketdata-pp-cli 見つからない場合は、インストールを提案します（このスキルの冒頭にある前提条件を参照）。
2. ユーザーのクエリに最適なコマンドを、上記の独自機能とコマンドリファレンスから選びます。
3. --agent フラグを付けて実行します。

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

4. あいまいな場合は、サブコマンドのヘルプを確認します。ticketdata-pp-cli <command> --help