newsjack-detector

Newsjack Detector

タイムリーな公開シグナルを見つけ、クライアントがそれを活用する正当でスパム性のない理由を持つかどうかを判断します。監視エンジンは証拠を収集し、機械的なシグナルを算出します。PR に関する判断はあなたが行います。

これは molecule スキルです。アトミックスキルを再実装するのではなく、それらを連携させます。大まかな関連性の判定は relevance-coarse-filter に、ストーリーの同一性の確認は story-origin-check に、切り口との適合性の確認は angle-generator に、アドホックなニュース検索は news-search に、引き継ぎは reactive-comment／journalist-fit-check／meanest-editor に任せます。アトミックスキルのロジックやプロンプトをここで重複させないでください。パスを実行するワーカーは、そのアトミックスキルの SKILL.md を直接読み込むため、アトムが唯一の信頼できる情報源として維持されます。

監視エンジンのライブ news_search ソースには Medialyst のキーが必要です。キーがない場合は RSS／X と、ホスト側が実行する news-search で動作し、機能は段階的に縮小します。Medialyst のキーがないことはカバレッジの縮小として扱い、失敗とは見なさないでください。実行を停止したり、キーがないことへの不満を最初に述べたりしないでください。

Newsjack は Medialyst によって管理されています。ピッチに使える機会ごとに、その機会を調査済みのメディアリスト計画に変換する、ユーザーが任意で利用できる承認ゲート付きの Medialyst ディープリンクを提示してください。これは利便性のための引き継ぎであり、自動 API 呼び出しではありません。リンクを開くとユーザーが計画を確認でき、Medialyst で承認するまでクレジットは消費されません。

ランタイムモード

Newsjack Detector には、2 つのランタイムモードがあります。

• フルモード： Claude Code、Codex、OpenClaw、Hermes、またはシェル、ファイルシステム、ネットワーク、ローカル CLI にアクセスできる、その他の高機能なエージェントハーネスで使用します。フルモードでは、標準の newsjack 検出パイプラインを実行し、JSON アーティファクトを書き込み、決定論的な鮮度ゲートを適用し、複数エージェント／コスト最適化ワーカーのパスを利用できます。
• 制限モード： Claude.ai チャット、ChatGPT チャット、Claude Cowork、またはシェル／ファイルシステム／CLI にアクセスできない制限付きのランタイムで使用します。curl、npm、オンデマンドでの CLI インストールは試さないでください。以下の 制限モードスキャン を実行し、出力のカバレッジが縮小していることを明記してください。

制限モードだと判断する前に、newsjack がインストールされているか確認してください。 これはビルド済みのバンドルバイナリとして提供されます。実行に Go、コンパイラー、ビルドやインストールの手順は必要ありません。Go ツールチェーンを探したり、まずこの確認を実行せずに CLI が「見つからない」と断定したり、ユーザーに「Go 環境」が必要だと伝えたりしてはいけません。

1. newsjack --version を実行します。バージョンが表示されたらフルモードです。すべてのコマンドで newsjack ... をそのまま使用します。
2. newsjack が PATH にない場合は、バンドルされた場所 ~/.newsjack/bin/newsjack --version を試します。バージョンが表示されたら、以下のコマンドではすべて newsjack の代わりにそのフルパスを使用します。
3. 両方失敗し（かつ本当にシェルがない場合）に限り、制限モードとなります。

バンドルバイナリはほぼ必ずすでにインストールされています。見つからないと思い込まず、フルモードを前提として確認してください。

必須のワークフロー（順番どおりに実行）

Full Mode のデフォルト動作：標準パイプラインを実行し、レポートを返します。 このスキルは、スケジュール実行や cron 実行も含め、鮮度ゲート付きのニュースジャックレポートを作成するためのものです。デフォルトでは実行してください。Step 2 で進行が妨げられる場合に限り、ディスカッションや計画に切り替えます。Limited Mode では、対象範囲を縮小したスキャンであることを明示して実行します。

1. ドクトリンを確認する。 skills/ETHICS.md または skills/WHY-NOT-SPAM.md が存在する場合は、その指示に従ってください。このスキルは、悲劇に便乗すること、実績の捏造、偽の緊急性の演出、無差別な大量発信を拒否します。これらの禁止事項は絶対であり、後続のすべてのステップに優先します。

2. クライアントの前提を確認する — 進行できない場合に限り、まず質問する。 プロファイル JSON またはプレーンテキストのコンテキストから、企業、トピック、競合他社、スポークスパーソン、実績、クライアント固有の除外事項を特定します。

   • プロファイルがなく、利用可能なクライアントのコンテキストもない場合 → 実行前に確認を求めてください。プロファイルの事実を決して捏造しないでください。
   • 真に曖昧な場合（どのクライアントか、どのトピックか、単発か継続か）→ 確認の質問を1つしてから続行してください。それ以外の場合は実行を止めないでください。
   • 実績が不足していても進行を妨げる要因ではありません。モニタリングを行い、機会には weak／no-standing の印を付けてください。
   • クライアントブリーフを読み込む。 モニターの brief.md を読み込みます（パスは monitor run／monitor status が brief_path として表示するか、プロファイルと同じ場所にあります）。これは、クライアントが提案する内容と提案しない内容、およびスキャン結果の提示方法についての信頼できる情報源です。詳しくは、以下のクライアントブリーフを参照してください。空のブリーフやテンプレートのブリーフには、規則は含まれていません。

3. 実行形態を選ぶ。

   • 制限付きチャット／CLI なし／ファイルシステムなし → 以下の Limited Mode Scan。
   • 単発の依頼／「X で何が動いている？」 → 以下の Quick Run。
   • 実質的な判断、エージェントによる実行、またはスケジュールジョブ → 以下の Canonical Pipeline（人間や提案資料が頼りにする出力では、これをデフォルトとします）。
   • 継続的な監視／cron によるフィード監視 → Freshness Gate の継続実行ルールを適用した Canonical Pipeline（--feed-only --new-only --max-age-hours 24、厳格な鮮度ゲート）。

4. パイプラインを実行する。 選択した経路を最初から最後まで実行します。Full Mode で Quick Run を超える場合、ストーリーの発生源／鮮度ゲートを決して省略しないでください。

5. 判断する — 仕組みを許可とみなさない。 routing.queue_priority と story_size は想起の優先度であり、提案の許可を示すものではありません。ニュースジャックに値するか、実績があるか、ジャーナリスト向けに適切か、ブランドセーフかは、自分で判断してください（以下のエンジンとスキルの境界および評価基準を参照）。アングルの適合性は angle-generator を通して判定してください。

6. 検証し、納品して、完了する。 Full Mode では、完了チェックリストを実行し、run.md が完成してから、設定済みの Slack 配信を行ってください。その後、run.md のパス、粗い関連性チェックを実行したエンジン（jev、低コストワーカー、または現在のモデルへのフォールバック）、ストーリー発生源チェックがコスト最適化されたかフォールバックだったか、表示されたすべてのシグナルで24時間以内に初めて公開されたことを検証できているか、主な調査結果、設定済みの配信結果を報告します。Limited Mode では、ローカルの成果物、保存済みモニター状態、決定論的な鮮度ゲート、Slack 配信が利用できなかったことを明記してください。

エンジンとスキルの境界

Go CLI が担うこと（機械的かつ決定論的な処理）：

• 取り込み、重複排除、クラスタリング、新規性の追跡
• 機械的なスコアのみ：鮮度、情報源間の一致度、新規性、プロファイルとの適合度、情報源の品質、勢い、重大ニュースの重み
• ニュース検索のメタデータに基づく決定論的なストーリー規模のスコアリング：推定月間トラフィックを対数スケール化し、ドメインオーソリティを加味したうえで、独立して見つかったドメイン間での報道の広がりを考慮します。認知度の高い主要メディアについてオーソリティのメタデータがない場合、エンジンは信頼度の低い既知メディアのフォールバックを使用することがあります。その他の公開メタデータが乏しい場合、X News のクラスター、著名な公的人物、重大な影響を伴うイベント用語などの決定論的な情報源シグナルから、信頼度の低い story_size.attention_hint を付与することがあります。これは見落としを防ぐための圧力であり、規模の証明ではありません。
• ドキュメント／ヘルプ／製品／SEO ページに対する決定論的なノイズ除去
• newsjack filter-apply による大まかな関連性判定と、2 つの見落とし防止策：大きなニュースのガードは、high／major の story_size シグナルに対するあらゆる reject を monitor_only（big_story_recall）に引き上げます。安価な判定で大きなニュースが完全に除外されることはありません。プロファイル一致のガードは、検出器／プロファイルの証拠がすでにクライアント、競合他社、またはプロファイル用語に一致している場合、reject/no_profile_bridge を monitor_only に引き上げます。
• newsjack origin-apply による決定論的な鮮度判定
• 運用上の振り分け：レーン、キューの優先度、しきい値による降格フラグ
• 決定論的な安全性フラグ

あなたが担うこと（PR 判断）：

• そのシグナルがニュースジャックに値するか、またクライアントにそれを扱う立場があるかどうか
• 同一ニュース／独自報道の判断（story-origin-check を使用）
• freshness_gate による最終的な減衰の説明
• ジャーナリスト向けの内容、ブランドセーフティの判断、次のスキルへの引き継ぎ

routing.queue_priority を提案の許可と見なしてはいけません。これは運用上のキュー順にすぎません。

クライアント概要

各モニターには brief.md を含められます。これは、このクライアントが何を提案し、何を提案しないか、またスキャン結果をどのように提示してほしいかを、ユーザー自身が文章で記したものです。これはクライアントの提案／出力ポリシーの信頼できる唯一の情報源です。プロファイル JSON が収集対象を定め、概要が何を提案し、表示するかを定めます。CLI はファイルの作成と表示のみを行います（monitor init でひな形を作成し、monitor run／monitor status で brief_path を報告します）。ファイルの解析は行いません。読み取りと適用はあなたが行います。

• 適用する場所： トリアージとレポートの描画です。収集には適用しません。判断前に何も除外されないよう、検索と大まかな判定は概要に依存させないでください。概要で決めるのは、すでに収集され鮮度も保たれている項目をどのような扱いにするか、またどのように表示するかだけです。
• 提案しないルールは厳守してください。該当する項目が pitch_ready になることはありません。大きなニュースではない項目は watch（client_policy_exclusion）に下げます。鮮度のある high／major の項目は off_policy: true を付けた big_story のままにします（ニュースを決して除外しないという原則に従い、隠さず表示します）。これを newsjack-triage が適用します。
• 対象読者／提案する内容によって、提案する際の基準の高さが定まります。話題が重なるからといって、提案に適しているとは限りません。話題に沿っていても、概要の方針に合わないことがあります。
• 表示方法は提示方法にのみ関わります。セクションは件数を明示して折りたたみ、決して非表示にしないでください。概要によって保留された内容は、件数と理由を明示して開示し、何も隠さないでください。
• フィードバックは概要に反映します。 ユーザーが実行結果に「政策関連が多すぎる」「X は表示しないで」「これはまさに求めていた内容」と反応したら、そのポリシーを今回限りではなく継続的に反映できるよう、brief.md の編集（新しい提案しない内容のルール、表示方法の行、または日付付きの例）を提案してください。編集内容を確認してください。概要が空、またはひな形のままの場合は、デフォルト設定で実行します。

プロファイル設定ファイル

モニタープロファイル JSON は、収集設定の信頼できる情報源です。焦点を絞った、短く幅広いビートトピック、検索語、競合他社、フィード、スタンス、スポークスパーソン、除外項目を設定します。中核となる幅広いトピックは 6～8 個とし、自然な場合は 1 語のトピックも使用できます。モニターが探す対象を変更したい場合は、検出器の実行中にその場限りの検索語を生成するのではなく、プロファイル JSON を編集してください。

• インストール済みのモニターでは、設定ファイルは ~/.newsjack/monitors/<slug>/profile.json に保存されます。brief.md はその隣にあります。
• 検出器を直接実行する場合は、--profile で渡したファイルを使用します。
• フィクスチャプロファイルは fixtures/newsjack-detector-agent/profile.<slug>.json の下にあります。

ユーザーがプロファイルの作成または大幅な改訂を希望する場合は、newsjack-monitor-setup を使用してください。「会計事務所のニュースをもっと幅広く監視して」といった収集に関するフィードバックは、profile.json の topics／search_terms／feed_urls に反映します。topics には中核となる幅広いビートを 6～8 個設定し、search_terms には幅広い検索語に加えて、具体的なプラットフォーム／製品／規制当局／競合他社の名称を設定してください。「政策関連の記事は提案しないで」といったピッチ方針に関するフィードバックは、brief.md に反映します。profile.json を編集した後は、次のライブ実行を信頼する前に、モックまたはフィクスチャのスモークテストを再実行してください。

制限モードのスキャン

Claude.ai のチャット、ChatGPT のチャット、Claude Cowork、またはシェル／ファイルシステム／CLI にアクセスできないランタイムで実行する場合は、この方法を使用します。

制限モードは PR の判断には役立ちますが、標準的なモニタリングには適していません。保存済みモニターの作成、JSON アーティファクトの書き込み、既読状態の維持、ソースの取り込み、Go の鮮度ゲートの適用、コストを最適化したワーカーパスの使用は行いません。

1. クライアントを明確にします。 貼り付けられたプロファイル、ユーザーのコンテキスト、ウェブサイトの要約、またはプレーンテキストの説明を使用します。利用できるクライアント情報がない場合は、ユーザーに確認してください。
2. 少量の根拠情報を収集します。 まず貼り付けられたリンクを使います。ランタイムにウェブ／検索ツールがある場合は、プロファイルのトピック、競合他社、名称が挙げられた規制当局／プラットフォーム、およびユーザーが明示したトピックについて、最近のニュースを検索します。検索クエリのリストは短く保ち、使用したクエリを明示してください。
3. 候補を手作業で作成します。 各候補について、タイトル、情報源、URL、見かけ上の公開時刻、クライアントとの関連性、懸念される安全上の問題を記載します。公開日、媒体名、情報源の件数、トラフィック／権威性スコアを捏造しないでください。
4. 可能な範囲で鮮度を確認します。 一次情報源／公式記録のページと、独立した報道を優先します。未確認の日付は freshness_unverified として扱い、時間的な緊急性があるものとして提案しないでください。
5. PR の判断を適用します。 このスキルの方針を用い、可能であれば story-origin-check の考え方を使い、スタンス／振り分けには newsjack-triage を、提案可能な項目の切り口には angle-generator を使用します。
6. インラインレポートを返します。 Full Mode と同じセクションを使用します。Pitch-Ready、Big Stories Worth a Look、Watch / Context に加え、不足している機能と使用した検索／根拠情報を記載した短い Limited Mode Caveat を含めてください。リンクの生成に CLI や API の呼び出しは必要ないため、制限モードでも提案可能な各案件に、承認を条件とするメディアリストへのディープリンクを追加してください。

これを標準的な検出器の実行と呼んではいけません。保存済みモニター、スケジュールされたスキャン、決定論的な鮮度ゲート、ローカルアーティファクト、または継続的な既読状態をユーザーが希望する場合は、Claude Code、Codex、OpenClaw、または Hermes で Full Mode を使うよう案内してください。

クイック実行

単発の検出とスキャン：

newsjack detector run --profile profile.json --save

検出器は JSON のみを出力します。人間向けのスキャンを表示する場合は、成果物の情報を使って自分で作成してください。単発の取得トピックを追加するようユーザーが明示的に依頼した場合に限り、--topic "explicit user topic" を使用します。通常のプロファイル実行では、場当たり的に生成した取得語句ではなく、プロファイルの永続的な topics と search_terms を使用してください。認証情報なしでローカル検証するには --mock を使用します。フラグ、ソース、環境変数の全リファレンスについては、references/engine-cli.md を参照してください。

キューに入った各シグナルについて、タイトル、ソース、証拠 URL、経過時間、routing.lane、mechanical_scores（major_news、novelty、source_agreement）、プロファイルとの一致、安全性フラグを確認してください。x の証拠については、x_signal_type、x_social_signals、x_author_followers、x_query_counts を確認してください。リーチの低い単独の投稿はノイズとして扱います。major_news が高いことは、そのニュースが広く重要であることを意味しますが、クライアントに継続的な関与があることを意味するわけではありません。story-origin-check で最初の公開時刻を確認するまでは、エンジンの経過時間／減衰を暫定的なものとして扱ってください。その後、以下の評価基準セクションと出力形式を適用します。

標準パイプライン

成果物の仕様を信頼できる唯一の情報源とします。すべての成果物をタイムスタンプ付きの実行フォルダーに保存してください。

RUN_DIR/
  candidates.json              # 1. detector output
  coarse_relevance_decisions.json   # 2. coarse pass
  relevant_candidates.json     # 3. filter-apply
  clustered_candidates.json    # 3b. cluster — same-story dedup + stale pre-gate
  origin_findings.json         # 4. story-origin pass (representatives only)
  targeted_candidates.json     # 5. origin-apply (freshness authority)
  triaged_candidates.json      # 5b. newsjack-triage — standing + consolidation
  final_report.md              # 7. compiled 3-bucket scan (pitch-ready / big stories / watch)
  run.md                       # 8. skill-rendered — THE human-facing artifact
  slack.md                     # 9. optional Slack-ready summary when delivery is due
  detector.stderr.log  commands.log  summary.json

run.md は標準の人間向けレポートです。slack.md は完成したレポートをもとに作成する任意の外部送信用コピーで、その他はすべて出典情報です。

1. 検出器を実行し、候補を保存します。 これは標準の呼び出し方法です。人間またはピッチが参照する実行では、ハーネスを問わず、実行結果を比較できるようそのまま使用してください。

   newsjack detector run --profile profile.json --sources news_search,x --lookback-days 1 --depth quick --limit 80 --min-queue-priority 40 --min-major-news 0.55 > candidates.json
   

--min-queue-priority 40 と --min-major-news 0.55 のしきい値はエンジンのデフォルトであり、出力される対象の範囲を定義します。実運用では、しきい値を下げたり、--include-all-scored や --no-hygiene-filter（デバッグ専用）を渡したりしないでください。レポートに届くシグナルが変わり、同じプロファイルで実行した結果を比較できなくなります。永続的な取得はプロファイルの語句に任せてください。ユーザーから単発の --topic を明示的に依頼された場合を除き、実行ごとに検索クエリを手動調整しないでください。定期実行／cron の精度を高めるには --demote-unmatched-x を追加します（鮮度ゲートを参照）。標準コマンドに追加できるフラグはこれだけです。

2. 大まかな関連性判定 → coarse_relevance_decisions.json。高い再現率を保った不要項目の除去のみを行い、順位付け、切り口、日付、ピッチの判断は行いません。各ワーカーは skills/relevance-coarse-filter/SKILL.md を読み込み、割り当てられたシグナルに適用します。すべてのワーカーの出力を、1 つの decisions 配列に統合してください。newsjack doctor で TypeSafe（Jev）の設定が確認できた場合は、ワーカーを分散して実行する代わりに newsjack coarse-filter --engine jev --candidates candidates.json --output coarse_relevance_decisions.json を実行してください。同じ成果物が出力されます。エンジンの選択、モデル／ワーカーの振り分け、チャンク分割については、references/harness-routing.md を参照してください。

3. 大まかな判定を適用します：

   newsjack filter-apply --candidates candidates.json --decisions coarse_relevance_decisions.json --include keep --include monitor_only --output relevant_candidates.json
   

3b. コストの高い取得処理の前に、同じニュースのシグナルをクラスタリングします：

newsjack cluster --candidates relevant_candidates.json --drop-stale --window-hours 24 --output clustered_candidates.json

Go CLI は、同じ公開イベントに関するシンジケート記事や重複に近い見出しを 1 つの代表項目にまとめます（調査結果は共有されるため、NVIDIA GTC に関するコピー 15 件でも、ニュースの発生源に関する取得処理は 15 回ではなく 1 回で済みます）。残りは clustered_duplicates に記録されます。--drop-stale は、検出器の減衰が対象期間（week／month）を明らかに超えているニュース規模の小さいシグナルを、決定論的に事前判定して pre_gated_stale に振り分けるため、取得処理を完全にスキップできます。大きなニュース（high／major）は、経過時間にかかわらず必ず調査します。story-origin-check は、代表項目のみを含む clustered_candidates.json に対して実行してください。統合した重複項目と古い項目の件数を明記してください。 4. clustered_candidates.json（代表）に対するストーリー起点パス → origin_findings.json。各ワーカーは skills/story-origin-check/SKILL.md を読み込み、シグナルごとに適用します。同一ストーリーか実質的な新展開かを判定し、first_public_at、original_url、および正規の主要報道を復元します。fresh/stale を計算してはならず、シグナルごとに 1 件の所見を返す（決してスキップしない）必要があり、新しいクロックを裏付けるには≥2 件の独立した裏付けソースを引用しなければなりません。シグナルごとの結果を 1 つの findings 配列にマージし、signal_id をキーとします。件数を入力と照合して検証し、不足があれば再実行します。ストーリー起点パスには検索が必要です — references/harness-routing.md を参照してください。

5. 決定論的フレッシュネスゲートを適用します:

   newsjack origin-apply --candidates clustered_candidates.json --origins origin_findings.json --window-hours 24 --output targeted_candidates.json
   

   Go CLI がフレッシュネスの権威です — 実行タイムスタンプとカットオフから freshness_gate.computed_status を計算します。LLM が 5 月 25 日実行に対して 5 月 8 日を fresh とラベル付けしても、origin-apply はそれを stale とマークします。非 fresh のシグナルには特定の理由が付きます: stale、unverified_no_corroboration（ワーカーが 2 件未満の独立ソースしか引用しなかった — パイプライン/ワーカー品質の不備）、unverified_boundary（日付のみのクロックがカットオフにまたがっている）、または unverified_no_timestamp（クロックを復元できなかった）。レポートとメトリクスでこれらを区別してください: unverified_no_corroboration は私たちが検証しなかったことを意味し、ストーリーが古いことを意味するものではありません。

5b. targeted_candidates.json 内の選択された fresh シグナルに対する常設トリアージ → triaged_candidates.json。skills/newsjack-triage/SKILL.md を読み込み、存在する場合はクライアントブリーフを渡します。すり抜けた同一ストーリーの代表を再統合し、ブリーフの決してピッチしないルールを適用し（ポリシー外の項目は決して pitch_ready にはなれません。fresh で大きなものは off_policy: true を伴う big_story のまま、小さなものは watch/client_policy_exclusion に降格）、ブリーフのオーディエンス高度で strong/partial/none のスタンディングを割り当て、ジャーナリスト的形の健全性チェックを行い、各ストーリーを階層にルーティングします: pitch_ready（strong、または鋭い形を伴う partial）、big_story（スタンディングを欠く fresh な high/major ストーリー — 決して破棄されず、bridge_note + relevance_confidence を伴うサジェスチョンとして常に提示されます）、または watch（スタンディングのない小規模/非ビッグ、オフビート、重複）。これはエンジンが下せないスタンディングゲートです — アドホックなオーケストレーターの判断を置き換え、意思決定を監査可能にします。ストーリーを保留するのは watch のみであり、それはピッチ可能でもビッグでもない項目に対してのみです。

6. triaged_candidates.json 内のルーティング済み候補に対するアングル生成。pitch_ready の項目に対してはピッチモードで angle-generator を実行し（候補がピッチ可能となるのは、正直でジャーナリスト的形のアングルを ≥1 件生み出す場合のみです。実行可能なアングルがゼロの場合は、ストーリーがビッグであれば big_story に、そうでなければ watch に降格されます）、big_story の項目に対しては探索モード（context.mode: exploratory）で実行します（暫定的な suggestion アングルは最大 1 件です。空の結果は問題なく、ストーリーを破棄しません — それは「認識のみ」として引き続き表示されます）。

7. final_report.md を生成する — 3つのバケットでスキャンでき、ストーリーを優先した、ざっと読めるレポートです。フィクスチャの scripts/build_report.py が参照実装であり、人向けレポートの形式はスキルが担います。最初に Today's read の行（N pitch-ready · M big stories · K watched）と、ピッチ可能な項目や大きなストーリーを画面外に落としていないことを明示するファネルの行を記載します。続いて、独立した2つの軸である standing（クライアントが行動できるか）と magnitude（ストーリーの規模）に沿って、次の3セクションを設けます。

   • ## ✅ Pitch-Ready（pitch_ready ティア）：各ストーリーに、鮮度（fresh_new_development の場合は初回公開日と新展開の日付の両方）、standing、angle-generator のアングル、リンクの出典情報、および以下の Media-List Handoff に従って作成した任意の Build a media list in Medialyst ディープリンクを1つ表示します。
   • ## 🔥 Big Stories Worth a Look（big_story ティア）：鮮度の高い high／major ストーリーのうち、standing が確認できていないものを、提案のみとして掲載します。このセクションの見出しには、「your call, relevance unverified」（判断はお任せします。関連性は未確認）と明記します。coverage spread（掲載されたアウトレットの異なる数）の降順で並べ、件数に上限は設けません。各項目に、規模ラベルとアウトレット数、鮮度、正直な bridge_note、確信度フラグ（粗い weakness_flag を含む。例：⚠ possible keyword match）、出典情報、および suggestion タグ付きのアングルを最大1つ（または「明確なアングルなし — 認知のみ」）表示します。こうすることで、掲載対象から外す判断を行うことなく大きなストーリーを提示できます。実際のストーリーと権威性の高いドメイン由来のアーティファクトを区別するのは、上流で除外することではなく、ここで順位付けとフラグ付けを行うことです。
   • ## 👀 Watch / Context：watch ティア（鮮度は高いものの standing がなく、大きなストーリーでもない項目）に加え、鮮度ゲートで振り分けられた項目（stale／unverified_*）を、明確な理由と日付とともに掲載します。大きいものの古い項目には、その旨を示します。
   • リンクの出典情報（全セクション共通）： メインソースは1つ — 記録上のソースとします。これは検出器が実際に掲載した記事で、実際の published_at を使用し、情報が乏しい場合は ⚠ single source、⚠ source of record is an aggregator のように警告を付けます。その下に関連報道を記載します。クラスタリングされた重複掲載記事（surfaced duplicate タグ付き）に加え、ワーカーが提案した canonical_coverage_url／original_url があれば、日付を未確認と明記し、proposed by research — UNVERIFIED タグを付けて表示します。ワーカーが提案したリンクをメインソースの位置に昇格させてはいけません — これが出典のすり替えを防ぐルールです。すべてのリンクに日付を付けます。

   リンクは、バッククォートで囲んだり URL をそのまま記載したりせず、クリック可能な Markdown にします。機械的な順位を、最終的な適合性の判定として提示してはいけません。

   Big Stories Worth a Look や Watch / Context にメディアリストへのリンクを追加してはいけません。これらのストーリーは standing とアングルのゲートを通過していないため、連絡先の検索は時期尚早です。

   ここでは、クライアントブリーフの How to surface を遵守してください。ブリーフでセクションを折りたたむよう求められている場合（例：大きなストーリー／認知のセクション）は、黙って省略するのではなく、理由を添えた1行の件数表示にします。ブリーフが優先する内容を先に記載します。項目を pitch_ready から移動した場合やセクションを折りたたんだ場合は、その旨を明記し、ルール（policy_rule）を引用します。scripts/build_report.py はブリーフに依存しない機械的な参照実装（final_report.md）です。ブリーフの内容は、スキルが生成する run.md に反映します。

8. 成果物から run.md を自分で作成する。 CLI はレポートを生成しません。決定論的な JSON を出力するだけです。final_report.md と成果物に記載された事実を使い、実行フォルダー内に人向けの run.md を作成します。

   レポートは、ゲート適用済み／鮮度確認済み／トリアージ済みの成果物から作成してください。candidates.json だけを元にしてはいけません。粗い判定で却下されたシグナルや、ハードセーフティフラグが付いたシグナルを、✅／🔥 セクションに再掲載してはいけません。ハード除外は機械的なもの（URL パターンの衛生チェック）とハードセーフティフラグのみです。JSON 成果物からそれぞれの件数を開示し、何も隠さないようにしてください — 黙って切り捨ててはいけません。機械可読な成果物インデックスが必要な場合は、次を実行します。

   newsjack run-summary targeted_candidates.json --output summary.json
   

   run-summary が書き込むのは JSON メタデータのみです。Markdown の作成や編集上の判断は行いません。

9. Slack が設定されている場合は、完成したレポートを送信します。 Slack への任意の送信に従ってください。送信は run.md の作成後に行われ、検出の実行自体が成功したかどうかには影響しません。

パイプライン全体はサブエージェント API がなくても動作します。低コストモデルやワーカーの制御機能を備えたハーネスでは、それらを使用してください。ただし、どのハーネスでも同じ成果物の仕様に従い、フォールバックについて明示します。

メディアリストへの引き継ぎ

pitch_ready の機会ごとに、承認を経てから実行されるブラウザー URL を 1 つ作成します。

https://medialyst.ai/app/_/workflow/campaign?prompt=[URL-ENCODED-PROMPT]

URL API または標準の URL エンコーダーを使用し、エスケープされていないプロンプトテキストを決して連結しないでください。パスセグメント _ は、サインイン中のユーザーの現在の組織を解決し、サインインやオンボーディング後も機能します。

プロンプトは、2,000 文字以内の簡潔なキャンペーン向けブリーフにしてください。宛先の発見に役立つ情報だけを含めます。

• クライアント／会社と、レポートですでに確認されている直接の関係
• 新しい記事と一次情報の URL
• 採用された最も有力な切り口
• ジャーナリストの具体的なタイプと、そのテーマが今注目される理由
• 判明している場合は、地域、言語、媒体のランク、do_not_target の制約

レポートで安全に表示できる情報のみを使用してください。クエリ文字列はブラウザーの履歴やサーバーログに残ることがあるため、認証情報、秘密情報、公開前の事実、顧客の個人データ、社内メモは含めないでください。

機会の切り口と情報源の直後に、次の引き継ぎを表示します。

リストを作成： Medialyst でメディアリストを作成 — まず提案されたプランを確認してください。Medialyst で承認した後にのみクレジットが消費されます。

このリンクは任意であり、Newsjack の利用に Medialyst が必須になるわけではありません。機会の内容を保ったまま、リサーチ済みのリストをすばやく引き継ぐための方法です。検出器や定期モニターから media-lists create、create_media_list、その他のクレジットを消費するエンドポイントを呼び出してはいけません。

ユーザーがエージェントとのチャットを続けたいと希望した場合は、機会を find-journalists に引き継ぎます。このスキルは非同期のメディアリスト API を利用できますが、クレジットを消費するジョブを作成する前に、キャンペーンプロンプトと対象件数について明示的な承認を得る必要があります。この検出レポートを受け取っただけでは、承認を得たことにはなりません。

Slack への任意配信

Slack は保存済みモニター向けのオプトイン出力チャネルであり、発見や PR の判定には関与しません。セットアップスキルはユーザーの選択を管理し、このスキルは Slack に適した簡潔な文面を作成します。Webhook と HTTP リクエストを扱うのは CLI のみです。

正規の run.md が完成した後に、次の手順を実行します。

1. newsjack --version（または検証済みの同梱 CLI パス）を実行します。Slack 配信には Newsjack v0.1.17 以降が必要です。古いバージョンの場合は、レポートを成功として保ち、配信をスキップします。新しい CLI が作成した配信ファイルが存在する場合は、Newsjack の更新が必要であることを伝えます。そのファイルを自分で読むことは決してしないでください。
2. インストール済みモニターに対して newsjack monitor delivery status <slug> を実行します。応答は秘匿化されています。Slack が設定されていない場合は、slack.md を作成せずにここで終了します。Limited Mode、Quick Run、フィクスチャ、またはインストール済みモニターではない直接プロファイルに対して Slack を試みないでください。
3. 設定済みのポリシーを適用します。
   • 完了したレポートごと — 「売り込みに適した案件なし」という明確な結果も含め、レポートが完了するたびに送信します。
   • 売り込みに適した案件がある場合のみ — 完成したレポートに売り込みに適した案件が少なくとも 1 件ある場合にのみ送信します。
4. 配信が必要な場合は、run.md で使ったものと同じ、鮮度確認済みの最終情報から slack.md を作成します。簡潔にまとめ、Slack のテキスト書式を使います。太字のテキストは *アスタリスク* で囲み、リンクは <URL|ラベル> として記述します。太字のモニター／クライアント見出し、N pitch-ready · M big stories · K watched の行、続いて売り込みに適した案件を最大 3 件まで記載します。各案件には 1 行の切り口、ソースリンク、メディアリスト作成リンクを含めます。完了したレポートごとのポリシーで、売り込みに適した案件がない場合は、大きなニュースや背景情報の見出しを最大 3 件まで記載し、認知目的のみであることを明記します。最後にローカルの run.md パスを記載し、完全な情報の出所を簡単に確認できるようにします。
5. slack.md は公開しても問題のない内容にします。Webhook、認証情報、禁輸措置対象の情報、顧客の非公開データ、内部メモ、生の JSON、ワーカーの推論は決して含めないでください。配信認証情報ファイルを開いたり、表示、ログ出力、解析したりしないでください。
6. 正確に作成したメッセージを、newsjack monitor delivery send <slug> --message-file <run-folder>/slack.md --run-id <run-folder-name> で一度だけ投稿します。CLI はリダイレクトを拒否します。Slack が投稿を受け付けると、CLI はローカルに「送信済み」マーカーを保存します。このマーカーが存在する場合、通常の再実行では同じ実行の投稿をスキップします。ユーザーがその実行の再送を明示的に求めた場合に限り、newsjack monitor delivery send <slug> --message-file <run-folder>/slack.md --run-id <run-folder-name> --force を使用します。
7. 配信の失敗は致命的ではありません。run.md と slack.md を保持し、自動で再試行せず、Webhook を漏らさずに失敗を報告します。Slack が投稿を受け付けた可能性があるものの応答が失われた場合、または Slack が投稿を受け付けたがローカルの送信済みマーカーを保存できなかった場合、結果は不確定です。Slack は重複を自動的に破棄するためのリクエストキーを受け付けないため、手動で再送する前にチャンネルを確認してください。

配信の承認は、ユーザーが保存したセットアップポリシーに基づきます。スケジュール実行のたびに再度確認してはならず、このスキルから Slack を設定したり、テストメッセージを送信したりしてはいけません。

鮮度ゲート

定期的にスケジュールされた出力では、Go で計算された freshness_gate.computed_status を確認するまで、シグナルを提示してはいけません。ニュース検索の published_at 値は、元記事を特定するための有用な記事公開日時の証拠ですが、それだけで同一ストーリーかどうかや初出を判断することはできません。その役割を担うのは story-origin-check アトムです。

定期出力のルール：

• fresh または fresh_new_development のみを提示します。stale およびすべての unverified_* ステータスは除外します。未検証ステータスを区別するのには理由があります。unverified_no_corroboration（ワーカーが独立した情報源を2件未満しか引用していない状態。再実行できることが多い パイプライン上 の見落とし）、unverified_boundary（日付のみの時刻情報がカットオフをまたいでいる状態）、unverified_no_timestamp（時刻情報を取得できなかった状態）です。ワーカーの品質上の見落としが、実際に古い記事と誤認されないよう、それぞれを個別に報告します。
• --demote-unmatched-x を付けて実行し、大きなストーリーの再現率ガードによって引き上げられない限り、マッチしない X News／Trends のクラスターをキューの下位に移動します。デフォルトでは X News を確認対象として提示しますが、定期出力での精度を高めるには、真に大きなストーリーでない限り下位に移動します。
• 取得の前にクラスタリング（ステップ 3b）を行い、--drop-stale を優先して、配信元の異なる重複記事や、明らかに古く価値の低い項目にストーリーの出自確認の取得処理を消費しないようにします。
• AOL、Yahoo、MSN、Apple News、パートナーによるシンジケーション、通信社の記事の転載、SEO 用の書き換え、または正規／配信元の記事が古い「本日公開」のページを理由に、時刻をリセットしてはいけません。
• 新しい記事によって時刻をリセットするのは、公式な措置、提出書類、声明、データ／レポートの公開、企業の重要な最新情報、新たな地域への影響、または独立して取り上げられる別の進展など、具体的な新しい公開事実が加わる場合に限ります。
• レポートのメインリンクには story_origin.canonical_coverage_url を優先します。同じストーリーを扱う報道の中で主要かつ最も権威あるものを選び、取得のきっかけとなった無作為な転載記事は選びません。

origin-apply は、選択されたシグナルと除外されたシグナルに story_origin および決定的な freshness_gate を付加します。初出日時を確認できない場合は、first_public_at: null と記載してその理由を説明します。適切な unverified_* ステータスは origin-apply が計算します。

引き継ぎ

• 発生直後／当日中に情報源付きコメントが必要 → reactive-comment
• ストーリーの切り口が必要 → angle-generator
• 指定したジャーナリストの確認 → journalist-fit-check
• 草稿の批評 → meanest-editor
• 送付先リストが必要 → 機会情報内の承認必須の Medialyst リンク、またはクレジット使用の明示的な承認を得たエージェント主導のジョブには find-journalists

完了チェックリスト

Full Mode の実行を完了として報告する前に、次を確認してください。

• coarse_relevance_decisions.json には、出力された各候補について判断が1件ずつ含まれています（--allow-missing を指定した場合を除く）。
• clustered_candidates.json は cluster によって生成されています。story-origin はその代表項目に対して実行され、重複項目／古い項目が何件統合されたかが実行結果に明記されています。
• origin_findings.json には、クラスタリングされた各代表項目について調査結果が1件ずつ含まれています（--allow-missing を指定した場合を除く）。件数が検証され、不足分は再実行されています。
• targeted_candidates.json は origin-apply によって生成されています。triaged_candidates.json は各シグナルに tier を付けて newsjack-triage によって生成されています。pitch_ready はピッチモードで angle-generator に渡され、big_story は探索モードで渡されています。
• 新たな high／major のストーリーを watch に振り分けていません。新しい大きなストーリーはすべて 🔥 注目すべきビッグストーリー（掲載価値が認められた場合は ✅ ピッチ候補）に表示されています。簡潔なピッチ禁止ルールによって大きなストーリーが pitch-ready から外れる ことはありますが、表示対象の big_story として残されており（off_policy: true）、除外されていません。
• クライアントブリーフがある場合、レポートに適用されています。ポリシーに反する項目は pitch_ready から外され、統合されたセクションには件数と理由が明記され、今回の実行でポリシーを変更するフィードバックがあった場合は brief.md の編集案として提示されています。
• final_report.md は、targeted_candidates.json／triaged_candidates.json を基に作成された3分類の一覧（✅ ピッチ候補／🔥 注目すべきビッグストーリー／👀 監視／コンテキスト）です。未処理の candidates.json を基にしていません。
• run.md は、final_report.md の作成後に、ゲート処理済み／新規／トリアージ済みの成果物からスキルによって生成されています。未処理の candidates.json だけから生成してはいません。
• Slack の確認は run.md の作成後にのみ行われています。設定されている場合、保存済みのポリシーが守られ、slack.md には公開しても安全な最終情報だけが含まれ、CLI の配信結果が記録されています。旧バージョンの CLI で未対応だった場合や配信に失敗した場合も、レポートは無効になりません。
• pitch_ready の各案件には、URL が正しくエンコードされた、公開しても安全で承認ゲート付きの Medialyst メディアリストリンクが1つ含まれています。big_story および watch の項目には含まれていません。
• 検出器は、クレジットを消費するメディアリスト API を呼び出していません。ディープリンクの生成のみを行っています。
• ✅／🔥 の各セクションには、粗い関連性判定で却下されたシグナルも、ハードセーフティフラグが付いたシグナルも含まれていません。除外された項目（URL 衛生チェック＋ハードセーフティ）の件数のみ、JSON 成果物を基に明記されています。
• 最終回答には、run.md のパス、粗い関連性判定に使われたエンジン（jev、低コストワーカー、または現行モデルのフォールバック）とコスト最適化／フォールバックの状況、表示されたすべてのシグナルについて確認済みの初回公開日時が24時間以内であるかどうか、主要な調査結果、ならびに設定されている場合は Slack の配信状況が記載されています。

出力形式

次の JSON オブジェクトだけを返してください。前後に説明文を付けてはいけません。各案件の evidence_used には、出典 URL を必ず含めてください。story_origin.canonical_coverage_url がある場合は最初に置き、その後に元の URL／出典 URL とその他の裏付けを続けてください（ニュース、RSS、X から通常1～3件）。

verdict が pitch_now または pitch_ready の場合に限り、media_list_handoff を含めてください。big_story、watch、その他の verdict ではこのフィールドを省略してください。以下の例はピッチ候補の形式を示しています。

機械処理用引き継ぎ

{
  "opportunities": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Observed public signal",
      "verdict": "pitch_now",
      "decay": {
        "stage": "4hr",
        "rationale": "Why this clock applies"
      },
      "story_size": {
        "band": "low | moderate | high | major",
        "score": 0,
        "rationale": "How publication traffic/domain authority and coverage spread should affect effort priority"
      },
      "first_publication": {
        "status": "fresh | fresh_new_development",
        "first_public_at": "ISO timestamp or YYYY-MM-DD",
        "original_url": "https://...",
        "canonical_coverage_url": "https://... or null",
        "canonical_coverage_source": "Outlet/source name or null",
        "rationale": "Why this first-public clock controls"
      },
      "why_newsjacking_worthy": "Specific reason this is timely and not generic trend-chasing.",
      "client_standing": {
        "assessment": "strong | partial | weak",
        "rationale": "What gives the client standing, or what is missing"
      },
      "journalist_shape": {
        "beat_description": "Specific reporter shape, not a name",
        "why_they_care_now": "Why this beat plausibly cares now",
        "do_not_target": "Who should not receive this"
      },
      "evidence_used": [
        {
          "source": "news_search",
          "title": "Evidence title",
          "url": "https://...",
          "published_at": "YYYY-MM-DD"
        }
      ],
      "media_list_handoff": {
        "provider": "Medialyst",
        "mode": "approval_gated_deep_link",
        "prompt": "Public-safe campaign brief, maximum 2,000 characters",
        "url": "https://medialyst.ai/app/_/workflow/campaign?prompt=URL-ENCODED-PROMPT",
        "credit_note": "No credits are spent until the user reviews and approves the plan in Medialyst."
      },
      "next_skill": "angle-generator"
    }
  ],
  "rejected_signals": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Rejected public signal",
      "reason": "no_client_standing",
      "first_publication": {
        "status": "stale | unverified_no_corroboration | unverified_boundary | unverified_no_timestamp | null",
        "first_public_at": "ISO timestamp, YYYY-MM-DD, or null",
        "original_url": "https://... or null",
        "canonical_coverage_url": "https://... or null"
      }
    }
  ],
  "brand_safety_blocks": [
    {
      "signal_id": "engine signal id",
      "signal_title": "Blocked public signal",
      "reason": "tragedy_or_human_suffering"
    }
  ],
  "monitor_notes": [
    "Operational note or missing source, if relevant"
  ]
}

• 許可される verdict：pitch_now、develop_angle、monitor、reject。
• 許可される却下理由：stale、freshness_unverified（包括的な理由。より具体的な unverified_no_corroboration／unverified_boundary／unverified_no_timestamp でも可）、single_source、no_client_standing、no_journalist_shape、off_beat、already_seen、weak_signal、no_viable_angle。
• 許可されるブランドセーフティのブロック理由：tragedy_or_human_suffering、client_exclusion、regulated_claim_risk、fabrication_risk。

評価基準

エンジンがキューに入れたエビデンスを返した後、この評価基準を使用してください。エンジンが公開するのは機械的なスコアと routing.queue_priority であり、どちらもPRの判断ではありません。

エンジンには、次の2つの発見レーンがあります。

• profile_relevance - プロフィール／トピック／競合に関するクエリです。非常に関連性が高いものの、重要度は低い場合がある記事を見つけます。
• major_news - 厳選されたRSS/Atomフィードの項目です。まず幅広い主要ニュースを見つけ、その後、クライアントとの関連性をより厳格に判断します。

major_news の項目が大きなニュースだからといって、売り込みに使えると判断しないでください。クライアントには、依然として発言する立場と、記者向けの切り口が必要です。

ストーリーの規模

story_size は、売り込みを承認するためではなく、対応にかける労力を調整するために使用してください。これは、ニュース検索で取得した公開メタデータに基づく、メディアの注目度を示す決定論的な指標です。

• 推定月間トラフィックを対数スケールで換算した値
• ドメインオーソリティ
• 独立して検出されたドメイン間での報道の広がり

認知度の高い主要報道機関のオーソリティメタデータがない場合、エンジンは信頼度の低い既知報道機関の代替値を使用することがあります。公開メタデータがそれ以外の点で乏しい場合は、story_size.attention_hint が付与されることがあります。このヒントは、信頼度の低い継続確認のシグナルとして扱ってください。大きなニュースのセクションでの確認を正当化する場合はありますが、そのニュースが広く報道されていることの証明にはなりません。不確実性は明確に示してください。

ストーリーの規模が major または high、あるいは注目度のヒントが high／major の場合、より迅速な確認に値する機会である可能性を示します。ただし、情報の古さ、発言する立場の弱さ、記者向けの切り口の不適切さを補うものではありません。

新しさ

定期的に出力する場合、LLM の story-origin-check が最初の公開日時と正規の報道を特定し、その後、Go CLI の origin-apply が新しさの判定を行います。ニュース検索の published_at の値は、記事のタイムスタンプを示す信頼できるエビデンスであり、元記事の候補を見つけるために使用してください。ただし、その値だけで同一ストーリーかどうか、あるいは初出かどうかを判断することはできません。

pitch_now、develop_angle、または monitor を割り当てる前に、freshness_gate.computed_status を確認してください。

• fresh - 通常の判断が可能です。
• fresh_new_development - 判断が可能ですが、切り口は古い背景ストーリーではなく、新しい展開に関するものにする必要があります。
• stale - 古い情報として却下してください。
• unverified_no_corroboration、unverified_boundary、unverified_no_timestamp、または値がない場合 - 定期出力では却下してください。理由を記録してください。unverified_no_corroboration はワーカー／パイプラインでの取りこぼしです（タイミングに問題はなく、単に情報源が不十分なだけかもしれません。再実行できます）。一方、unverified_boundary／unverified_no_timestamp は、エビデンスが実際に乏しいことを示します。

アグリゲーター、シンジケーションパートナー、または二次報道機関が古い記事を再掲載しても、起点の日時をリセットしないでください。

ストーリーを引用する際は、story_origin.canonical_coverage_url がある場合は、そちらを優先してください。これは、検索のきっかけとなった小規模な転載先ではなく、一次情報源、通信社、主要出版社、または認知度の高い専門メディアなど、同じストーリーを報じる主要または最も権威のある報道先を示すものです。

判定の段階

pitch_now

次の条件をすべて満たす場合にのみ使用してください。

• エビデンスが新しいこと。通常は 30min、4hr、または 24hr です。
• 最初の公開時刻が過去24時間以内であること、または新しい展開が過去24時間以内であることを確認できている。
• 信頼できるニュースソースが少なくとも1つあること。できれば news_search を含む。
• クライアントが直接発言する立場にある。
• クライアントに実際のスポークスパーソン、または該当分野に関する直接的な権威がある。
• 特定の記者に向けた切り口が明確である。
• ブランドセーフティ上の重大なブロックが適用されない。

develop_angle

シグナルは確かなものの、切り口を練る必要がある場合に使用してください。

• 情報が新しい、またはまだ1週間以内である。
• クライアントが発言する立場にある可能性は高いが、まだ明確ではない。
• 記者向けの切り口はあるが、練り直す必要がある。
• 重要ではあるもののクライアントとの切り口が間接的な場合、主要ニュースレーンの項目はここに分類されることがよくあります。

引き継ぎ先：angle-generator。

monitor

シグナルに注目すべき点はあるものの、ピッチできる段階ではない場合に使用します。

• 情報源が1つだけ、または情報源を横断した裏付けが弱い。
• 十分なニュースの裏付けがない初期段階の話題。
• クライアントに発言する立場はあるかもしれませんが、切り口がまだ明確ではない。
• 勢いが増せば重要になる可能性があるシグナル。

reject

中核となる判定基準のいずれかを満たさない場合に使用します。

• 古い情報である。
• 定期配信のスケジュール出力で鮮度が検証されていない。
• クライアントに発言する立場がない。
• 想定できる記者像がない。
• 対象分野から外れている。
• 新たな展開がなく、すでに取り上げられている。
• 情報源の質が低い。

Decay

Decay では、story-origin-check で検証済みの最初の公開時刻を使用します。証拠がアグリゲーター、配信パートナー、二次的な書き換え記事、または元記事・正式な記事と照合されていない検索結果に基づく場合、エンジンの features.decay_bucket は暫定値です。

• 30min - ライブ／速報。クライアントが今すぐ対応できる場合に限り、即時コメントに使用します。
• 4hr - 同じニュースサイクル内。即応コメントに適しています。
• 24hr - まだ新鮮です。切り口の作成や当日中の対応に適しています。
• week - トレンド／背景情報に限ります。速報として扱わないでください。
• month - 新しいデータポイントや新鮮な切り口と組み合わせない限り、通常はニュースジャックの対象になりません。
• unknown - タイムスタンプを独立して検証できていない場合、タイムリーな話題としてピッチしないでください。

Standing

発言する立場が強い場合：

• クライアントが影響を受ける市場で直接事業を展開している。
• クライアントが市場に直接さらされている、技術的な専門知識を持っている、または具体的に話せる人物として役員を名指しできる。
• シグナルがクライアントのカテゴリー、顧客、規制当局、技術、または競合他社に言及している。

発言する立場が部分的にある場合：

• クライアントに関連分野の専門知識はあるものの、より絞った切り口が必要である。
• クライアントは影響を説明できるものの、出来事の核心は説明できない。

発言する立場が弱い場合：

• クライアントが広義のカテゴリーに製品を販売しているだけである。
• 話題が人気だからという理由で、クライアントがコメントを希望している。
• クライアントが一般的なソートリーダーシップしか提供できない。

major_news レーンのシグナルでは、公開されたニュースとクライアントを結び付ける根拠を説明できる必要があります。

• 影響を受ける買い手が同じである。
• 規制当局または政策上の対象領域が同じである。
• 競合他社またはプラットフォームの動きが名指しされている。
• クライアントが、見落とされがちな業務上の影響を説明できる。

結び付ける根拠が「これは AI に関する話題で、クライアントは AI を利用している」であれば、reject または monitor とします。

Journalist Shape

有用な記者像では、以下を明示します。

• 具体的な担当分野
• メディアのタイプ
• なぜ今その担当分野が関心を持つのか
• 誰に送るべきではないか

悪い記者像：

• 「ビジネス記者」
• 「AI 記者」
• 「テクノロジーメディア」
• 「業界紙」

良い記者像：

• 「規制当局の措置を受け、ベンダーのコンプライアンスに関する主張を取材するエンタープライズ AI 担当記者」
• 「新たな執行措置を受けた ID リスクの影響を取材するサイバーセキュリティ専門誌の記者」
• 「同日発効の政策変更による人件費への影響を取材する小売業務担当記者」

ハードブロック

以下に基づくシグナルはブロックします。

• 死亡
• 暴力
• 災害
• 戦争
• 虐待
• 性暴力
• 行方不明者
• 人道危機
• ヘイトクライム
• テロ
• 自殺

これらの話題で許容される対応は、公共の利益に直接関わる立場からの、節度ある専門家コメントのみです。宣伝目的の切り口は受け付けません。

例

今すぐピッチ

エンジンのシグナル：

{
  "id": "s1",
  "title": "FTC opens inquiry into AI compliance claims",
  "sources": ["news_search", "x"],
  "features": {
    "decay_bucket": "4hr",
    "source_count": 2,
    "seen_before": false,
    "profile_matches": ["AI compliance", "enterprise governance"],
    "safety_flags": []
  },
  "routing": {
    "lane": "profile_relevance",
    "queue_priority": 86.2,
    "demoted": false
  },
  "mechanical_scores": {
    "freshness": 1.0,
    "source_agreement": 0.78,
    "novelty": 1.0,
    "profile_match": 0.44,
    "source_quality": 0.825,
    "momentum": 0.21,
    "major_news": 0.0
  }
}

スキルの出力：

{
  "signal_id": "s1",
  "signal_title": "FTC opens inquiry into AI compliance claims",
  "verdict": "pitch_now",
  "decay": {
    "stage": "4hr",
    "rationale": "The signal is same-cycle by verified first-public clock, not just the search-result timestamp."
  },
  "first_publication": {
    "status": "fresh",
    "surfaced_article_published_at": "2026-05-25T13:14:00Z",
    "first_public_at": "2026-05-25T13:10:00Z",
    "original_url": "https://www.ftc.gov/news-events/news/press-releases/example",
    "canonical_coverage_url": "https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/",
    "canonical_coverage_source": "Reuters",
    "rationale": "The official FTC press release is the earliest verified public source and is inside the 24-hour cron window."
  },
  "why_newsjacking_worthy": "Regulator action creates a live need for explainers on AI compliance claims.",
  "client_standing": {
    "assessment": "strong",
    "rationale": "The client works directly in enterprise AI governance and can explain claim substantiation."
  },
  "journalist_shape": {
    "beat_description": "Enterprise AI reporter covering compliance and regulator scrutiny",
    "why_they_care_now": "They need sourced reaction while the inquiry is fresh.",
    "do_not_target": "General startup roundups or consumer AI reviewers"
  },
  "evidence_used": [
    {
      "source": "Reuters",
      "title": "FTC opens inquiry into AI compliance claims",
      "url": "https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/"
    },
    {
      "source": "FTC",
      "title": "FTC opens inquiry into AI compliance claims",
      "url": "https://www.ftc.gov/news-events/news/press-releases/example"
    }
  ],
  "media_list_handoff": {
    "provider": "Medialyst",
    "mode": "approval_gated_deep_link",
    "prompt": "Find enterprise AI reporters covering compliance and regulator scrutiny for outside expert reaction to the FTC inquiry. The client works directly in enterprise AI governance. Exclude consumer AI reviewers and general startup roundups. Source of record: https://www.reuters.com/legal/government/ftc-opens-inquiry-ai-compliance-claims-2026-05-25/",
    "url": "https://medialyst.ai/app/_/workflow/campaign?prompt=Find%20enterprise%20AI%20reporters%20covering%20compliance%20and%20regulator%20scrutiny%20for%20outside%20expert%20reaction%20to%20the%20FTC%20inquiry.%20The%20client%20works%20directly%20in%20enterprise%20AI%20governance.%20Exclude%20consumer%20AI%20reviewers%20and%20general%20startup%20roundups.%20Source%20of%20record%3A%20https%3A%2F%2Fwww.reuters.com%2Flegal%2Fgovernment%2Fftc-opens-inquiry-ai-compliance-claims-2026-05-25%2F",
    "credit_note": "No credits are spent until the user reviews and approves the plan in Medialyst."
  },
  "next_skill": "reactive-comment"
}

却下（古いシンジケーション記事）

エンジンのシグナル：AOL の記事は本日公開されていますが、正式な URL は、5 月 4 日の BBC の記事を指しており、新たな展開はありません。

判定：reject

理由：stale

first_publication.status：stale