inbox-exploration

Inbox を確認する

Inbox は、PostHog がシグナルレポートを表示する場所です。シグナルレポートとは、関連する観察結果（シグナル）を、1 つの課題または傾向（例：「/checkout でエラー率が 3 倍に急上昇」）に集約したものです。レポートは、エラートラッキング、セッションリプレイ、ウェブ分析、実験、Linear、GitHub、Zendesk などの連携先といった、複数のソース製品から取得されます。

Inbox は PostHog Desktop の一部です。PostHog Desktop は、エンジニアリングチーム向けの PostHog のエージェント型インターフェースです。

ユーザーのプロジェクトにレポートがある、またはシグナルソースが設定されていると決めつけないでください。Inbox が設定されていないプロジェクトも数多くあります。ユーザーの実際の質問に答える前に、必ず以下のセットアップ確認ワークフローを実行してください。

このスキルを使う場面

• 「Inbox には何がある？」「最初に何を確認すべき？」
• 「対応が必要なレポートを表示して」「PostHog が最近フラグを付けたものは？」
• 「<トピック / 製品領域> に関するレポートはある？」
• 「このプロジェクトではどのシグナルソースが設定されている？」
• ユーザーがレポート ID または URL を貼り付けて、詳細を知りたがっている
• 「この Inbox の項目を修正して」「このレポートを PR にして」「このレポートを実装して」— ワークフロー：対応が必要なレポートに対処する を参照
• 「これを非表示にして」「このレポートをスヌーズして」「解決済みにして」「修正しました」— ワークフロー：レポートを解決、非表示、またはスヌーズする を参照
• 「これをマージして」「このレポートで提案されたプロンプトを実行して」— ワークフロー：レポートに対するアクションを実行する を参照

詳しく調査する場合は、他のスキルやツールに引き継いでください。

• signals スキル — HogQL 経由で document_embeddings をクエリしてシグナルの生テキストを取得したり、シグナルをセマンティック検索したり、レポートに寄与したすべてのシグナルを調べたりする場合に使います。
• PostHog の製品固有の MCP ツール — レポートが特定のエラー、ログ行、セッション、人物、または時間範囲を示している場合は、対応するドメインツールを使って詳細な情報を取得します。
  • エラートラッキング：エラートラッキングをソースとするレポートには、query-error-tracking-issues-list、query-error-tracking-issue、query-error-tracking-issue-events を使用します
  • ログ：課題の前後のログアクティビティを見つけるには、query-logs、logs-count-ranges を使用します
  • セッションリプレイ：影響を受けたユーザーの録画を見つけるには、query-session-recordings-list、session-recording-get を使用します
  • 人物 / アクティビティ：特定のユーザーの行動を調べるには、persons-retrieve、advanced-activity-logs-list を使用します
  • 傾向 / SQL：アドホックな検証クエリには、query-trends、execute-sql を使用します

シグナルレポートから分かるのは、PostHog が何をクラスタリングしたかです。製品固有のツールを使うと、その背後にある詳細が分かります。ユーザーが詳しく調査したい場合は、これらを組み合わせてください。

利用可能なツール

ツール	用途
inbox-reports-list	フィルター（ステータス、検索など）に対応した、ページネーション付きのレポート一覧
inbox-reports-retrieve	単一レポートの詳細全体
inbox-reports-claim	レポートの担当または担当解除を行い、任意で実装 PR を関連付けます
inbox-report-artefacts-list	レポートの作業ログ全体 — signal_finding のエビデンス、ステータス判断、コミット、タスク実行、メモ（読み取り専用）
inbox-report-artefacts-retrieve	単一アーティファクトの詳細全体（読み取り専用）
inbox-reports-set-state	単一レポートを解決（resolved）、却下（suppressed）、またはスヌーズ（potential）します
inbox-reports-bulk-set-state	1 回の呼び出しで 1～100 件のレポートに同じ状態遷移を適用します（ID ごとの結果）
inbox-report-actions-list	レポートのエージェント実行アクション（マージする、提案プロンプト）と、それぞれを今すぐ開始できるかどうか（読み取り専用）
inbox-report-actions-run	これらのアクションのいずれかを、レポートに関連付けられたバックグラウンドのエージェント実行として開始します
inbox-ranking-outcomes-list	各ランキングモデルの結果が予測する内容と、その予測期間、コホート、ベースレート（読み取り専用）
inbox-source-configs-list	設定済みのシグナルソース（受信トレイにデータを提供するプロダクト）
inbox-source-configs-retrieve	単一ソース設定のレコード全体
inbox-source-configs-partial-update	ソースの enabled フラグの切り替え（または config の調整）
posthog:execute-sql（signals skill）	基盤となるシグナルへの HogQL アクセス（先に signals スキルを読んでください）

inbox-reports-*-list / -retrieve、inbox-report-artefacts-list / -retrieve、および inbox-source-configs-*-list / -retrieve ツールは読み取り専用です。公開されている書き込み操作は、inbox-reports-set-state（単一レポートの解決／却下／スヌーズ）、 inbox-reports-bulk-set-state（1 回の呼び出しで 1～100 件のレポートに同じ状態遷移を適用）、 inbox-reports-claim（担当／担当解除／PR の関連付け）です。詳しくは Workflow: resolve, dismiss, or snooze a report を参照してください。さらに、inbox-report-actions-run（レポートアクションからエージェント実行を開始）については Workflow: run an action on a report を、また、 ソースの enabled フラグをオンまたはオフにする inbox-source-configs-partial-update もあります（例：{enabled: false} で、ソースから受信トレイへのデータ送信を停止します）。 ソースを新規作成したり、全体を置き換えたりするための -create / -update もあります。処理の一時停止は MCP では公開されていません。

用語

各レポートのステータスの意味（トリアージエージェントが対応する優先度のおおよその順）：

• ready — 判定が完了し、対応可能な評価が利用できます
• pending_input — 続行するためにユーザーからの入力を待っています
• in_progress — 要約または判定を進めています
• candidate / potential — シグナルは蓄積されていますが、まだ正式なレポートには昇格していません
• failed — 処理中にエラーが発生しました
• suppressed — インボックスから除外されており、デフォルトでは表示されません。人またはエージェントが却下したか、誰かが確認する前にジャッジが保留にしました。以下の 却下されたレポートと保留されたレポート を参照してください
• resolved — レポートが求めていた作業が完了しています。終端ステータスです。解決済みのレポートが再び昇格することはないため、再発した場合は、そのレポートにリンクされた新しいレポートが作成されます。リンクされた実装 PR のマージ時に自動で設定されるか、inbox-reports-set-state を使って直接設定します（以下のワークフローを参照）

デフォルトでは、inbox-reports-list は suppressed レポートを除外し、-is_suggested_reviewer,status,-updated_at の順に結果を並べます。まずユーザー自身が推奨レビュアーとなっているレポートが表示され、次にステータス順、最後に最終更新日時が新しい順で表示されます。フィルターの仕組みについては、ツールの入力スキーマを参照してください。

却下されたレポートと保留されたレポート

suppressed レポートには、次のいずれかの経緯があります。インボックスでは各経緯がそれぞれ別のビューに表示され、inbox-reports-list の view パラメーターでも同じように分けられます。

view	次の条件を満たす抑制済みレポートを一覧表示します	suppression_source
dismissed	人またはエージェントが却下したもの、別のレポートに統合されたもの、または PR が未マージのままクローズされたもの	dismissed
held_back	誰かが確認する前にジャッジが抑制したもの	safety_judge、not_actionable、system

抑制済みの各行には、経緯を区別するためのフィールドが 2 つあります。

• suppression_source — ステータスが suppressed でない場合は null です。
  • dismissed：誰かがレポートを削除することを選択しました。理由は dismissal_reason と dismissal_note で確認してください。
  • safety_judge：安全性ジャッジがレポートを安全でないと判定しました。
  • not_actionable：対応可能性ジャッジがレポートを対応不可と判定しました。
  • system：パイプラインが別の理由でレポートを抑制しました。却下記録もジャッジの判定もない古いレポートも、この値で表示されます。
• suppression_explanation — ソースが safety_judge または not_actionable の場合のジャッジによる説明です。それ以外のソースの場合、またはジャッジが説明を提示していない場合は null です。

人またはエージェントが判断したものは dismissed のみです。それ以外のソースは、誰にも確認されていないジャッジの判定であり、ジャッジが誤っている可能性もあります。ユーザーに、保留されたレポートをユーザー自身が非表示にしたと伝えてはいけません。

次の場合は、確認時に保留されたレポートも含めてください。

• ユーザーが、PostHog によって除外された内容や、想定していたレポートがインボックスにない理由を尋ねた場合
• ユーザーが、対応可能なキューだけでなく、インボックス全体の確認や監査を求めた場合
• レポートを登録または統合する前に、インボックス全体の状態と重複がないか確認する場合

保留されたレポートを確認するには、inbox-reports-list を {"view": "held_back"} で呼び出します。各レポートの suppression_source と suppression_explanation を表示し、ユーザーが判定を判断できるようにしてください。レポートが有効だとユーザーが判断した場合は、state: "potential" で復元します。レポートは、ジャッジが保留にする前のステータスに戻ります。ユーザーが判定に同意した場合は、dismissal_reason を指定して state: "suppressed" を呼び出します。すると、レポートは held_back から dismissed に移動します。どちらの呼び出しについても、ワークフロー：レポートを解決、却下、またはスヌーズする を参照してください。

「推奨レビュアー」の意味

レポートの is_suggested_reviewer: true は、現在の PostHog ユーザーが、そのレポートに対応するのに最も適任だとレポート調査フローによって判断された最大 3 人のうちの 1 人であることを意味します。これは、レポートがユーザー 個人にとって 重要であることを示す最も強いシグナルなので、トリアージではこの情報を重視してください。

このフラグが設定される仕組みは次のとおりです。

1. レポートを調査する際、エージェントは根本にあるシグナルに最も関連する GitHub のコミット（例：失敗したコードパスに変更を加えたコミット）を特定します。
2. それらのコミットの作成者を取得し、古いもの／関連性の高いコミットをより重く評価して、上位 3 件の GitHub ログイン名を選びます。これらはレポート上の SUGGESTED_REVIEWERS アーティファクトとして保存されます。
3. 読み込み時に、各組織メンバーに紐づく GitHub ID（ソーシャル認証または GitHub インテグレーション経由）を使って、それらの GitHub ログイン名を PostHog ユーザーに対応付けます。現在の 閲覧者の紐づけられた GitHub ログイン名がその中に含まれている場合、そのレポートの is_suggested_reviewer は true になります。PostHog の user_uuid でレビュアーを保存することもできます（スカウト、または組織メンバーを直接指定した人物によるもの）。この場合、GitHub との紐づけがなくても閲覧者と照合されます。レポートが failed の場合、および ready のレポートが not_actionable と判断された場合は、どのようなレビュアーが登録されていても、このフラグは必ず false になります。そのため、ルーティングを監査するときは suggested_reviewers を直接確認してください。

トリアージにおける実用上のポイント：

• true は「あなたがこのレポートの推奨レビュアーです」という意味です。担当者ではなく、担当者として有力な候補です。パイプラインがレビュアーを特定した場合、通常はあなたが関連コードを作成した（または最近変更した）ことを意味します。スカウトや人物が user_uuid であなたを指定した場合は、あなたが担当者だと判断したことを意味します。これは推奨であり、確定的なものではありません。
• false でも、そのレポートが無関係だとは限りません。（a）別の人がコードを担当している、（b）推奨されたログイン名がコミット履歴から取得され、その GitHub アカウントを紐づけている組織メンバーがいない（user_uuid で設定されたレビュアーにはこの問題はありません）、または（c）ソース資料が特定のリポジトリ／コミットに結び付いていない、という可能性があります。
• ユーザーが「自分は 何を確認すればよいですか？」と尋ねた場合は、is_suggested_reviewer: true のレポートを最初に提示してください。これらは、担当者の候補としてユーザーに割り当てられたレポートです。ほかのレポートは混ぜず、二次的なグループとして伝えてください。
• ユーザーに推奨レポートが ない 一方で受信トレイが空ではない場合は、「受信トレイには、あなたが最近作成したコードに紐づくものはありません」のように明確に伝えてください。リストの先頭がユーザー向けに個別化されているかのように装わないでください。

ワークフロー：空または未設定の受信トレイへの対応（最初に読む）

ユーザーがセッション中に初めて受信トレイについて尋ねた場合、または inbox-reports-list が count: 0 を返した場合は、必ずこの確認を実行してください。診断結果によって次に伝える内容が決まります。

ステップ 1 — ソース設定を確認する

inbox-source-configs-list
{ "limit": 50 }

主なケースは 3 つあります。

ケース A — ソース設定がまったくない（count: 0）

ユーザーは Inbox／シグナルのセットアップをまだ行っていません。Inbox にデータがあるかのように装わないでください。 まずシグナルソースを設定する必要があること、そしてその推奨方法は https://posthog.com/desktop から PostHog Desktop をインストールすることだと、率直に伝えてください。応答例：

プロジェクトにはまだシグナルソースが設定されていないため、Inbox は空です。Inbox には、エラートラッキング、セッションリプレイ、GitHub、Linear、Zendesk などのソースから PostHog が自動的にクラスタリングした問題や傾向が表示されます。セットアップする最も手早い方法は、PostHog Desktop をインストールすることです。接続すると、シグナルが流れ始め、翌日くらいには Inbox にレポートが表示されます。

ユーザーがセットアップについて相談したいと言わない限り、ここで終了してください。これ以上 Inbox ツールを実行しないでください。どれも結果は空になります。

ケース B — ソース設定は存在するが、すべて enabled: false

以前にソースがセットアップされましたが、現在はすべてオフになっています。今はシグナルが流れていないことを伝えてください。ユーザーに確認したうえで、inbox-source-configs-partial-update { "id": "<source_config_uuid>", "enabled": true } を使ってソースを直接再有効化できます。または、プロジェクトのシグナル設定からオンにすることもできます。レポートを探し回らないでください。残っているものはすべて古い情報です。

ケース C — 少なくとも 1 つのソース設定が enabled: true

セットアップは正常に見えます。それでも inbox-reports-list が何も返さない場合は、シグナルが流れていてもレポートにクラスタリングされるまで時間が必要だと考えられます。そのことをユーザーに伝え、有効なソースを簡潔に列挙してください（例：「GitHub とエラートラッキングが有効です」）。後で再確認するか、signals スキルに移動して未加工のシグナル量を確認することを提案してください。

ソース設定に status: "failed" がある場合は、回答でそのことを伝えてください。そのソースは現在シグナルを生成していないため、Inbox に表示される情報が少ない原因かもしれません。

ステップ 2 — その後で、ユーザーの本来の質問に進む

ステップ 1 でセットアップが正常で、少なくとも 1 件のレポートが見つかった場合は、以下のトリアージ／詳細確認／フィルタリングのワークフローに進みます。

ワークフロー：対応が必要な項目をトリアージする

ユーザーが「何を確認すればいいですか？」や「対応が必要なものはありますか？」と尋ねた場合：

ステップ 1 — 準備完了／進行中のキューを取得する

inbox-reports-list
{
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

count: 0 が返された場合は、「Inbox が空です」と伝える前に、上記の空／未設定時のワークフローに進んでください。適切な回答は、ソースが設定されているかどうかによって異なります。

レポートが担当者に割り当てられても、パイプラインのステータスはそのまま維持されるため、このキューには他のユーザーがすでに担当している作業も返されます。引き受け可能な項目を尋ねられた場合は "unclaimed": true を追加し、呼び出し元がすでに担当していて再開する可能性のある項目を一覧表示するには "assignee": "me" を追加します。

ステップ 2 — ソースと実行可能性ごとに要約する

各レポートの応答には、次の内容が含まれます。

• id、title、summary
• status、priority、actionability（注：まだ pending_input／ candidate のレポートでは null です。判定はまだ実行されていません）
• signal_count、total_weight — レポートの根拠となった証拠の量
• source_products — 根拠となったシグナルの発生元の製品
• is_suggested_reviewer — 現在のユーザーがこのレポートの推奨レビュアーかどうか （上記の「推奨レビュアーとは」を参照。該当コードの GitHub コミットの作成者情報をもとに、 紐付けられた GitHub ID を通じて PostHog ユーザーにマッピングされます）
• pull_requests — このレポートに対して PR が作成されている場合
• work_state — unclaimed、working、in_review、done のいずれか
• assignee — レポートを担当している人（ユーザー、内部タスク、または外部エージェント）。誰も担当していない場合は null です。他の人が担当しているレポートを一覧に含める際は、未着手の作業に見えないよう、その旨を明記してください。
• _posthogUrl — レポートへのクリック可能なディープリンク。応答には必ず含めてください

ユーザーがすばやく確認できるよう、結果をグループ化してください。まず is_suggested_reviewer: true のレポートを優先してください — これらは現在のユーザーが 作成したコードに関連するレポートです。その後で、残りを優先度ごとにグループ化してください。

## Inbox — 8 actionable reports

⭐ Suggested for you (1)
- Checkout error rate spiked 3× — error_tracking, 47 signals (you're a suggested reviewer)
  <_posthogUrl>

🔴 High priority (2 more)
- Session replays on /pricing show repeated rage clicks — session_replay, 12 signals
  <_posthogUrl>
…

🟠 Medium priority (4)
…

is_suggested_reviewer: true のレポートがない場合は、残りを一覧表示する前に、その旨を明示してください。該当セクションを黙って省略しないでください。

ステップ 3 — 詳細確認を提案する

最後に、明確な次のアクションを提示します。「チェックアウトエラーについて詳しく調べましょうか？」→ inbox-reports-retrieve を呼び出してレポート全体を取得し、必要に応じて signals スキルに移って 根拠となったシグナルのテキストを確認します。

ワークフロー：特定のレポートを詳しく調べる

ユーザーが Inbox の URL またはレポート ID を貼り付けた場合：

inbox-reports-retrieve
{ "id": "<report_uuid>" }

signals_at_run と artefact_count を含む完全なレコードが返されます。次に、レポートの作業ログを読み取ります。

inbox-report-artefacts-list
{ "report_id": "<report_uuid>" }

レポートの証拠（signal_finding）、ステータス／優先度／実行可能性の判定（safety_judgment、actionability_judgment、priority_judgment、 repo_selection、suggested_reviewers）、および作業ログ（commit、task_run、note）が返されます。これらをまとめた、読み取り専用の呼び出しで確認できる「存在する理由と、これまでに行われたこと」の情報です。

生のシグナルテキストが必要な場合に限り、signals スキルを使用してください。キュレーション済みの所見だけでは不十分な場合に使用します。

1. inbox-reports-retrieve を使って、レポートのメタデータと id を取得します
2. inbox-report-artefacts-list を使って、キュレーション済みの証拠、判定、作業ログを取得します
3. signals スキルの例 2（特定のレポートのすべてのシグナルを取得）を使います — HogQL クエリの metadata.report_id にレポート ID を渡します — 生の基礎シグナルテキストが必要な場合に限ります

これらのレイヤーは互いを補完します。inbox-report-artefacts-list では、キュレーション済みの判定済みビュー（証拠、判定、PR／タスク実行履歴）を確認でき、signals スキルでは、そのレポートの生成につながった生の観測内容を調査できます。

ワークフロー：実行可能なレポートに対応する

ユーザーがレポートを読むだけでなく、何か対応したい場合 — 「この Inbox 項目を修正して」「これを PR にして」「これを実装して」などです。通常、候補となるのは ready で actionability: immediately_actionable のレポートです。ここで重要な原則は、 レポートは診断であり、絶対的な事実ではありません。実装前に実際のコードと照合して確認してください。 signals_scout（および LLM による調査をソースとするもの）のレポートは、特に入念に確認する価値があります。その summary はファイル名や関数名を含む根本原因を自信たっぷりに述べていることがよくありますが、古くなっていたり、誤っていたりする可能性があります。

ステップ 1 — 取得し、既存の作業を確認して、担当する

inbox-reports-retrieve
{ "id": "<report_uuid>" }

作業を始める前に、次を確認してください。

• already_addressed — true の場合、修正がすでに進行中、またはマージ済みの可能性があります。重複して対応する前に、ユーザーに確認してください。
• pull_requests — 別の PR を作成する前に、既存の PR を確認してください。1 つの報告に、複数リポジトリにまたがる作業や PR が含まれていることがあります。
• work_state と assignee — ほかの人がすでに作業に着手しているかどうかを確認できます。引き継ぎは可能ですが、進行中の作業を見落とさず、意図的に行ってください。
• status — 完了した判断が含まれるのは ready の報告だけです。candidate / pending_input の報告はまだ調査されていません。まとまっていない概要だけを根拠に実装しないでください。

調査や実装を始める前に、報告の担当を取得してください。

posthog:inbox-reports-claim
{ "report_id": "<report_uuid>" }

返された assignee.claim_id を保存し、その後の作業更新や成果物の書き込み時に渡してください。 別のアクターから引き継ぐには takeover=true が必要です。期限切れのクレーム ID は拒否されます。 クレームは、現在の内部タスクまたは外部 MCP クライアントに紐づけられます。クレームは期限切れにならないため、修正を完了せずに作業を離れるときは、報告を却下する場合も含め、必ず報告の担当を解除してください。 解除によって所有権だけがクリアされます。紐づけられたプルリクエストは報告に残り、どのステータスからでも解除できます。そのため、却下済みの報告も解除できます。

ステップ 2 — コードを確認して診断を検証する（省略しないでください）

まず、報告の作業ログを読んでください。そこには根拠と、その根拠に基づく判断が記録されています。

inbox-report-artefacts-list
{ "report_id": "<report_uuid>" }

ここには signal_finding の根拠、ステータス／優先度／対応可能性の判断、commit / task_run の履歴が示されます。コードに手を加える前に必要な、「なぜこの報告が存在し、何がすでに行われたか」を正確に把握できます。続いて、報告の summary にファイル、関数、ときには行番号が記載されています。該当箇所を開き、記載された指摘が正しいことを確認してください。引用されたコードが存在し、報告に記載された状態のままであり、実際に記載された不具合を引き起こしていることを確かめてください。さらに詳しい確認が必要な場合は、signals スキルから元のシグナルを取得してください（metadata.report_id）。そうすれば、整理済みの所見の背後にあるシグナルのテキストを確認できます。診断が正しくない場合は、その旨を伝えて作業を中止してください。誤った報告も有用な発見です（下記の dismiss の候補になります）。推測に基づいて修正してよい理由にはなりません。作業を中止する前に、ステップ 1 で取得したクレームを解除してください。そうすれば、誰も作業していないのに進行中と表示されるのではなく、報告が未担当の状態に戻ります。

posthog:inbox-reports-claim
{ "report_id": "<report_uuid>", "claim_id": "<claim_uuid>", "release": true }

ステップ 3 — 適切なレイヤーに修正範囲を絞る

• source_products に signals_scout が含まれ、根本原因がスカウト自体の動作（実行するプロンプトや使用するしきい値など）にある場合は、ハーネスではなく、スカウトの SKILL.md を修正するほうが適切なことがよくあります。チームごとにカスタマイズされたスカウトは、このリポジトリではなくユーザーの Skills Store に置かれている点に注意してください。そのため、修正箇所がリポジトリの PR では対応できない可能性があります。ユーザーにその旨を伝えてください。
• それ以外の場合は、通常の変更と同様に対応してください。リポジトリの規約（CLAUDE.md、領域固有のスキル）に従い、変更を最小限に抑え、報告された不具合を検出できたはずの回帰テストを追加してください。

ステップ 4 — PR を作成して紐付ける

リポジトリの PR の規約に従って PR を作成し、レポートに紐付けます。

posthog:inbox-reports-claim
{
  "report_id": "<report_uuid>",
  "claim_id": "<claim_uuid>",
  "pull_requests": ["https://github.com/example/repository/pull/123"]
}

PR リンクは追加される方式で、再試行しても重複しません。完了判定でスタック全体が考慮されるよう、判明している PR をすべてまとめて送信してください。同じ PR を複数のレポートに紐付けることもできます。接続済みのリポジトリでは、状態の検証と Webhook の更新がすぐに行われます。未接続のリポジトリの PR も状態が不明なまま受け付けられるため、作業が取り込まれた後に該当するレポートを手動で解決してください。また、どちら側からでも経緯を追えるよう、PR の説明にレポートの _posthogUrl も記載してください。

PR を作成しただけでレポートを解決しないでください。 リンクされたすべての PR がクローズまたはマージされ、そのうち少なくとも 1 つがマージされると、レポートは解決されます。マージされずにすべてクローズされた場合、レポートは抑制されます。オープン、ドラフト、または状態不明の PR が 1 つでもあると、自動完了されません。PR のオープン時に手動で解決すると、まだ取り込まれていない作業が完了したと断定することになり、受信トレイを見ているレビュアーにはその違いが分かりません。手動での解決は、PR のマージでは反映されない修正（スキル本文の変更、設定の変更、NO_REPO レポートなど）に使用します。詳しくは以下のワークフローを参照してください。

ワークフロー：レポートに対してアクションを実行する

レポートでは、エージェントの実行を開始するアクションを提示できます。受信トレイにボタンとして表示されるものと同じアクションです。マージする（get_it_merged）は、レポートに関連付けられたオープンかつ承認済みのプルリクエストの CI を修正してマージし、各おすすめのプロンプト（suggested_prompt）はレポートが提案するプロンプトを 1 つ送信します。tasks-create-and-run の代わりにこれらを使用してください。ここから開始した実行はレポートに紐付き、レポートの実行一覧に表示され、レポートのタスク上限にカウントされ、レポートのコードアクセスルールが適用されます。2 つのツールはフラグの背後で段階的に公開されているため、ツール一覧に表示されない場合があります。その場合は、レポートの _posthogUrl を開いてボタンを押すよう、ユーザーに案内してください。

ステップ 1 — アクションを一覧表示する

posthog:inbox-report-actions-list
{ "report_id": "<report_uuid>" }

各アクションは、利用可能かどうかにかかわらず返されます。available: true のものを選んでください。アクションが利用できない場合は、disabled_reason に理由（承認済みのオープン PR がない、AI データ処理が承認されていない、など）が記載されています。実行を試みず、その理由をユーザーに伝えてください。text は実行時に最初のリクエストとして送られるメッセージです。エージェントに何を依頼するのかユーザーが知りたい場合は、この内容を表示してください。

ステップ 2 — 確認してから実行する

実行を開始すると、組織の利用枠を消費するタスクが作成されます。また、「マージする」ではプルリクエストがマージされる可能性があります。ユーザーが名前を挙げて依頼していないアクションを実行する前に、ユーザーに確認してください。

posthog:inbox-report-actions-run
{ "report_id": "<report_uuid>", "action": "suggested_prompt", "suggested_prompt_index": 0 }

suggested_prompt_index は suggested_prompt の場合にのみ渡し、一覧にある値を指定してください。201 が返されると、task_id、run_id、task_url が含まれます。呼び出しが成功するたびに新しいタスクが作成されるため、再試行しないでください。run_error が設定されている場合、タスクは存在しますが実行は開始されていません。エラーを報告し、2 つ目のタスクを開始しないでください。

ステップ 3 — 実行を追跡する

実行はバックグラウンドで行われます。task_id と run_id を使って tasks-runs-retrieve で追跡し、ユーザーに task_url を伝えてください。バックグラウンド実行では誰も質問に回答できないため、エージェントが判断を必要とするときは、レポートの作業ログにメモを残します。inbox-report-artefacts-list で新しいメモを読み取ってください。

エラー

すべての拒否には code が含まれます。同じ内容で再試行しないでください。

ステータス	code	対応方法
400	report_action_unavailable	このアクションは現在利用できません。相手に detail を伝えてください。
403	report_action_unavailable	組織での AI データ処理が承認されていません。管理者が設定で有効にします。
403	report_action_sandbox_refused	タスクサンドボックスではレポートアクションを開始できません。自分のセッションから開始するよう担当者に依頼してください。
409	report_action_run_active	レポートに対するマージ実行がすでに進行中です。本文の task_id と run_id を追跡してください。
429	signal_report_task_cap	レポートがタスクの上限に達しました。すでに実行されている実行を使って作業してください。
429	throttled, usage_limit_exceeded	ユーザー単位または組織単位の使用制限に達しました。制限が解除されるまでお待ちください。
402	self_driving_free_trial	組織はセルフドライビングの無料トライアル中のため、プルリクエストを作成できません。
404	なし	そのインデックスにはレポートの候補プロンプトがありません。アクションを再度一覧表示し、新しいインデックスを使用してください。

ワークフロー：レポートを解決、却下、または保留にする

3つの結果を1つのツールで処理します。根本にある問題で実際に起きたことに応じて選択してください。

問題の状態	状態	理由
あなたの作業によって修正された	resolved	終了状態です。レポートの役目を果たしました
実際には存在しない、または修正する価値がない	suppressed	理由を記録したうえで、受信トレイから除外されます
実在するが先送りされた、または別の手段で修正された	potential	パイプラインに戻り、再発した場合に再表示されます

inbox-reports-set-state
{
  "id": "<report_uuid>",
  "state": "suppressed",
  "dismissal_reason": "analysis_wrong",
  "dismissal_note": "Verified against products/foo/bar.py — the cited code path can't reach this state."
}

• state: "resolved"は、依頼された作業が完了したことを示し、終端状態です。再発した場合はこのレポートを再開するのではなく、新しいレポートが作成されます。ready／pending_input、またはアーカイブ時にそれらの状態だったsuppressedレポートから設定できます。それ以外の場合は409が返されます。**実際に完了した作業だけを解決済みにしてください。**修正を含むPRがマージされると、それだけで解決済みになります（_Step 4_を参照）。Webhookでは処理できない場合（スキル本文の編集、設定の変更、NO_REPOレポート）に限り、手動で解決済みにしてください。その場合はdismissal_reason: "fixed_outside_posthog"を記録します（プルリクエストなしで修正が反映された場合）。修正を含むプルリクエストがマージされたものの、それだけではレポートが解決されなかった場合はpr_mergedを使用します。レポートが提出される前に問題が修正されていた場合に限り、already_fixedを使用してください。自分で修正した場合にalready_fixedとstate: "potential"を組み合わせないでください。この組み合わせは「別の何かによって修正されたが、再発の可能性がある」という意味なので、レポートが再び戻ってきます。
• state: "suppressed"は受信トレイからレポートを除外します。state: "potential"はレポートをパイプラインに戻すようスヌーズします。スヌーズ時に snooze_for: <N>を設定すると、シグナルがさらにN件蓄積されるまで保留されます。
• dismissal_reasonには、サーバーで検証される正規コード（already_fixed、report_unclear、analysis_wrong、wrong_assignee、wrong_repo、wontfix_intentional、wontfix_irrelevant、fixed_outside_posthog、no_action_needed、pr_merged、other）を指定する必要があります。一覧にない値を指定すると400が返されます。特定のコードに当てはまらない場合は、otherとdismissal_noteを使用してください。dismissal_noteには自由に記述できます（4000文字以内）。どちらもDISMISSALアーティファクトとして保存されるため、後で状態を変更しても理由が残ります。**解決する場合も必ず両方を含めてください。**後から読む人に理由が伝わるようにするためです。
• wrong_repoは、エージェントが誤ったリポジトリを対象にレポートを調査したことを意味します。正しいリポジトリを示すcorrected_repository（"owner/repo"、大文字と小文字は区別されません。この理由を指定した場合に限り使用可能）と組み合わせてください。この修正内容は却下記録に残され、プロジェクトの今後のリポジトリ選択すべてに反映されます。また、指定したリポジトリがプロジェクトに接続されている場合、このレポートの次回の選択先にもなります。使用可能な修正先が指定されていない場合は、代わりにレポートの選択先がクリアされ、復元時には却下されたリポジトリを再利用せずに選択し直します。
• wrong_assigneeは、レポートが誤った担当者またはチームに届いたことを意味します。これはルーティングに関するフィードバックであり、レポート自体が誤りだという判定ではありません。
• レポートを却下、スヌーズ、または復元すると、dismissal_noteは、そのレポートを提出したスカウトへの誘導メモとしても転送されます。すべてのスカウト実行は起動時にこのメモを読み取るため、ここに書く内容によって同じレポートが再び提出されるのを防ぎます。読み手を意識し、判定だけでなく、それを確定づける証拠も記してください。解決は、レポートが役割を果たしたことを示すものであり、提出が誤りだったことを示すものではないため、メモは転送されません。メモはレポートに残ります。wrong_repoによる却下は、メモがなくても転送されます。誘導メモには、レポートが誤って対象にしたリポジトリと、指定した場合はcorrected_repositoryが記載されます。転送には、手動でスカウトメモを残す場合と同じスキル編集アクセス権が必要です。その権限がないプロジェクトでは、メモはレポートに記録されますが、スカウトには届きません。
• これは破壊的で冪等ではない状態遷移です。レポートの現在の状態から遷移できない場合は409が返されます（dismissal_reasonが正規コードでない場合は400が返されます）。抑制する前にユーザーに確認し、メモには理由を記録してください。根拠のない却下は、却下しないよりも悪い結果になります。診断が誤っていたために却下したレポート（上記のStep 2）は典型的な例です。analysis_wrongを指定し、メモに証拠を記載して抑制してください。払い戻されたレポートは凍結状態です。スヌーズと解決はいずれも、説明用のdetailとともに409／skippedを返します。
• 複数のレポートを一度に状態遷移させるには、ids配列（1～100件）を指定してinbox-reports-bulk-set-stateを使用します。各IDに同じstate／dismissal_reason／dismissal_note／corrected_repository／snooze_forが適用され、IDごとのresultsリスト（リクエスト順）と、transitioned_count／skipped_count／failed_count／not_found_countのサマリーが返されます。IDはそれぞれ独立して処理されるため、一部が失敗しても呼び出しは200を返します。状態遷移が許可されていないIDはskipped（単一レポートの場合の409に相当）となり、残りのIDは処理されます。バッチ全体が成功したと見なさず、IDごとの結果を確認してください。

ワークフロー：トピックまたはソースで絞り込む

「に関するレポートはありますか？」と聞かれたら、まずsearchを使います：

inbox-reports-list
{
  "search": "checkout",
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

searchはタイトルと概要を対象に検索します。ユーザーがキーワードではなく製品領域について尋ねている場合は、source_productを使います：

inbox-reports-list
{
  "source_product": "session_replay,error_tracking",
  "limit": 20
}

キーワード検索で有意な結果が得られない場合は、signalsスキルに引き継ぎます。embedText()を使ってシグナルのテキストを意味検索すると、キーワードフィルターでは見つからなかったレポートも見つかります。

モデルの予測を構成要素として使う

受信トレイのランキングモデルは、各レポートの結果を予測します。inbox-reports-listとinbox-reports-retrieveの各行には、予測がrankingに含まれています：

"ranking": {
  "status": "scored",
  "scored_at": "2026-10-24T05:12:00Z",
  "predictions": [
    { "outcome": "open", "probability": 0.21, "lift": 1.5, "readable": true },
    { "outcome": "action", "probability": 0.09, "lift": 1.4, "readable": true },
    { "outcome": "fix", "probability": 0.3, "lift": 2.7, "readable": true }
  ]
}

• open：人がレポートを開きます。action：人またはそのエージェントが対応します。fix：誰かがレポートに記載された問題を修正します。各結果の現在の意味、期間、ベースレートを確認するには、inbox-ranking-outcomes-listを呼び出してください。これらは提供されているモデルに準じます。
• 予測が示すのは、今後起こる可能性であり、実際に起きたことではありません。fixの確率が高くても、レポートが修正済みという意味ではありません。修正状況はstatusとPRフィールドを確認してください。
• リフトは、確率を結果のベースレートで割った値です。1.0は平均的なレポート、2.7は発生する可能性が2.7倍であることを示します。結果間の比較にはリフトを使ってください。各結果のベースレートは異なるため、確率の生値は比較できません。
• readable: falseは、学習実行でその結果のホールドアウトAUCを測定できなかったことを示します。その結果によるランキングやフィルタリングは慎重に行ってください。
• statusはscored、stale（スコアリング後にタイトルまたは概要が変更されているため、予測は変更前のテキストに基づきます）、unscored（まだスコアがなく、低スコアを意味するわけではありません）、またはnot_available（ユーザーがランキングモデルを参照できないため、モデルによる並べ替えやフィルタリングを行うと400が返されます）です。
• inbox-reports-retrieveには、予測を生成したmodelも記載されています。異なるモデルによる予測は比較できません。

使い方の例：

• 修正される可能性が高いレポート：view=actionableとordering=-ranking_fixを指定します。
• 見落とされがちな有望なレポート：priority=P3,P4とranking_min_lift=fix:2を指定します。
• おそらくノイズ：3つすべての結果でリフトが低いレポートは、重複排除または却下の候補です。対応する前に内容を確認してください。リフトの低さは手がかりであり、断定ではありません。
• どの例にもsearchまたはsource_productを追加して、トピックを絞り込めます。

ranking_min_liftとranking_min_probabilityには、カンマ区切りの<outcome>:<value>ペアを指定します。レポートはすべてのペアを満たす必要があります。未スコアおよび古いレポートは一致しません。

注意事項：

• 予測はモデルによる推定であり、上位の値は過大予測になる傾向があります。実際の確率としてではなく、ランキングやフィルタリングに使ってください。
• fixの陽性例の大半はactionの陽性例でもあります。両者を合算しないでください。

ワークフロー：設定済みのソースを確認する

ユーザーが「どのシグナルソースが設定されていますか？」または「は接続されていますか？」と尋ねた場合：

inbox-source-configs-list
{ "limit": 50 }

各エントリにはid、source_product、source_type、enabled、statusに加え、タイムスタンプが含まれます。詳細全体（記録フィルターや評価IDなど、ソースごとのconfig JSONを含む）を確認するには：

inbox-source-configs-retrieve
{ "id": "<source_config_uuid>" }

連携の認証情報は別のIntegrationモデルに保存されており、configの内容には含まれません。そのため、内容をユーザーに要約しても問題ありません。

statusフィールドは、基盤となるデータのインポートまたはワークフローの状態を示します：

• running / completed — 通常どおりシグナルを取り込んでいます
• failed — このソースは現在シグナルを生成していません。ユーザーに伝えてください

ソースを有効化または無効化するには、設定のidと{ "enabled": true | false }を指定してinbox-source-configs-partial-updateを使います。渡したフィールドだけが変更されるため、単純な切り替えにはこのツールが適しています（-updateはレコード全体を置き換え、-createは新しいソースを作成します）。ソースを有効化するとシグナルの処理と費用が発生するため、切り替える前にユーザーの確認を取ってください。

inbox-source-configs-partial-update
{ "id": "<source_config_uuid>", "enabled": false }

ヒント

• 受信トレイが空だと判断する前に、セットアップを確認してください。 inbox-reports-list が count: 0 を返した場合は、まず inbox-source-configs-list を呼び出してください。ソースがない場合、シグナルの受信を開始するにはユーザーが PostHog Desktop をインストールする必要があります。ソースはあるのにレポートがない場合は、シグナルは届いていますが、まだクラスタリングされていません
• ユーザーがレポートを開けるよう、必ず _posthogUrl を提示してください
• デフォルトの並び順では、すでにユーザーが提案したレポートが優先されています。依頼がない限り、順序を変更しないでください
• pending_input または candidate ステータスのレポートでは、priority と actionability が null になります。これは想定された動作であり、バグではありません。まだ判定が実行されていないためです
• suppressed レポートはデフォルトで除外されます。誰かが却下したレポートには view: "dismissed"、判定者が保留したレポートには view: "held_back"、両方には status: "suppressed" を指定してください。レポートが受信トレイから消えた理由を説明する前に、suppression_source を確認してください
• MCP 経由で公開されている受信トレイへの書き込み操作は、inbox-reports-set-state（レポートを1件、解決／却下／スヌーズする）、inbox-reports-bulk-set-state（同じ操作を1～100件のレポートに行う）、inbox-reports-claim（担当者として割り当てる／解除する／PRを紐付ける）、inbox-source-configs-partial-update（ソースの enabled フラグを切り替える）です。レポートに対応する（修正を実装する）には、担当者として割り当て、コードと照らし合わせて診断を検証してから、PRを作成して紐付けてください。詳しくは ワークフロー：対応可能なレポートへの対処 を参照してください。PRに紐付いた修正はPRのマージ時に自動的に解決されるため、PRを開いた時点で手動で解決しないでください。ディープリンクの _posthogUrl も必ず提示してください
• レポートの summary だけを根拠に、決して修正を実装しないでください。 レポート、特に signals_scout によるレポートはLLMによる診断です。修正を書く前に、実際のコードで、引用されているファイル／関数／動作を確認してください。裏付けのないレポートは、修正ではなく却下の候補です
• 「どのような種類のシグナルがありますか？」または「すべてのソースで最近何が起きていますか？」と尋ねられたら、signals スキルに切り替えてください。レポートレイヤーでは個々の観測結果が隠されているため、それらを見るには document_embeddings に対して HogQL を実行する必要があります
• ソース設定にはレコードごとのディープリンクがありません。プロジェクト設定からアクセスするため、inbox-source-configs-retrieve は _posthogUrl を返しません。レポートと混同しないでください