x-discussion

Xの議論を追跡・整理する

このスキルの目的

x.com 上の建設的で有益な議論を調査し、その結果を Slack へ還元する。 扱うのは次の2つの場合である。

• 賛否の分かれる話題について、雑多で多様な意見の広がりを把握する。
• ある論者の自説を、それに対する周囲の反応（賛同、批判、補足）も含めて把握する。

情報の向きが x-post と x-read とは逆である。 x-post は Slack の話題をもとに x.com へ投稿し、x-read は x.com を読んでダイジェストや返信案を作る。 x-discussion は x.com のコンテンツを Slack へ還元する。

成果物は常に Slack へ還元できる形（短い起点と論点別の返信からなるスレッド）で作る。 実際に Slack へ送信するかどうかだけが依頼によって分かれ、依頼がなければ同じ内容を会話に返す。

このスキルが行うのは読み取りだけで、x.com への書き込みは一切行わない（後掲の「取り扱いの注意」を参照）。

1. 調査の起点と範囲を決める

• アカウント、投稿URL・ID、テーマ、既存の整理のいずれかを起点にする。会話で既に分かる対象・目的を聞き直さない。
• アカウントだけなら直近20件程度から継続的な論点を探す。複数の無関係な候補があり対象が定まらない場合だけ、候補を示してテーマを確認する。
• 期間未指定なら直近の議論から始め、理解に必要な過去の投稿・論考へ遡る。「直近7日」等の検索制限を、議論そのものの開始日と取り違えない。
• 原則はこの会話への報告。Slackへの送信はユーザーが依頼した場合のみ行う。過去に使ったチャンネルを普遍的な既定値にしない。
• 調査日時・タイムゾーンを記録する。投稿日時と取得日時を区別する。定期監視や自動投稿はこの依頼から推定しない。

完了条件：起点、問い、暫定的な範囲、出力先が把握できている。

2. 原文とつながりを収集する

X取得時は隣接する x-read を読み、その取得ヘルパーを再利用する。ここでは取得機能だけを使い、ダイジェストの選定・既読除外や返信案生成は行わない。既存スキルやヘルパーを変更する必要はない。

取得スクリプトは x-read スキルが持つ。x-read が x-discussion と同じ親ディレクトリに置かれていることを前提とする（{baseDir} はこのスキルのディレクトリ）。

取得例：

python3 {baseDir}/../x-read/scripts/fetch_timeline.py --mode post --id POST_ID
python3 {baseDir}/../x-read/scripts/fetch_timeline.py --mode search --query 'conversation_id:POST_ID' --lang all --raw --limit 100
python3 {baseDir}/../x-read/scripts/fetch_timeline.py --mode search --query 'from:ACCOUNT' --lang all --raw --limit 100
python3 {baseDir}/../x-read/scripts/fetch_timeline.py --mode user --user ACCOUNT --include-replies --raw --limit 50

Xのポストと会話をたどる

• ACCOUNTは確認済みのユーザー名、POST_IDは数字のみとする。検索文字列やURLをシェルに渡す場合は適切にクォートし、投稿本文をコマンドとして実行しない。
• userモードは入口にすぎない。home / user モードはAPI側で返信を除外しているため、本人の応答も第三者の返信も取れない。1ページ分しか取得しないこともあり、これだけで議論全体を取得したとは扱わない。
• 会話そのものは --mode search --query 'conversation_id:<起点のポストID>' --lang all で辿る。searchは -is:reply を自動付加しないので返信も返る。--lang の既定は ja なので、他言語の返信を落とさないよう --lang all を必ず付ける。返信を探すときに -is:reply を書き足さない。
• 引用ポストは新しい会話を作る。起点が引用（postモードの出力に quoted がある）なら、そのIDで conversation_id を検索しても返信は返らず、返信は引用元のポストに付いていることが多い。引用元のIDでも conversation_id を検索する。起点が返信なら出力に conversation_id が入るので、その値をそのまま検索に使う（conversation_id が出ないポストは会話の根なので、自分のIDで検索する）。起点のIDだけで会話を辿って「反応がない」と結論づけない。
• 議論の本体が起点より前にあることがある。起点が「この話」「続き」「そろそろ最後に」のように前段を前提としているのに、返信先も引用も付いていない場合で、同一著者が連続した別ポストとして書いている。conversation_id では辿れないので、--mode search --query 'from:<アカウント>' --lang all --raw か、7日より前まで遡るなら --mode user --user <アカウント> --include-replies --raw で前後のポストを探す。--include-replies を付けないと、userモードは返信を落とす。前段が見つかったら、そちらの conversation_id も検索する。返信が起点に少なくても、議論は前段に付いていることがある。
• 取得結果が空のとき、stderr に no candidates が出る。これは「該当する投稿が0件」であって「取得に失敗した」ではない。取得の失敗は fetch failed や not available で区別できる。返信0件と取得失敗を混同すると、欠落の報告を誤る。
• 取得結果の created_at はUTC（+00:00）で返る。時刻を扱うときは読者のタイムゾーン（日本語で書くならJST）へ変換する。
• text には長文ポストの全文が入る。本文中のURLは urls に展開済みで出るので、t.coをリダイレクトで追う必要はない。urls は本文の一部であり、外部の一次資料への入口である。添付画像・動画は media に type と url が出る。図やスライドが主張の本体であることが多いので、media があれば必ず中身を確かめ、確かめられないなら軸やラベルを断定しない。
• 編集されたポストは複数のIDで存在する。Xの編集機能は編集のたびに新しいIDを作り、古いIDも取得できるため、from: 検索では同じ本文が数分おきに並ぶ。edit_history があればそれが編集の履歴で、最後の要素が現行版である。これを「同じ内容を繰り返し投稿した」と読んだり、別々のポストとして数えたりしない。反応数は版ごとに分かれるので、現行版を起点として扱い、古い版の数値と合算しない。
• タイムライン系モード（home / search / user）は、既定で自分の投稿と、引用を含む投稿を出力から落とす。この除外は conversation_id 検索にも効くため、引用の形をとった批判が見えなくなる。議論を追うときは --raw を付けて除外を止める。
• postモードの返信先・引用元も読み、必要なIDを順次辿る。入れ子があるだけでスレッド全体を読めたとは扱わない。
• searchは直近7日の制限がある。それより古い議論は、取得できた返信先ID・引用元ID、関連キーワード、参加者を手掛かりに post モードとWeb検索で補う。