exploring-signals-scouts

Signals スカウトを調べる

スカウトとは、一定の間隔で自動的に起動し、1 つの PostHog プロジェクトを調査して、実際に提示する価値があるものを判断し、検出結果として Signals の受信トレイに出力するか、何もなかったとして終了する（これは正当な結果です）スケジュール実行されるエージェントです。PostHog には、標準スカウトの一群が付属しています。全プロダクトを対象とする汎用スカウト（signals-scout-general）に加え、各領域に特化したスカウト（エラートラッキング、ログ、AI オブザーバビリティ、実験、フィーチャーフラグ、セッションリプレイ、ウェブ分析、アンケートなど）があります。プロジェクトでは、標準スカウト以外にカスタムスカウトも使用できます。チームが作成した signals-scout-* スキル（例：-brand-mentions、-mcp-feedback）もここに表示されるため、スカウトの一覧が固定されていると思い込まないでください。プロジェクトの正式な一覧は signals-scout-config-list で確認できます。（ただし、新しく作成したスカウトは、コーディネーターの次回のティックで自動登録されるか、書き込み側の signals-scout-config-create を使って登録されるまで、設定行がありません。そのため、新しいスカウトは一覧に表示されるまで少し時間がかかる場合があります。）

このスキルでは、読み取り専用の MCP ツールのみを使って、プロジェクトのスカウトの動作とパフォーマンスを把握し、調べることができます。スカウトの作成と調整方法を解説する authoring-signals-scouts スキル、およびスカウトが報告を送る受信トレイについて解説する inbox-exploration スキルを補完する、オブザーバビリティのためのスキルです。

スカウト群について確認できる情報は 5 種類あり、それぞれに専用のツールがあります。

確認したいこと	ツール	わかること
実行されるスカウト、その頻度、実行姿勢	signals-scout-config-list	スカウトごとの 1 行：スケジュール、enabled、emit、last_run_at、description
スカウトの実際の動作（実行ごと）	signals-scout-runs-list / -retrieve	実行ごとのステータス、所要時間、実行終了時の概要、emitted_count、詳細へのリンク
実行を通じてスカウト群が学んだこと	signals-scout-scratchpad-search	チームごとの永続的なメモリ（ベースライン、ノイズ、許可リスト）
スカウトが実際に出力したもの	document_embeddings に対する execute-sql	検出結果ごとの正式な記録（重み、重大度、信頼度） — 以下を参照
スカウトがユーザーに提示したもの	inbox-reports-list	基準を満たし、受信トレイのレポートになった検出結果

状況を把握するための 6 つ目のツールは signals-scout-project-profile-get です。これは、すべてのスカウトが初回起動時に読み込む「このプロジェクトについて確かなこと」の決定論的なスナップショットです。スカウトが何も見つけられなかった場合、その理由はたいていここにあります。

出力の扱い：ファイルへの退避を前提にする

これらのツールのうち 2 つ、signals-scout-runs-list と、特に tasks-runs-session-logs-retrieve は、MCP クライアントのトークン予算を超過し、ファイルに退避されるサイズのペイロードを返すことがよくあります。これはエラーではなく、通常の動作です。呼び出しが失敗してから気づくのではなく、あらかじめ考慮しておきましょう。

• signals-scout-runs-list の limit は小さく設定してください（約 10～15）。各行には長文の summary が含まれ、実行結果はスカウト群全体を対象に新しい順で返されるため、控えめな件数でも大きなデータになります。
• セッションログはもともと大きなデータです。 1 回の実行のログは数百 KB から数 MB に及びます。call --json で取得し（保存ファイルが整形テキストではなく、本物の JSON になるため jq で処理できます）、保存したファイルはインラインで読むのではなく、jq やスクリプトで読み取ってください。
• セッションログを手作業で解析しないでください。 同梱の scripts/ が再構成を行います。詳しくは以下を参照してください。

まず確認：フリートはセットアップされていますか？

プロジェクトにスカウトがいると思い込まないでください。フリートが動作するのは、signals-scout 機能フラグの対象として登録されたチームのみです。プロジェクトには設定がない場合や、すべて無効になっている場合、スカウトがドライランのままになっている場合があります。 セッションでユーザーが初めてスカウトについて尋ねたときは、まずこれを実行してください。

signals-scout-config-list

結果を次の3つのケースに照らして読み取ってください。

設定リストはページ分割されません。{ results: [...] }（配列のみ）として返され、countフィールドはありません。結果を次の3つのケースに照らして読み取ってください。

• 空（results: []） — スカウトは登録されていません。プロジェクトはスカウトフリートの対象になっていない（または、まだ一度も確認されていない）状態です。そのまま明確に伝え、実行履歴を探し回らないでください。活動をでっち上げるのではなく、Signals のスカウト設定、または PostHog Code のオンボーディングを案内してください。

• 設定はあるが、すべてenabled: false — フリートは登録されていますが、一時停止中です。何も実行されていません。存在するスカウトと、すべてオフになっていることを伝えてください。

• enabled: trueが1つ以上ある — フリートは登録されており、そのスカウトは実行可能です。有効なスカウトごとに、run_interval_minutes（実行間隔）、emit（false = ドライラン。実行されますが、受信トレイには何も書き込みません）、およびlast_run_atを記録してください。「稼働中」と報告する前に、注意点が1つあります。実行はenabledではなく、signals-scout機能フラグによって制御されます。対象として登録された後、フラグの対象から外されたプロジェクトでは、enabled: trueの行が残っていても、コーディネーターは実行を計画しなくなります。そのため、有効なスカウトのlast_run_atが古い、またはnullである場合、スカウトがアイドル状態なのではなく、プロジェクトが対象から外れていることを示す場合がほとんどです。

  last_run_atは_ディスパッチ_の記録であり、実行された証拠ではありません。 コーディネーターは、実行時期が来たスカウトの子ワークフローを_キューに登録した_時点で、この値を更新します。ワーカーが実行を開始する前です。子ワークフローのディスパッチはファイア・アンド・フォーゲット方式なので、ワーカーが過負荷または停止中の場合、子ワークフローはキューに残り、実行が一度も開始されなくても、last_run_atはティックごとに更新され続けます。そのため、last_run_atが新しいことが意味するのは「このティックでディスパッチされた」ことであり、「実際に実行中」ではありません。 稼働状況を示す信頼できる情報は、signals-scout-runs-listにある最新の実行行です。設定のタイムスタンプと照合してください。last_run_atが新しい（数分前）にもかかわらず、そのスカウトの実行行がrun_interval_minutesを大幅に超える時間にわたって現れない場合、フリートはディスパッチしているが実行していない状態です。ワーカーの処理が滞っている、または停止している、あるいは実行が取り残されているなど、実際の信頼性の問題であり、スカウトが稼働中とは言えません。last_run_atだけを根拠に「実行中」と報告しないでください。

enabled: trueでもemit: falseのスカウトは、「スカウトが何もしていない」という誤解の最も一般的な原因です。毎回実行され、推論も行われていますが、まだ調査結果を投稿できないだけです。スカウトについて報告するときは、必ずemitの状態も伝えてください。

設定、実行、スクラッチパッドの各エントリの全フィールド、実行ステータスの値、および各要素の関連付けについては、references/scout-data-model.mdを参照してください。

ワークフロー：フリートを調査する

「どんなスカウトがいて、何をしていますか？」という質問には、まずconfig-listを実行し、次に各スカウトの最新の実行情報を加えて、ユーザーが設定だけでなく稼働状況も把握できるようにします。

1. signals-scout-config-list — 登録されているスカウトの一覧。
2. 有効なスカウトごとにsignals-scout-runs-listを実行し、skill_nameが一致する最新の実行を選びます（実行一覧はフリート全体で新しい順に返されるため、通常は1回の呼び出しで全スカウトを確認できます）。statusと、実行からどれくらい経過したかを報告してください。

ユーザーが一覧しやすいように、スカウト、実行間隔、状態、最終実行、最終結果の表にまとめ、異常な点（未実行、最終実行がエラー、長期間ドライランのままなど）があれば指摘してください。

ワークフロー：1 つのスカウトを最初から最後まで理解する

「エラートラッキングのスカウトはどのように動作していますか／調子はどうですか？」

1. 設定を読む — config-list で signals-scout-error-tracking の行を探します： スケジュール、姿勢、最終実行日時。
2. 本文を読む — posthog:llma-skill-get {"skill_name": "signals-scout-error-tracking"} は、チームの実際の指示セットを返します（標準の既定値の場合も、変更が加えられた 手編集済みの行の場合もあります）。これは、実行のたびにエージェントへ指示される内容です。 シグナルとノイズを見分ける基準、探索パターン、除外条件が含まれます。スカウトがそのように 振る舞う理由を理解するには、本文を読んでください。
3. 最近の実行を読む — runs-list で text にスキルのドメインを指定するか、 最新の実行を確認して skill_name で絞り込みます。各実行の終了時に記録される summary は、スカウトが何を調べ、どう判断したかを説明しています。
4. 記憶した内容を読む — scratchpad-search（下記参照）を使います。スカウトが書き込んだ メモリー項目から、このプロジェクトについてスカウトが把握しているベースラインとノイズが わかります。

ワークフロー：最近の実行を読む

signals-scout-runs-list は、フリート全体の最新の実行を新しい順に返します （上限は 100 件）。「最近何があったか？」を調べるときに使います。

• 期間を指定するには、date_from / date_to を使います（ISO-8601 形式。created_at の 開始日時は含み、終了日時は含みません）。さらに前の期間を調べるには、より早い日時を date_to に指定します。
• サマリーを検索するには、text を使います。各実行の終了時の summary に対して、 大文字と小文字を区別しない部分一致検索を行います。ヘッドレススカウトの重複排除にも使われ、 「チェックアウトエラーの急増をすでに調べた実行はあるか？」といった確認にも使えます。
• 出力結果で絞り込むには、emitted を使います。emitted=true は少なくとも 1 件の 検出結果を提示した実行のみを返し、emitted=false は何も検出しなかった実行のみを返します。 文章を解析せずに「実際に何かを出力した実行はどれか？」を確認する直接的な方法です。

各サマリー行には、run_id、skill_name、skill_version、status、started_at、 completed_at、emitted_count（実行が出力した検出結果の数）、emitted_finding_ids（それらの ID）、task_url（トランスクリプト全体を確認できる Tasks UI へのディープリンク）、 および文章の summary が含まれています。ユーザーに説明するときは、まず summary を 伝えてください。これはスカウト自身による平易な言葉での締めくくりです。また、詳しい推論を 確認できるよう、必ず task_url も提示してください。

ワークフロー：単一の実行を詳しく調べる

ユーザーが1回の実行の全容を知りたい場合（または実行 ID / Tasks URL を貼り付けた場合）：

signals-scout-runs-retrieve
{ "id": "<uuid>" }

フィールド名が異なる点に注意してください。runs-list は各実行の ID を run_id として返しますが、runs-retrieve では id として受け取ります。run_id の値を id に渡してください。

実行の全情報が返されます。status、started_at / completed_at（これらから実行時間を算出します）、skill_name / skill_version（何が、どの本文バージョンで実行されたか）、実行終了時の summary、emitted_count / emitted_finding_ids、および task_url です。トランスクリプト（実際のツール呼び出しや推論）はペイロードには含まれず、task_url の先にある Tasks UI にあります。すべての手順を確認したい場合は、そのリンクをユーザーに渡してください。失敗した実行では summary は空で、エラーフィールドもありません。ペイロードは一覧の行と同じように見えるため、失敗の 理由 を知るにはトランスクリプトを確認する必要があります。

そのために UI を開く必要はありません。tasks-runs-session-logs-retrieve は、実行のセッションログ（すべてのツール呼び出し、メッセージ、推論ステップ）をデータとして返します。失敗を診断するときや、会話を離れずに実行内容を正確に追跡したいときに便利です。実行の task_run_id を id として渡し、task_id も渡してください（どちらも実行の行にあります）。

生のストリームは大きく（数百 KB から数 MB）、インライン表示の上限を超えるため、call --json で取得してファイルに出力し、手作業で解析する代わりに scripts/render_run_report.py に渡してください。

⚠️ 絞り込むために exclude_types: "tool_call_update,…" を指定しないでください。 そうしたくなるかもしれません。ストリームの大部分は、増分的な tool_call_update チャンクで占められています。しかし、各ツールの実際の入力はそれらのチャンクにしかありません。ベースとなる tool_call イベントの rawInput は空で、ストリーム上の更新が入力（および最終的な rawOutput）をトークンごとに組み立てます。これらを除外すると、ツールの 名前 しか分からず、スカウトが実際に何を照会したのか分かりません。ログをすべて取得し、スクリプトで各呼び出しを再構成してください（toolCallId ごとにまとめ、最も情報量の多い rawInput を保持し、完了時の rawOutput / status を紐付けます）。

実行で何件出力されたかは、主要なフィールド emitted_count で確認できます。 emitted_count > 0 は実行によってその件数のファインディングが提示されたことを意味し、emitted_count: 0 は何も出力せずに終了したことを意味します。これを判断するために summary の文章を解析する必要はもうありません。「すでに P1 を出力済みで、再出力しなかった」のような表現は 以前の 実行について述べているため、summary に "emitted" が含まれるかどうかで判定するのは確実ではありません。一方、emitted_count は信頼できる件数です。emitted_finding_ids には、その件数に対応する finding_id が出力順に並びます。それぞれが source_id = run:<run_id>:finding:<finding_id> を持つ Signal に対応するため、実行からファインディングへの信頼できるリンクになります。実行からファインディングへのリンク、および出力されたファインディングがグループ化を経て source_product: "signals_scout" の受信トレイフィルターに入る仕組みについては、references/scout-data-model.md を参照してください。

status が complete で、summary が「ベースラインでは出力するものがない」といった内容の実行は正常な結果であり、失敗ではありません。ほとんどの実行は何も出力せずに終了するはずです。何も出力しない実行が続いても、システムが正常に機能しているのであって、壊れていると考えないでください。

ワークフロー：フリートが学習した内容を確認する

スクラッチパッドは、チームごとに保持されるフリートの永続的なメモリです。スカウトが記述する文章形式のエントリーで、今後の実行をより賢く、ノイズの少ないものにします。これを読むと、フリートがこのプロジェクトについて何を信じているかがわかります。

signals-scout-scratchpad-search
{ "text": "error_tracking" }

新しい順にエントリーを返します（最大100件）。textはcontentとkeyを大文字・小文字を区別せずに照合します。すべてを閲覧する場合はtextを省略してください。各エントリーのkeyには、学習の_種類_を示すカテゴリプレフィックスが付いています。

Prefix	Meaning
pattern:	ベースライン — このチームのデータが通常どのような形をとるか
watch:	追跡中だが、まだ発行基準に達していない進行中の問題
noise:	フリートが無視すると判断したパターン（開発専用、単一ユーザーなど）
addressed:	チームが修正した、または対応を終えた事項
dedupe:	特定の問題／フィンガープリント／検出結果の再発行を制御するゲート
allowlist:	再び表面化させないことを確認済みのエンティティ
not-in-use:	このチームが使用していない製品／サーフェス（クローズアウトメモ）
mcp-gap:	後で提起する価値があるとスカウトが気づいたツールの不足

これは共通の語彙であり、固定された一覧ではありません。スカウトは必要に応じて独自のプレフィックスや<domain>ラベルを作成します（たとえば、稼働中のフリートではwatch:が頻繁に使われています）。そのため、見慣れないプレフィックスも単なる別のカテゴリとして扱ってください。エントリー同士は[[key]]のウィキリンクで相互参照されています。キーは<prefix>:<domain>:<entity>の形式です（例：dedupe:error_tracking:019e8375-…）。

ユーザーから「なぜスカウトがXを検出しなくなったのですか？」と聞かれた場合は、スクラッチパッドでnoise:、addressed:、dedupe:、allowlist:のエントリーを検索してください。フリートが意図的に抑制するよう学習した可能性があります。正式なプレフィックスの語彙と、フリートが判断に用いる4状態の重複排除分類については、authoring-signals-scoutsスキル（references/dedupe-and-memory.md）に記載されています。

ワークフロー：スカウトが実際に発行した内容を一覧表示する

「最近フリートが発行したものは何ですか／スカウトが生成した検出結果をすべて見せてください」という場合。実行行には発行フラグも検出結果の件数もなく、文章形式のsummaryはヒューリスティックです。また、受信トレイのフィルター（下記）は、グループ化によってスカウトの検出結果が複数のソースを含むクラスターに統合されるため、情報が失われます。検出結果ごとの信頼できる記録は、document_embeddingsテーブル内の発行済みシグナルそのものです。一般的な方法であるexecute-sqlを使えば、どのチームについても照会できます。スカウトが発行すると、emit_signalはsource_product="signals_scout"のシグナルを書き込みます。スカウトの帰属情報（skill_name、finding_id、severity、confidence）はmetadata.extraに、weightとsource_idはトップレベルに記録されます。

execute-sqlで取得し、scripts/emitted_signals.pyを使って整形してください。正確なクエリはスクリプトのヘッダーにあります。行ごとに1つの検出結果が表示され、任意のスカウトの組み合わせで絞り込めます。

#   call --json execute-sql { "truncate": false, "query": "<the emitted-signals query>" }  -> emitted.txt
python scripts/emitted_signals.py --signals emitted.txt --now <ISO> [--skill mcp-feedback,general]

ここにある行は、検出結果が永続化されたという確かな証拠です。すべての発行ゲートを通過しています。ギャップを説明するときには、その逆のケースも重要です。スカウトがsummaryで「EMITTED ...」と説明していても、事前チェックゲート（その時点でのドライラン、組織によるAI処理の未承認、またはsignals_scoutソースの無効化）によって発行がひそかに破棄されたり、発行に失敗したりする場合があります。こうした結果はこのテーブルに記録されないため、発行されたと主張されているのに存在しない検出結果は、スクリプトのバグではなく、それ自体が診断情報です。各行の背後にある発行コントラクト（重みと信頼度の基準、重大度、重複排除）については、authoring-signals-scoutsスキル（references/emit-contract.md）に記載されています。実行と検出結果の関連付け、およびその制限については、references/scout-data-model.mdを参照してください。

ワークフロー：スカウトが見つけた内容を確認する

スカウトの調査結果は、受信トレイのレポートとしてユーザーに届きます。スカウトをソースとして受信トレイを絞り込みます。

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

スカウトが裏付けるレポートを見つけるには、この方法が直接的です。各調査結果は source_product="signals_scout" を付けて出力され、そのタグはグループ化を経てレポートのシグナルメタデータに引き継がれます。 また、受信トレイのフィルターは、寄与したシグナルに signals_scout が含まれるレポートをすべて残します。そのため、 表示されるのはフリートが見つけたレポートです。

結果が空でも、フリートがまだ出力していないという意味であり、フィルターが壊れているわけではありません。スカウトの基準は 厳しく、ほとんどの実行は出力せずに終了するため、静かなプロジェクトや登録したばかりのプロジェクトでは、スカウトが裏付けるレポートがゼロでも 正常であり、想定どおりです。出力された内容を実行ごとに確認するには、受信トレイではなく実行を参照してください。 signals-scout-runs-list?emitted=true には、出力のあった実行がすべて表示されます。また、各実行の emitted_count と emitted_finding_ids から、生成された調査結果の数と内容がわかります（各 finding_id は source_id = run:<run_id>:finding:<finding_id> を持つ Signal に対応します）。受信トレイを より広く確認するには、inbox-exploration スキルを使用してください（ステータス、推奨レビュアー、レポートの基になるシグナルの詳細など）。 各調査結果の出力仕様（重み、信頼度、重大度、説明文）は、 authoring-signals-scouts スキルの references/emit-contract.md に記載されています。

ワークフロー：健全性とパフォーマンスを評価する

「自分のスカウトは実際に機能していて、コストに見合っていますか？」単一の指標だけでは判断できません。一定期間の実行を通してスカウトを評価します。実行を取得し（date_from を指定して runs-list を実行）、以下の観点から判断してください。 各シグナルの読み取り方やよくある失敗パターンを含む詳細な手順は、 references/assessing-performance.md にあります。

• 実行間隔の遵守状況 — 実行はおおむね run_interval_minutes ごとに行われていますか？大きな間隔が空いている場合、コーディネーターが実行をスキップしています（無効化されている、フラグによって停止されている、または負荷の高いタイミングに上限に達している） か、あるいはディスパッチされているのに実行が作成されていません。last_run_at を使えば両者を区別できます。設定の last_run_at も古い場合、コーディネーターは実行の計画を停止しています。一方、last_run_at は新しいのに最新の実行行が数時間前のままなら、前述のディスパッチと実行の乖離です（ワーカーの処理が滞っている、または停止している、あるいは実行が取り残されている状態です）。この乖離は runs-list だけではわかりません。
• 成功率 — エラーにならず、正常な status に到達した実行はいくつありますか？エラーが続く場合、スカウトが静かなのではなく、故障しています。
• 出力率 — 出力があった実行と、何も出力せずに終了した実行の割合はいくらですか？各実行の emitted_count を直接確認するか、runs-list?emitted=true / ?emitted=false で期間を分けて確認してください。 稼働中のサーフェスで長期間ほぼゼロなら、判別条件が厳しすぎる可能性があります（または、サーフェスが実際に静かな可能性があります）。ほぼ 100% なら、通常はノイズが多すぎることを意味します。健全なスカウトのほとんどは、まれにしか出力しません。
• シグナル対ノイズ比 — 出力された内容のうち、アクションにつながる受信トレイのレポートになったものと、抑制されたものはそれぞれどのくらいですか？出力のあった各実行の emitted_finding_ids を使って実行と Signal 行を対応付け、inbox-reports-list でレポートの状態を照合してください。
• メモリーの増加 — 健全なスカウトは、時間の経過とともに pattern: / noise: / dedupe: エントリーを蓄積します。多くの実行を重ねてもスクラッチパッドが空のままなら、学習していません。

ヘルパースクリプト

このスキルには、よくある依頼に対応する 純粋なフォーマッター が scripts/ に4つ同梱されています。 ネットワーク I/O は一切行いません。これは「エージェントが取得し、スクリプトが整形する」という分担の後半を担います。 手順は常に同じです。

1. MCP を使って call --json で各ペイロードを取得し（整形済みテキスト形式ではなく、生の JSON）、 ファイルに保存します。大きなもの（runs-list、tasks-runs-session-logs-retrieve）では インライン表示の上限を超えてファイルに出力されるため、どのみち必須です。スクリプトにはそのファイルを指定できます。
2. そのファイルに対してスクリプトを実行します。

4つとも標準ライブラリのみを使う Python 3.11 以降のスクリプトで、標準出力（または --out）に プレーンテキスト を出力します。ターミナルで読みやすいよう設計されているため、.txt として保存してください。

scripts/render_run_report.py — 1つの実行を詳しく調査

1つの実行を調べる際に役立つ、詳細なレポートを生成します。ヘッダー （ステータス、所要時間、姿勢）、エージェントの説明と各ツール呼び出し および実際の入力 を 交互に示す説明付きタイムライン、実行終了時の概要、スクラッチパッドのメモが含まれます。

# fetch (note --json), saving each to a file:
#   call --json signals-scout-runs-retrieve { "id": "<run_id>" }            -> run.json
#   call --json tasks-runs-session-logs-retrieve { "id": "<task_run_id>", "task_id": "<task_id>", "offset": 0 }  -> log.json   (FULL — no exclude_types)
#   (optional) call --json signals-scout-scratchpad-search { ... }          -> mem.json
#   (optional) call --json signals-scout-config-list {}                     -> cfg.json
python scripts/render_run_report.py --run run.json --log log.json \
    --scratchpad mem.json --config cfg.json --out report.txt

モード（--mode、デフォルトは detailed）：

モード	含まれる内容	--log が必要か？
summary	ヘッダー + 姿勢 + 終了時の説明文	いいえ
detailed	+ ツール 入力 を含む説明付きタイムライン + ツール集計 + スクラッチパッド	はい
full	+ 各ツール呼び出しの（切り詰めた）出力をインライン表示	はい

その他のフラグ：--show-output（detailed モードで出力を表示）、--input-width / --output-width （切り詰め幅）、--no-art（ハリネズミのバナーを省略）、--base-url（デフォルトは us.posthog.com）。

scripts/fleet_survey.py — フリート全体を調査

一覧性の高い1つの表に、スカウト、有効状態、姿勢、実行頻度、最終実行、最終結果をまとめます。さらに、「確認する価値あり」のセクションで、未実行、ドライランのまま停止、最終実行失敗のスカウトにフラグを付けます。

#   call --json signals-scout-config-list {}                 -> cfg.json
#   (optional) call --json signals-scout-runs-list { "limit": 30 }  -> runs.json   (small limit!)
python scripts/fleet_survey.py --config cfg.json --runs runs.json --now <current-ISO-time>

経過時間の列を表示するには、現在時刻（ISO-8601 形式）を --now で渡します。emit／quiet 列は各実行の概要文に基づく ヒューリスティック です。信頼する前に概要と照らし合わせてください。

scripts/assess_health.py — 一定期間の実行に基づく健全性評価

上記の「健全性とパフォーマンスの評価」ワークフローを実装します。スカウトごとの表（実行数、成功率、emit 率、実行間隔に対する実行頻度の差、遵守状況、所要時間の中央値、メモリーの増加）に加え、すべて失敗したスカウト、タイムアウトのような失敗、実行頻度の停滞、古さ、空のスクラッチパッドにフラグを付ける「確認する価値あり」セクションが含まれます。

#   call --json signals-scout-runs-list { "limit": 100, "date_from": "<ISO>" }  -> runs.json
#   (optional) call --json signals-scout-config-list {}                          -> cfg.json
#   (optional) call --json signals-scout-scratchpad-search {}                    -> mem.json
python scripts/assess_health.py --runs runs.json --config cfg.json \
    --scratchpad mem.json --now <current-ISO-time> [--skill signals-scout-general]

--config を指定すると、実行頻度の遵守状況（想定間隔）と古さ（正確な last_run_at）を評価できます。期間内の実行記録は100行の上限により最新の実行が欠落することがあるためです。--scratchpad を指定しない場合、メモリー列は n/a と表示され、メモリーに関するフラグは付きません。emit 率は同じく概要文に基づくヒューリスティックです。シグナル対ノイズは inbox-reports-list と照合してください。

scripts/emitted_signals.py — フリートが実際に出力したすべての検出結果

「スカウトが実際に出力した内容を一覧表示する」ワークフローを実装します。検出結果ごとの信頼できる一覧（日時、スカウト、重大度、重み、信頼度、finding_id、1行の仮説）と、スカウトごとの集計（出力数、重大度の内訳、重みの範囲、最新の出力）を表示します。文章によるヒューリスティックである assess_health の出力率とは異なり、出力されたシグナルを直接読み取るため、正確です。

入力は signals-scout-* ツールではなく、document_embeddings に対する execute-sql の結果です（汎用の全チーム向け経路）。クエリ全体はスクリプトのヘッダーに記載されています。そのままコピーしてください。execute-sql はパイプ区切りのテキストテーブルを返します（call --json の場合も、そのテキストが JSON 文字列にラップされて返されます）。そのため、スクリプトはテキストを解析します。クエリでは意図的にパイプで安全に扱えるスカラー列のみを選択しています（複数行の description は除外し、hypothesis はサニタイズされています）。

#   call --json execute-sql { "truncate": false, "query": "<emitted-signals query from the header>" }  -> emitted.txt
python scripts/emitted_signals.py --signals emitted.txt --now <current-ISO-time> \
    [--skill mcp-feedback,general] [--severity P0,P1,P2] [--since <ISO>] [--sort weight] [--wide]

--skill にはカンマ区切りのセットを指定します（signals-scout- 接頭辞は省略できます）。--wide を指定すると scout_run_id が追加されるため、検出結果を出力した実行の render_run_report.py に直接つなげられます。対象範囲に関する注意点を忘れないでください。この一覧に表示されるのは永続化されたシグナルです。実行サマリーに記載されているのにここにない検出結果は、ゲートで除外された（ドライラン／AI 処理が承認されていない／ソースが無効になっている）か、失敗したものです。

ヒント

• 必ず emit の状態を明示してください。 ユーザーがスカウトの故障だと思う原因として最も多いのは、実際には「実行中だがドライラン」です。
• 問題なく何も出力されずに完了したなら成功です。 多くの実行では何も見つからないはずです。問題のない空の実行が続いても、問題として報告しないでください。
• 出力の有無は、実行の主要なフィールドです。 文章の summary を解析せずに出力された内容を見つけるには、runs-list?emitted=true で実行を直接フィルタリングするか、実行ごとの emitted_count を確認してください。source_product: "signals_scout" の受信トレイフィルターには、フリートが表示した レポート が一覧表示されます。ここで結果が空でも、フィルターが壊れているのではなく、まだ出力されていないという意味です（スカウトは高い基準を設けています）。
• 約30分かかって failed になった実行は、スカウトの故障ではなくタイムアウトであることがほとんどです。 正常に完了した実行は数分で終わります。多くの場合、スカウトが調査を深掘りしすぎて予算を使い切っています（フリートは「tight-run recipe」のスクラッチパッドエントリーを書き込んで自ら修正します）。ただし、スカウト自体は数分で実際に完了していたのに、最後の完了処理が中断されて実行が停止した、誤判定のタイムアウトもあります。セッションログ（上記）で両者を見分けられます。調査しすぎた場合は、タイムリミットまでツール呼び出しが続きます。誤判定のタイムアウトでは、それよりずっと前に動きが止まります。所要時間だけで調査しすぎたと判断しないでください。
• まず実行の summary を提示してから、全文のトランスクリプトを確認できる task_url を案内してください。 実行行の生データをそのままユーザーに提示しないでください。
• last_run_at: null は、スカウトが一度も実行されていないことを意味します。さらに調べる前に、有効になっていることとプロジェクトが登録されていることを確認してください。
• スカウトが何も出力しなかった理由を説明するには、プロジェクトプロファイルを確認してください。 signals-scout-project-profile-get で、監視対象の領域が実際に使われているかどうかを確認できます。ログがないプロジェクトのログスカウトには、行うことがありません。
• このスキルは読み取り専用です。 スカウトのスケジュール、状態、または本文を変更する場合は、authoring-signals-scouts スキルに引き継いでください。signals-scout-config-update と skills-store の編集手順が説明されています。