prioritizing-my-inbox

受信トレイの優先順位付け

活発なプロジェクトの受信トレイには、未解決のレポートが数百件、または数千件あります。 デフォルトの一覧順では、ユーザーが提案したレポートが先頭に表示され、その後、ステータスと更新日時で並べ替えられます。 この順序は、個人の優先順位を示すものではありません。 このスキルでは、その人が最初に選ぶレポートを理由とともに短いランキング形式でまとめます。

ランキングを決める入力は3つあります。

1. 今、その人がどんな状況にあるか。 activity-summary-get は、現在のテーマ、所有・ウォッチしているオブジェクト、取り組んでいるプロダクトを返します。
2. モデルが何を予測しているか。 各レポートの行には、open、action、fix の確率とリフトを含む ranking.predictions があります。
3. そのレポートで何が求められているか。 推奨レビュアー、その人が回答責任を負うクレーム、pending_input ステータス、マージ待ちの承認済みプルリクエストなどです。

出力はランキング形式であり、データをそのまま並べたものではありません。 スコアを参考にしつつ、判断を加えてください。スコアで候補を見つけ、順序はあなたが決めます。

リクエストを解析する

• N：「上位10件」「自分のトップ5」「25件」など。指定がなければ25件です。50件を超える場合は、下位の候補が薄くなることを伝え、代わりにフィルターを使うか尋ねます。
• フォーカス：テーマ、プロダクト、キーワード（「異常関連だけ」「エラートラッキング」など）。「だけ」と指定されていない限り、追加の候補プールとして扱い、優先度を上げますが、ハードフィルターにはしません。
• 除外条件：「ダイジェストを除外」「scout fleet のものは除外」「プルリクエストがあるものは除外」など。
• 期間：「今週」「今日」「月曜日以降」など。指定がなければ、過去14日以内に作成または更新されたレポートを対象にします。
• モード：「自分が修正できるもの」「自分の対応待ち」「新着だけ」など。以下の候補プールまたは優先度に対応します。

ステップ1：対象者の情報を読み込む

activity-summary-get
{}

応答から関心プロファイルを作成します。

• strength と last_seen を含むテーマ。過去3日以内に確認され、strength: high のテーマを最も重視します。
• computed.owned と computed.watched にある固有の用語：スキル名、フラグキー、保存済みクエリ名、インサイト名、ダッシュボード名。これらは一般的なテーマ語よりもレポートとの一致度が高くなります。
• computed.products.works_in と computed.pages にあるプロダクト。これらは source_product およびレポートのトピックに対応します。
• profile の最近の質問に関する行。その人が今週質問したレポートは、有力な候補です。

一般的な単語は、検索語として適していません。 活発なプロジェクトでは、要約に「ranking」という言葉が何気なく含まれているだけで、search: "ranking" が何百件ものレポートに一致することがあります。 所有しているスキル名（anomaly-metrics など）、フラグキー、テーマラベルに含まれる特徴的なフレーズなど、具体的な用語を優先してください。

呼び出しで status: not_ready が返された場合、または404の場合は、その人のサマリーがありません。 その旨を1行で伝え、ほかのシグナルを使って続けてください。 その場合、ランキングでは推奨レビュアーの割り当て、クレーム、モデルをより重視します。 その人が関心のあるトピックを2、3個挙げてもらい、それを関心プロファイルとして使うことも提案してください。

ステップ 2：候補を集める

レポートの各行は大きく（多くの場合、概要だけで 3～4 KB あります）なるため、1 ページにまとめず、複数の小さな候補群を取得してください。 呼び出しごとの limit は 20 以下にしてください。 すでに取得した ID を exclude に渡すと、後続の候補群を新鮮に保てます。 exclude に指定できる ID は最大 100 件で、それを超えるリストは API に拒否されるため、最も除外したい 100 件（現時点で最有力の候補）を渡し、残りはローカルで重複を除去してください。 候補群は重複するため、id で重複を除去し、各レポートがどの候補群に含まれていたかを記録してください。

候補群	呼び出し	理由
あなた向け	view: "for_you"、sort: "recommended"、created_after: <window>	そのユーザーに割り当てられている、そのユーザーの対応待ち、またはそのユーザーが担当中のもの
最近更新された項目	view: "for_you"、ordering: "-updated_at"、created_after なし	新しい PR の承認や質問など、最近動きのあった古いレポート
自分の担当	assignee: "mine"	そのユーザーまたはそのエージェントがすでに担当している作業
対応の可能性が高い項目	view: "actionable"、ordering: "-ranking_action"、created_after: <window>	モデルが誰かが対応すると予測する項目
新しく、開かれる可能性が高い項目	created_after: <last 3 to 7 days>、ordering: "-ranking_open"	確認する価値のある新しいレポート
テーマ検索	search: "<specific term>"、created_after: <window>。上位テーマごとに 1 回呼び出し（3～5 回、limit は 10～15）	ルーティングでは見落とされる個人的な関連性
自分の入力が必要（任意）	view: "needs_input"、scope: "for_me"、created_after: <window>	そのユーザーにしか下せない判断

すべての候補群で inbox-reports-list を使用します。 for_you と needs_input には必ず期間を指定してください。 created_after が絞り込むのは作成時刻のみです。そのため、期間より前に作成され、期間内に更新されたレポートを確認できるのは、最近更新された項目の候補群だけです。 この候補群では期間の判定に updated_at を使用します。updated_at が期間外になるまでページを取得し、3 ページを上限としてください。 assignee: "mine" には担当が期限切れにならないため期間を指定せず、数百行が返る場合があります。デフォルトの順序を維持し、最初のページだけを読んでください。 活発なプロジェクトでは、これらのビューに 1,000 件ものレポートが含まれることがあり、古い pending_input の行には強く見える古いスコアが付いています。

ランキングの ordering 値と ranking_min_* フィルターは、ランキングの段階的導入の対象外のユーザーには 400 を返します。 その場合は代わりに sort: "recommended" を使用し、レスポンスの ranker フィールドを確認して、どの順序が適用されたかを把握してください。 ユーザーが閲覧できる場合、各行には引き続き ranking.predictions が含まれるため、クライアント側でスコアを計算できます。

候補は重複を除去したうえで 60～150 件を目指してください。 受信トレイ全体を読まなくても、上位 25 件をしっかり選ぶには十分な数です。

ステップ 3：スコアを付ける

status が resolved、suppressed、failed のレポートと、work_state: done のレポートは除外します。 本人が何が壊れたのかを尋ねている場合に限り、failed を残します。 次に、各候補にスコアを付けます。 references/scoring.md に、デフォルトの計算式、各項目の理由、計算例が記載されています。 概要は次のとおりです。

score = priority_base × model_multiplier × freshness
      + interest_bonus + needs_me_bonus

• priority_base：P0 は 5、P1 は 4、P2 は 3、P3 は 2、P4 は 1、なしは 1.5 です。
• model_multiplier：ranking.status が scored で、scored_at が約 7 日以内の場合に限り、action と fix のリフトの平均値を使います。それ以外は 1.0 です。リフトが欠けている場合は低いのではなく、不明として扱います。
• freshness：過去 2 日以内に更新されたレポートを優先し、3 週間更新されていないレポートの評価を下げます。
• interest_bonus：関心プロフィールに照らし合わせます。概要よりタイトルの一致を重視します。強度が高く、最近確認されたテーマとの一致は、古いテーマとの一致より重視します。
• needs_me_bonus：担当者として提案されている、本人が対応すると表明している、本人に割り当てられた pending_input、承認済みでオープンなプルリクエストが対象です。

次に、状況に応じて判断します。

• 一連のレポートをまとめます。 日次ダイジェストを作成するスカウトは、ほぼ同じタイトル（「10 月 26 日の週次チェックアウト状況：…」「10 月 27 日の週次チェックアウト状況：…」など）のレポートを生成します。最も新しいものを残し、まとめた古いレポートの数を記載します。
• 重複をまとめます。 1 つの問題に関する 2 件のレポート（多くの場合、スカウトと GitHub ソースから 1 件ずつで、同じプルリクエストを共有）は、1 件分として扱います。両方にリンクします。
• すでに対応が完了した作業を見つけます。 pending_input レポートが、本人がすでにリリースしたもの（たとえば、ステップ 1 で呼び出したばかりのツール）を求めている場合があります。「すでに完了している可能性あり。解決しますか？」を次のステップとして、リストに残します。クリアすることにも意味があります。
• 「すでに対応済み」を考慮します。 already_addressed: true、または他の人が積極的に進めているプルリクエストは、本人がレビュー担当者でない限り、レポートの優先度を下げます。
• 多様性を保ちます。 1 つのテーマがリストの半分以上を占める場合は、そのテーマの中で優先度が最も低い項目を下げ、本人が他の領域も確認できるようにします。そのテーマだけを指定された場合は、この調整を行いません。
• 本人の対応待ちの項目を優先します。 本人のレポートに対する承認済みプルリクエストや、本人にしかできない判断は、他の人が担当する優先度の高い項目より上位になることがよくあります。

ステップ 4：リストを提示する

最初に、使用した情報を 1 行で説明します。アクティビティ概要のバージョンと見出し（短縮可）、対象プール、スコアを付けた候補の数を記載します。 次に、関連性が高い順にランキングしたリストを提示します。 各レポートについて、以下を記載します。

1. [<title>](<_posthogUrl>) · P2 · 1d · ready, PR #123 open (approved)
   Why you: activity-summary rollout theme, you're the suggested reviewer
   Model: action 9.1x · fix 4.7x
   Next: review and merge the PR

• タイトルリンク：_posthogUrl を使用します。必ず含めてください。
• 優先度、経過時間（新しいレポートは updated_at、または created_at を使用）、状態（status、work_state、プルリクエストとそのレビュー状態、他の人が担当している場合はその担当者）。
• あなたに関係する理由：順位付けにつながった主な理由を 1 つか 2 つ、わかりやすく説明します。一致したテーマや担当オブジェクトを明記します。
• モデル：action と fix のリフト（それ以外が欠けている場合は open のリフト）を記載します。空欄ではなく、「未スコア」または「スコアが古い」と記載します。リフトはモデルによる推定値なので、確率ではなく相対的な可能性として示します。
• 次のステップ：具体的なアクションを 1 つ示します。プルリクエストをレビューする、質問に答える、担当する、却下する、または読むだけにする、などです。

各項目は、短い行で 3～4 行にまとめます。 リストの後には、最大 3 行を追加します。

• まとめたもの（一連のレポート、重複）と、特筆すべき除外項目を記載します。
• 調整方法を示します。「『異常スコアリングに集中』『ダイジェストを除外』『自分で修正できる上位 10 件』と言って再ランキングできます」と案内します。
• どの項目についても詳しく確認できることを伝えます。詳しい調査、対応、解決には inbox-exploration に引き継ぎます。

本人が表を求めている場合、または N が少なく一覧で確認したい場合は、リストの代わりに表を使用します。

再ランキング

ユーザーがリクエストを調整した場合は、すでに保持している候補を再利用してください。
調整内容に、まだ取得していない候補群（新しいテーマの検索、より広い期間、保留中のレポート）が必要な場合に限り、追加で取得してください。
よくある調整の例：

ユーザーの発言	対応
「Xについてもっと」／「Xに絞って」	Xの検索候補群を追加し、Xに一致する項目を大きく加点します
「Xだけ」	Xに一致する項目だけに絞り込みます
「ダイジェストを除外」／「scout Yを除外」	タイトルのパターンまたはscout_nameで除外します
「自分で修正できるもの」	PRのないactionability: immediately_actionableのみを残し、fixの加点を重視します
「自分の対応待ちは？」	対応が必要なレポートのみを残します（該当するもののpending_input、PRの承認、自分の担当分）
「新しいものだけ」	期間を直近1～3日に設定し、created_atで並べ替えます
「モデルを無視して」	model_multiplierを1.0に設定し、その旨を伝えます

ガードレール

• このスキルは読み取り専用です。ユーザーがレポート名を指定して依頼しない限り、一覧内のレポートに対して担当者への割り当て、却下、解決、操作の実行を行わないでください。これらの手順にはinbox-explorationを使用してください。
• モデルの予測は、起こりうることを示すものです。fixの確率が高くても、レポートが修正済みとは限りません。その判断にはstatusとPR関連のフィールドを確認してください。
• アクティビティの概要を長々と引用してはいけません。これはランキングのための個人的なコンテキストです。プロフィールではなく、レポートが一致したテーマに言及してください。
• 受信トレイが空の場合、または候補群から何も返されない場合は、受信トレイが空だと伝える前に、inbox-explorationでセットアップの確認を実行してください。