mcpField
P
pp-posthog

pp-posthog

github.com/mvanhornデータ・データベース2.1k97 回インストール今日更新
リポジトリ

pp-posthog について

pp-posthog は、複数のリソース種別にまたがって PostHog のデータを照会・比較するエージェント向けスキルです。CLI は構造化 JSON を返し、フラグ、実験、LLM コスト、ユーザー、イベント、ダッシュボードを調べられます。

主な機能

  1. 01フラグ展開の健全性と依存関係の確認
  2. 02古い機能フラグの検出
  3. 03フラグのバリアント別に LLM コストを集計
  4. 04イベントプロパティの変化を検出
  5. 05実験の準備状況とダッシュボードの健全性確認

活用シーン

  1. 01フラグ展開の拡大前に回帰を確認
  2. 02整理対象のフラグを特定
  3. 03バリアント間の LLM 支出を比較
  4. 04実験とダッシュボードを監査

MCP 対応

MCP サーバーのバイナリをインストールし、Claude Code に登録できます。このスキルでは、エージェントモードで CLI を直接使う方法も説明しています。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mvanhorn/printing-press-library --skill pp-posthog

インストール後、Claude Code で/pp-posthogを入力して読み込まれたか確認します。

詳細

PostHog — Printing Press CLI

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

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

  1. Printing Press インストーラーを使ってインストールします。バイナリの保存先は、macOS/Linux では $HOME/.local/bin、Windows では %LOCALAPPDATA%\Programs\PrintingPress\bin がデフォルトです。
    npx -y @mvanhorn/printing-press-library install posthog --cli-only
    
  2. 次のコマンドで確認します:posthog-pp-cli --version
  3. このスキルを実行するエージェント/ランタイムから、報告されたインストールディレクトリに $PATH 経由でアクセスできることを確認します。

npx によるインストールが失敗した場合(Node がない、オフラインなど)は、Go を使った直接インストールに切り替えてください(Go 1.26.6 以降が必要です)。

go install github.com/mvanhorn/printing-press-library/library/developer-tools/posthog/cmd/posthog-pp-cli@latest

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

この CLI を使用する場面

エージェントのタスクで、複数のリソースタイプにまたがる PostHog データのクエリ、差分比較、または結合が必要な場合は、posthog-pp-cli を使用してください。たとえば、フラグの状態とエラーイベント、LLM のコストとバリアントのパフォーマンス、実験のエクスポージャーと有意性の比較などです。大量のデータを読み取る場合、ウェブ UI より高速で、HTML を解析しなくてもエージェントが直接利用できる構造化 JSON を出力します。

独自の機能

この API では、これらの機能を利用できる他のツールはありません。

フラグの安全性
  • flags blast-radius — フラグをアーカイブまたは名前変更する前に、そのフラグを参照するすべてのインサイト、ダッシュボード、実験、アンケートを見つけます。

    フラグをアーカイブまたは名前変更する前に使用して、ダッシュボードや実験が気付かないうちに壊れるのを防ぎます。

    posthog-pp-cli flags blast-radius --key my-checkout-v2 --json
    
  • flags rollout-health — フラグの段階的ロールアウトに対する実施可否の確信度を示します。エラー率と主要指標の変動を、フラグへのエクスポージャーと相関させます。

    フラグを 100% に引き上げる前に使用して、全体指標では見えないリグレッションを検出します。

    posthog-pp-cli flags rollout-health --key new-checkout --window 24h --agent
    
  • flags stale — N 日間評価されていないフラグを一覧表示します。蓄積する前に整理できる候補を見つけます。

    四半期ごとのフラグ整理スプリントで使用して、不要になったコードパスを安全に特定します。

    posthog-pp-cli flags stale --days 30 --json
    
LLM のオブザーバビリティ
  • llm cost-attribution — LLM の支出をフィーチャーフラグのバリアント別に分類し、コストの高いモデルバリアントが費用に見合っているかを確認します。

    実際のコンバージョンあたりのコストに基づいて、より高価な LLM バリアントを採用するか評価するときに使用します。

    posthog-pp-cli llm cost-attribution --flag model-tier --agent
    
蓄積されていくローカル状態
  • persons at-risk — コホート内で利用が途絶えかけており、最近エラーに遭遇したユーザーを、解約する前に明らかにします。

    毎週のリテンションレビューで使用して、解約が発生する前に積極的なアプローチの優先順位を決めます。

    posthog-pp-cli persons at-risk --cohort paying-users --silent-days 14 --json
    
  • events property-drift — トラッキングのリグレッション、つまり 2 つの期間の間にイベントから気付かないうちに消えたプロパティを検出します。

    デプロイ後に使用して、進行中の実験やダッシュボードを損なう、気付かれにくいスキーマ変更を検出します。

    posthog-pp-cli events property-drift checkout_completed --agent
    
  • experiments pre-check — 実験が今回のスプリント中に有意性に達するか、今すぐトラフィック調整が必要かを把握します。

    各スプリントの開始時に使用して、時間切れになる前にトラフィックの変更が必要な実験を明らかにします。

    posthog-pp-cli experiments pre-check --agent
    
  • dashboard health — 関係者との会議で指摘される前に、データの古さ、削除されたコホート、アーカイブ済みのフラグなど、壊れたダッシュボードを見つけます。

    毎週のビジネスレビュー前に使用して、データチームの信頼を損なうような、壊れたインサイトタイルを検出します。

    posthog-pp-cli dashboard health --stale-days 7 --agent
    

コマンドリファレンス

projects — プロジェクトを管理します

public-hog-function-templates — 公開 hog 関数テンプレートを管理します

  • posthog-pp-cli public-hog-function-templates — 一覧表示

user-home-settings — ユーザーのホーム設定を管理します

  • posthog-pp-cli user-home-settings partial-update — 認証済みユーザーのピン留めされたサイドバータブや、現在のチームのホームページを更新します。UUID として @me を渡します。
  • posthog-pp-cli user-home-settings retrieve — 認証済みユーザーのピン留めされたサイドバータブと、現在のチームで設定されたホームページを取得します。UUID として @me を渡します。

users — ユーザーを管理します

  • posthog-pp-cli users cancel-email-change-request-partial-update — メールアドレス変更リクエストの一部更新をキャンセルします
  • posthog-pp-cli users destroy — 削除します
  • posthog-pp-cli users list — 一覧表示します
  • posthog-pp-cli users partial-update — 認証済みユーザーのプロフィール項目または設定を 1 つ以上更新します。
  • posthog-pp-cli users request-email-verification-create — メールアドレスの確認をリクエストします
  • posthog-pp-cli users retrieve — ユーザーのプロフィールと設定を取得します。認証済みユーザーを取得するには UUID として @me を渡します。スタッフ以外の呼び出し元は……
  • posthog-pp-cli users update — 認証済みユーザーのプロフィールと設定を置き換えます。認証済みユーザーを更新するには UUID として @me を渡します。
  • posthog-pp-cli users verify-email-create — メールアドレスを確認します
適切なコマンドを見つける

実行したいことは分かっているものの、どのコマンドを使うか分からない場合は、CLI に直接問い合わせてください。

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

which は自然言語での機能クエリを、この CLI の厳選された機能インデックスから最適なコマンドに対応付けます。終了コード 0 は少なくとも 1 件一致したことを示し、終了コード 2 は確度の高い一致がないことを示します。その場合は --help に戻るか、より絞り込んだクエリを使用してください。

レシピ

アーカイブしても安全なフラグを見つける
posthog-pp-cli flags stale --days 60 --json | jq '.[].key'

60 日間評価イベントがないフラグキーを一覧表示します。安全にクリーンアップできる候補です。

ランプアップ前の安全性チェック
posthog-pp-cli flags rollout-health --key new-checkout --window 48h --agent --select flag_key,error_rate_delta,metric_delta

100% へランプアップする前に、フラグの対象ユーザーのエラー率と購入指標の変化を確認します

週次実験ブリーフィング
posthog-pp-cli experiments pre-check --json | jq '.[] | {key, winner, significance, days_remaining}'

月曜日のスタンドアップ向けに、実験を横断した事前チェックの概要を作成し、トラフィック調整が必要な実験を提示します

フラグバリアント別の LLM コスト
posthog-pp-cli llm cost-attribution --flag model-tier --since 2026-08-01 --agent --select variant,total_cost_usd,avg_cost_per_call

A/B バリアント間の LLM 支出を比較し、利用状況において GPT-4o が GPT-4o-mini を上回るか判断します

全体会議前のダッシュボード監査
posthog-pp-cli dashboard health --stale-days 7 --json | jq '.[] | select(.issues | length > 0)'

関係者向けプレゼンテーションの前に、フィルターが壊れている、またはデータが古いダッシュボードを提示します

認証設定

PostHog の個人 API キー(phx_...)を使用します。POSTHOG_API_KEY を設定するか、posthog-pp-cli auth set-token <token> を実行してください。POSTHOG_HOST を介して、US(app.posthog.com)と EU(eu.posthog.com)の両方のインスタンスに対応しています。

posthog-pp-cli doctor を実行して、設定を確認してください。

エージェントモード

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

  • パイプ可能 — stdout に JSON、stderr にエラーを出力します

  • フィルター可能 — --select でフィールドを絞り込めます。ドット区切りのパスはネストされた構造にアクセスし、配列では各要素を走査します。出力の多い API でコンテキストを小さく保つために重要です。

    posthog-pp-cli flags stale --agent --select key,days_stale
    
  • プレビュー可能 — --dry-run でリクエストを送信せずに表示します

  • オフライン対応 — sync/search コマンドは、ローカルの SQLite ストアが利用可能な場合にそれを使用できます

  • 非対話型 — プロンプトを表示せず、すべての入力をフラグで指定します

  • 明示的な再試行 — 既存の作成を成功として扱う場合に限り --idempotent を使用し、削除対象が存在しない場合を成功として扱う場合に限り --ignore-missing を使用してください

レスポンスエンベロープ

ローカルストアまたは API から読み取るコマンドは、出力を出所情報のエンベロープでラップします。

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

データには .results を解析し、ライブデータかローカルデータかを確認するには .meta.source を参照してください。人が読める N results (live) の概要は、stdout が端末の場合にのみ stderr に出力されます。パイプ経由やエージェントから利用する場合、stdout には JSON のみが出力されます。

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

この CLI について気になる点にあなた(またはエージェント)が気づいたら、記録してください。

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

エントリーはローカルの ~/.posthog-pp-cli/feedback.jsonl に保存されます。POSTHOG_FEEDBACK_ENDPOINT が設定され、かつ --send が渡されるか POSTHOG_FEEDBACK_AUTO_SEND=true が設定されていない限り、POST されることはありません。デフォルトの動作はローカルのみです。

バグ報告ではなく、意外だったことを書いてください。短く、具体的に、1 行で。それが積み重なっていきます。

出力の送信先

すべてのコマンドで --deliver <sink> を指定できます。出力は標準出力に加えて(または標準出力の代わりに)指定した送信先に送られるため、エージェントはコマンドの結果を手動でパイプ接続せずに送信先へ振り分けられます。次の 3 つの送信先に対応しています。

送信先動作
stdoutデフォルト。標準出力にのみ書き込みます
file:<path>出力を <path> にアトミックに書き込みます(一時ファイルを作成してからリネーム)
webhook:<url>出力本文を URL に POST します(--compact の場合は application/json または application/x-ndjson)

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

名前付きプロファイル

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

posthog-pp-cli profile save briefing --json
posthog-pp-cli --profile briefing flags stale
posthog-pp-cli profile list --json
posthog-pp-cli profile show briefing
posthog-pp-cli profile delete briefing --yes

明示的に指定したフラグは常にプロファイルの値より優先され、プロファイルの値はデフォルト値より優先されます。agent-context は、利用可能なすべてのプロファイルを available_profiles に一覧表示するため、情報を取得するエージェントは実行時にプロファイルを見つけられます。

終了コード

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

引数の解析

$ARGUMENTS を解析します。

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

MCP サーバーのインストール

この CLI の公開ライブラリエントリーまたはビルド済みリリースから MCP バイナリをインストールし、登録します。

claude mcp add posthog-pp-mcp -- posthog-pp-mcp

確認します:claude mcp list

直接使用

  1. インストール済みか確認します:which posthog-pp-cli 見つからない場合は、インストールを提案してください(このスキルの冒頭にある前提条件を参照)。
  2. ユーザーの質問に最適なコマンドを、上記の「独自の機能」と「コマンドリファレンス」から選びます。
  3. --agent フラグを付けて実行します:
    posthog-pp-cli <command> [subcommand] [args] --agent
    
  4. 曖昧な場合は、サブコマンドのヘルプを確認します:posthog-pp-cli <command> --help。

コメント