whathappened

/whathappened

whathappened スキルを実行しています。指定されたトピックについて、何が起きたのかとX 上で何が語られているのかを中立的にまとめてください。

一般的な調査ではありません。このファイルの内容に、最初から最後まで従ってください。

ホスト要件

次のツールが必要です。

• x_keyword_search
• x_semantic_search
• x_thread_fetch
• x_user_search

これらのツールがない場合は、停止してください。このスキルは Grok Build（または、これらの X ツールを備えた別のホスト）でのみ動作するとユーザーに伝えてください。ウェブ検索の結果から X のブリーフィングをでっち上げてはいけません。

厳守事項

1. X を最優先にして統合します。 出来事や世論に関するすべての主張は、X ツールの結果に基づく必要があります。投稿、ハンドル、エンゲージメント、引用を捏造してはいけません。
2. ウェブ利用の例外は限定的です。 トピックが何か、誰かを特定するため（正式名称、ハンドル、製品の特定）に限り、ウェブ検索（web_search または web_fetch）は最大 1 回まで使用できます。意見、感情、または「人々がどう考えているか」の調査にウェブを使ってはいけません。ウェブ検索を使った場合は、「不足情報」に明記してください。
3. トピックを探し出してはいけません。 ユーザーがトピックを指定していない場合や、「X で話題のこと／注目の話題は？」と尋ねている場合は、話題をでっち上げず、短い質問を 1 つしてトピックを尋ねてください。
4. v1 ではフラグを使いません。 フラグのようなトークン（--deep、期間の上書き指定）は無視するか、穏やかに取り扱ってください。期間は（以下の）動向から推定してください。
5. 中立的な分析者の口調にします。 煽る表現や嘲笑、「場が沸き立っている」といった表現は使いません。観測された意見の対立や議論を報告してください。
6. 期間は状況に応じて調整し、最新の情報を優先します。 期間を一律に 30 日に設定しないでください。話の筋を説明できる範囲で、できるだけ短い期間を選んでください。
7. 意見を事実として扱ってはいけません。 X のこのサンプルにおける世論として、感情や意見を示してください。
8. 出典を示します。 可能な場合は @handle と投稿へのリンクを優先してください。X ツールから投稿の引用 ID が得られる場合は、ホストのインライン投稿引用表示を使ってください。URL を捏造してはいけません。無関係な出典を末尾に羅列してはいけません。

検索クエリを作成する際は、references/query-patterns.md を読んでください。 サンプルが少ない、意見が分かれている、またはノイズが多い場合は、references/failure-modes.md を読んでください。

パイプライン

ステップ 0 - トピックの解析

• 名前が明示されたトピック（人物、組織、製品、リリース、出来事、論争）を必須とします。
• 検索対象のエンティティから意図を示す修飾語（sentiment、drama、takes）を取り除きますが、ユーザーがそれらを求めている場合は、統合時の観点として残してください。
• 大まかに分類します：出来事 | 人物／組織 | 製品／リリース | 論争。

ステップ 1 - エンティティ特定のための任意のウェブ検索（0 回または 1 回）

トピックが曖昧な場合、または明らかな公式ハンドル／名称がわからない場合：

• エンティティの特定にウェブ検索を最大 1 回行います。
• 正式名称、記載があれば公式の @handle、別名、ページに記載があればイベントの日付を抽出します。

トピックがすでに明確な場合（例：Kimi K3、@sama）は、ウェブ検索を省略してください。

ステップ 2 - X でエンティティを特定

• 必要に応じて、公式または一次情報源と思われるアカウントを x_user_search で検索します。
• 別名を作成します：完全一致のフレーズ、別表記、製品コード、キャッシュタグ。
• 確度の高いハンドルがわかっている場合は、from:handle を付けた一次情報源を優先してください。

Step 3 - パルス（常に最初）

短い since: 期間を指定して、低コストの Latest キーワード検索を実行し、勢いを測ります。まず試す期間の例：

• 急上昇候補：ここ数時間（今日の日付を指定する since:YYYY-MM-DD、Latest）
• ほとんど結果がない場合：モードを決める前に、一度だけ期間を広げます（昨日／過去 2 日間）

モードと期間を決定します：

パルスの兆候	モード	デフォルトの期間
投稿数が多く、エンゲージメントが上昇し、発信元が明確	急上昇	過去 1～6 時間（勢いがなお急増中なら数分）
同日中の明確な出来事／発表に関する投稿	同日	過去 24～48 時間
議論が続いており、勢いは中程度	ストーリー	過去 3～7 日間
投稿が少なく、古いニュースへの言及が中心	背景情報	過去 14～30 日間。なるべく最近の投稿を優先

要約には、選択した 期間 と モード を記載します。以降、次の場合に限り検索範囲を広げます。

• 何が起きたのかについて意見が一致していない
• 明らかなアカウントによる、見つかっていない一次発信の投稿がある
• 議論で、まだ確認していない発端の投稿が示されている

順位付けでは、古い投稿が明らかに誰もが引用・返信している発端である場合を除き、いいね数より新しさを優先します。その場合はスレッドを取得してください。

Step 4 - 検索ラティス（並列）

複数のレーンを使います。通常の実行では、X ツールの呼び出し総数をおよそ 8～14 回 に抑えます。

レーン	ツール	目的
トップ	x_keyword_search mode=Top	エンゲージメントの高い共通見解
最新	x_keyword_search mode=Latest + 時間演算子	新しい動向
セマンティック	x_semantic_search	言い換えや近接する切り口
一次発信	判明している場合は from:handle を含むキーワード検索	公式声明
議論	論争／引用／反論のクエリ	意見の相違を把握

references/query-patterns.md の高度な演算子を使います。クエリには必ず主要な対象を含めます。対象と無関係に拡散しているノイズは除外します。

Step 5 - スレッドの情報補完

シグナルの強い投稿から 3～8 件 を優先して、x_thread_fetch で取得します。

1. 発端／発表
2. 公式の一次発信
3. エンゲージメントが最も高い要約的な意見
4. 最も筋の通った擁護と、最も強い批判
5. 陣営の分裂を示す投稿

Step 6 - 順位付けとクラスタリング（頭の中で簡潔に）

概算スコア：

score = engagement × freshness_weight × authority_weight × on_entity

• 対象との関連性： 主要な話題（または明確な別名）についての投稿であること。
• 権威性（参考程度）： 公式アカウント、分野の専門家、一次報道を参考にします。ただし、固定の許可リストとして扱わず、認証済みアカウントだけを過度に重視しないでください。
• クラスタ： 同じ主張をする投稿をまとめて、1 つの陣営の箇条書きにします。

対象との関連性が裏付けられない、エンゲージメント稼ぎの投稿は除外します。

Step 7 - 要約の作成

以下のテンプレートを使って要約を出力します。順位付けした生の一覧はそのまま出力しないでください。 サンプルに利用可能な文章がある場合は、実際の投稿からの短い引用を、出典を明記して 少なくとも 2～3 件 含めます。

サンプルが少ない場合は、その旨を記載します。見せかけの総意より、正直に不確実性を示すことを優先します。

出力テンプレート

この構成を使います。ブログ風のセクションを追加しないでください。

# /whathappened: {topic}

**Window:** {human window} · mode {Breaking|Same-day|Story|Background} · as of {UTC or local stamp}
**X sample:** ~{N} posts · Top + Latest + {K} threads · confidence {high|medium|thin}
**Entity resolve:** {none | one web lookup: one-line what it was for}

## What happened
2–5 sentences. Prefer first-party and origin posts. Stick to what X supports.

## Where the conversation is
- Dominant frame
- Secondary frames
- Who is loud (camps / account types), not "people in general"

## Public opinion map
| Camp | Share (rough) | Core claim | Representative voices |
|------|---------------|------------|------------------------|
| … | ~X% | … | @a, @b |

Label shares as qualitative judgment from this sample, not polling.

## The live debates
1. **{title}** - Side A vs Side B; stakes in one line; best evidence posts
2. …

## Notable posts (receipts)
- [@handle](url or status link if known) - why it matters (role: origin / official / steelman / critique / meme)
- … (5–10 max)

## Gaps / caveats
- Thin sample, missing official voice, language bias, bot/noise risk, web resolve used, etc.
- What would change this read if true

書式に関する注意

• エムダッシュではなく、通常のハイフン - を使います。
• 中立的な表現を使います。「多くの投稿が主張している」「よくある批判は」などとし、「誰もが知っている」などとは書きません。
• 陣営のおおよその割合には、サンプルに基づく概算であることを明記します。
• 確信度が低い場合は、意見の分布を簡潔にし、「不足情報」を充実させます。
• 「不足情報」で終えます。ユーザーが追加質問を求めていない限り、最後に誘導的な案内を付け足さないでください。

実行前チェックリスト（最初のツール呼び出し前）

• 話題が示されている（示されていない場合は確認する）
• X ツールが利用可能（利用できない場合は対応を断る）
• Web 利用枠の残り：0、または 1 回（解決のみ）
• 調査依頼ではない

要約後のチェックリスト（送信前）

• 期間とモードを記載した
• 引用した各行に、取得した投稿の出典を明記した
• Web 由来の「感情分析」がない
• 確信度が高い場合、複数の投稿に基づいて陣営をまとめた
• 根拠が実在し、話題に関連している
• サンプルの限界について、不足情報を正直に記載した