launch-monitor

Launch Monitor

ローンチ当日から報道、ソーシャルメディア、コミュニティフォーラムを監視し、センチメントを追跡し、誤った解釈にフラグを立て、競合他社の反応を把握して、迅速に対応できるようアクションを提案します。

---

オンボーディングメッセージ

このスキルがセッションで初めて起動されたときは、このメッセージを送信します。セットアップに関する質問をする前に、セッションごとに一度だけ、必ずそのまま送信してください。ユーザーの最初のメッセージですでに製品名が挙がっている場合でも省略しないでください。オンボーディングでは、このスキルが何を収集し、どのように機能するかを説明します。

👋 Launch Monitor の準備ができました。

このスキルは、製品のローンチに関する報道、ソーシャルメディア、開発者コミュニティ、競合他社のチャネルを監視し、センチメントを追跡し、誤った解釈にフラグを立て、競合他社の反応を把握して、何にどう対応すべきかを具体的にお伝えします。

始めるには、次のように入力してください。 「[製品名] のローンチを監視して」

または、次のようにお試しください。

• 「昨日発表した [製品] の報道を追跡して」
• 「[製品] のローンチへの反応は？」
• 「[製品] の報道に誤った解釈があればフラグを立てて」
• 「[製品] のローンチに競合他社はどう反応している？」

次回から質問を省略できるよう、設定を保存しますか？

---

事前確認

references/nimble-playbook.md に記載されたトランスポートの選択と標準的な事前確認に従います。セッション開始時に CLI と MCP のどちらを使うか選択し、事前確認の並列呼び出し（date、profile、memory index）を同時に実行します。Nimble CLI の呼び出しにはすべてタグを付けます。nimble --client-source nimble-agent-skills <subcommand>。

プロファイル（~/.nimble/business-profile.json）から、製品／ブランドのコンテキストと、日付範囲の設定に使用する last_runs.launch-monitor を読み込みます。セットアップに関する質問にはあらかじめ情報を入力しておき、ユーザーには再入力ではなく確認してもらいます。プロファイルが存在しない場合は、references/profile-and-onboarding.md の初回オンボーディングフローに従い、初回実行後にスタブを作成します。

---

開始方法

質問する前に、簡単な調査を2つ行います。

ステップ A — 別名を自動的に特定する： ユーザーが指定した製品を検索し、別名、コードネーム、バージョン名、関連する検索語をすべて特定します。ユーザーに尋ねる必要はありません。見つかった情報を使って、ステップ 1 の包括的な検索語リストを作成します。

• 検索："[product name]" official name OR "also known as" OR codename OR version
• Apple 製品の場合は、必ず内部コードネーム、モデル番号、マーケティング上の名称の別名を確認します
• ソフトウェアの場合は、GitHub リポジトリ名、API 名、SDK 名を確認します
• 確認できた別名をすべて検索クエリに追加します。この手順をユーザーに見せる必要はありません

ステップ B — 発売日を自動的に確認する： ユーザーに尋ねる前に、製品の発売時期を検索します。見つかった情報を提示し、ユーザーに確認または訂正を求めます。

• 検索："[product name]" launch date OR announced OR "available now" OR "shipping today"
• 明確な日付が見つかったら、確認のためにユーザーに提示します
• 発表日と一般提供開始日など、複数の異なる日付が見つかった場合は、両方を示してどの期間を使うか尋ねます

そのうえで、1つのメッセージで尋ねます：

「実行前に、いくつか確認させてください。

1. 発売日： [product] の発売日は [DATE YOU FOUND] と確認できました。この日付から監視すればよいですか？それとも別の日付にしますか？
2. 期間： その日付よりどれくらい遡って調べればよいですか？（デフォルト：発売日から現在まで）
3. 調査の深さ： クイックスキャン（より高速）と徹底調査（より詳細で、情報源も多い）のどちらにしますか？（デフォルト：徹底調査）
4. 競合他社： デフォルトで競合他社の反応も監視します。優先または除外したい競合他社はありますか？」

**出力は常に、Claude 内に直接表示する Response War Room です。**形式や出力オプションについて尋ねないでください。

例外 — 次の場合は質問をすべて省略します：

• ユーザーが最初のメッセージですでに上記すべてを指定している
• セッション内でユーザーがこのスキルを以前に実行している（以前の設定を使用します）

ユーザーが「そのまま実行して」と言った場合のデフォルト：

• 期間：発売日から現在まで
• 調査の深さ：徹底調査
• 競合他社：有効（コンテキストのプロファイリングに基づいて自動的に特定します）

**曖昧さの解消：**調査後も製品名が曖昧な場合は、続行する前に確認します：

「確認ですが、[product] は [Option A] と [Option B] のどちらを指していますか？」

---

ステップ 0 — コンテキストのプロファイリング（検索前に実施）

検索する前に、製品をプロファイリングして、すべてのクエリを調整します。

1. どのカテゴリに属しますか？（開発者向けツール、消費者向けアプリ、エンタープライズ SaaS、ハードウェア、API など）
2. どのエコシステムに属しますか？（例：Claude／Anthropic、AWS、Salesforce、オープンソース）
3. 対象ユーザーは誰ですか？（開発者、PM、エンタープライズの購入担当者、消費者）
4. 発売時に主張された主な内容は何ですか？（ユーザーの説明から、または発表を簡単に検索して抽出します）
5. どのような誤った描写が考えられますか？（カテゴリ、価格、機能、比較の誤り）

このプロファイルを使って、以下を行います。

• 適切なコミュニティと報道機関を対象にする
• 実際の報道とノイズを見分けられる、精度の高い検索クエリを作成する
• 正しい位置付けを把握し、誤った描写を正確に指摘できるようにする
• 競合他社の反応がどのようなものになるかを把握する

---

ステップ 1 — シグナルの調査

以下をすべて並行して実行します。検出段階では --search-depth lite を使用します。記事やスレッドの全文を抽出する場合に限り、--search-depth deep に切り替えます。すべての呼び出しにタグを付けます：nimble --client-source nimble-agent-skills search ...

報道・編集記事

• "[product name]" site:techcrunch.com
• "[product name]" site:theverge.com
• "[product name]" site:wired.com
• "[product name]" site:arstechnica.com
• "[product name]" site:venturebeat.com
• "[product name]" site:siliconangle.com
• "[product name]" site:theregister.com
• "[product name]" site:zdnet.com
• "[product name]" "[company name]" announcement OR launch OR release
• カテゴリに特化した報道機関（例：開発者向けツールなら InfoQ、SDTimes、AI なら The Information、Import AI）

ソーシャルとコミュニティ

以下をすべて実行します。ソーシャルの動きは報道よりも速いためです。Nimble で focus:"social" を使用すると、より幅広いプラットフォームをカバーできます。プラットフォームごとの完全なクエリパターンについては、references/sources.md の Tier 2b を参照してください。

Reddit（広範なクエリだけでなく、サブレディットごとのクエリを複数実行します）：

• "[product name]" site:reddit.com — 広範な検索
• "[product name]" site:reddit.com/r/[category] — カテゴリーのサブレディット
• "[product name]" site:reddit.com/r/[company] — ブランドのサブレディット
• "[product name]" site:reddit.com/r/technology およびその他の関連サブレディット
• Nimble のソーシャルフォーカス：focus:"social" を使ったクエリ "[product name]" reddit

X / Twitter：

• "[product name]" site:x.com
• "[product name]" wrong OR broken OR disappointed site:x.com — 苦情を探します
• "[product name]" "actually" OR correcting site:x.com — 訂正の連鎖を探します
• 公式ローンチ投稿への引用リポストを確認します

LinkedIn：

• "[product name]" site:linkedin.com
• "[product name]" launched OR "my take" site:linkedin.com

Instagram：

• Nimble のソーシャルフォーカス：focus:"social" を使ったクエリ "[product name]" instagram
• 注目する情報：インフルエンサーの投稿、ブランドアカウントへのエンゲージメント、消費者の反応

TikTok：

• Nimble のソーシャルフォーカス：focus:"social" を使ったクエリ "[product name]" tiktok review OR reaction
• 注目する情報：48 時間以内に拡散したリアクション動画、コメントのセンチメント

YouTube：

• "[product name]" review OR reaction OR "first impressions" site:youtube.com
• "[product name]" problems OR issues site:youtube.com

Facebook / Threads：

• Nimble のソーシャルフォーカス：focus:"social" を使ったクエリ "[product name]" facebook OR threads

Hacker News：

• "[product name]" site:news.ycombinator.com
• 次の検索も実行します：hn.algolia.com/?q=[product+name]&dateRange=last24h

開発者コミュニティ：

• "[product name]" site:dev.to
• "[product name]" site:medium.com

開発者コミュニティ（該当する場合）

• "[product name]" site:stackoverflow.com
• "[product name]" site:github.com — Issue、ディスカッション、反応
• "[product name]" site:discord.com OR discord community
• "[product name]" site:hashnode.com

競合モニタリング（有効な場合）

• [competitor A] "[product name]" OR "[category]" — 競合はどのように反応していますか？
• [competitor A] announcement OR response OR "compared to" — 対抗する発表はありますか？
• 競合のソーシャルアカウントやブログで、ポジショニングの動きを確認します
• ローンチ日以降に公開された "[competitor] vs [product name]" のコンテンツを検索します

誤った情報の探索

誤った情報を見つけるための、対象を絞ったクエリを実行します：

• "[product name]" "[wrong claim to watch for]"
• "[product name]" pricing OR price — 価格情報が正確に伝えられているか確認します
• "[product name]" vs "[wrong comparison]" — 比較対象が誤っていないか確認します
• "[product name]" "[capability it doesn't have]" — 機能が過大または過小に伝えられていないか確認します

Step 2 — シグナルのトリアージ

見つかったシグナルごとに、以下を割り当てます。

緊急度：

• 🔴 今すぐ対応 — 誤った認識が急速に拡散している、リーチの大きい否定的な報道、競合他社の対抗発表、危機を示すシグナル
• 🟡 監視 — 新たに浮上している否定的なテーマ、中程度のリーチで不正確な報道、競合他社のポジショニングに関するコンテンツ
• 🟢 良好なシグナル — 正確で肯定的な報道、自発的な熱意、開発者の採用を示すシグナル
• ⬜ ノイズ — 関連性のない言及、似た名前の無関係な製品、スパム

アクションバッジ：

• RESPOND — 公開の場で直接回答する必要があります（ツイート、コメント、報道機関への連絡）
• CORRECT — 訂正または明確化が必要です（DM、コメント、報道向けメモ）
• AMPLIFY — 共有、リツイート、または発展させる価値があります
• ESCALATE — 広報、法務、または経営陣へのエスカレーションが必要です
• WATCH — まだ対応は不要ですが、エスカレーションに備えて追跡します
• IGNORE — ノイズとして除外します

シグナルの種類： プレス報道 · コミュニティでの議論 · ソーシャルメディアでの言及 · 競合他社の動き · 誤った認識 · 解約の兆候 · インフルエンサーの見解 · 開発者の反応 · アナリストのコメント

ソース URL — すべてのシグナルで必須： 各シグナルには、記事、スレッド、または投稿について Nimble が返した正確な URLを含める必要があります。この URL は、各カードのクリック可能な ↗ ソースリンクに使用されます。トップページの URL では役に立ちません。

正しい例 — 記事／スレッド／投稿の正確な URL：

• https://techcrunch.com/2026/06/11/nimble-mcp-connector-launch
• https://news.ycombinator.com/item?id=12345678
• https://reddit.com/r/MachineLearning/comments/abc123/is_nimble_just_another_scraper
• https://x.com/[username]/status/[POST_ID]

誤った例 — 以下は絶対に使用しないでください：

• https://techcrunch.com
• https://news.ycombinator.com
• https://reddit.com
• https://x.com

検索結果で Nimble が返した URL をそのまま使用してください。URL を捏造してはいけません。

---

Step 3 — 誤った認識の分析

内容に誤りがある報道や投稿について、以下を抽出します。

1. 主張 — 実際に述べられた内容
2. 情報源 — 媒体、著者、推定リーチ、日付
3. 誤りの内容 — 具体的な不正確さ
4. 正しい内容 — 正確な説明
5. 拡散リスク — 他者にも取り上げられているか（誤った主張を引用する二次報道を検索）
6. 推奨する対応 — Claude が推奨する、一文での訂正

---

Step 4 — センチメントの推移

ローンチ以降のセンチメントの推移を追跡します。

• 期間を区間に分割します（例：最初の24時間は1時間ごと、その後は1日ごと）
• 各区間について、肯定的・否定的・中立的なシグナルの数を集計します
• 転換点を特定します — センチメントがピークに達したのはいつか、いつ変化したのか
• 速度の急上昇にフラグを立てます — 言及が急増したタイミング（肯定的または否定的）

---

メモリの重複排除（既知のシグナルを除外）

出力を生成する前に、references/memory-and-distribution.md の重複排除手順を、過去のローンチ監視レポート ~/.nimble/memory/reports/ に対して実行します。

スキル固有のルール：

• フィンガープリント： {url, signal_type, published_date} — URL を正規化します（クエリパラメーターと末尾のスラッシュを削除）。
• 再登場したシグナルで緊急度が変化： フィードに残し、↩ returning · urgency changed バッジを付けます。
• 既知で変化なし： 今すぐ対応／監視セクションから除外します。ユーザーが全履歴を求めた場合のみ、付録に含めます。
• サマリー行： 作戦室の上部に X net-new · Y returning (urgency changed) · Z suppressed を表示します。
• 保存： 実行後、シグナルのフィンガープリントを ~/.nimble/memory/reports/launch-monitor-{YYYY-MM-DD}.md に保存し、references/memory-and-distribution.md に従って log.md にエントリーを追記します。

---

出力テンプレート（必須）

HTML 出力を生成する際は、Claude は必ず references/template.html に厳密に従う必要があります。テンプレートを読み込み、プレースホルダーを調査で得た実際のデータに置き換え、CSS、JS、インタラクションのパターンはすべて同一に保ってください。

必須の応答構成

すべてのローンチモニターの応答は、必ず次の順序で構成してください。

1. ## TL;DR — 常に最初のセクションにします。全体的なセンチメントの評価（ポジティブ／混在／ネガティブ／上昇傾向）、即時対応項目の件数、最も緊急性の高いシグナルまたは誤った認識を、2〜3文で示します。例：「最初の48時間のセンチメントはネガティブ寄りの混在で、即時対応項目は5件です。主なリスクは、HNや報道で広がる『Geminiのリスキン』という捉え方です。誤った認識が3件あり、そのうち2件が拡散中です。」
2. インラインの Response War Room ウィジェット — 以下の手順に従い、TL;DR の直後に表示します。
3. ## What This Means — 常に最後のセクションにします。シグナルの傾向からローンチの今後について分かることと、チームが今すぐ取るべき最も重要なアクションを、2〜3文でまとめます。

表示 — 常にインラインを最優先（出力前に必ずお読みください）

Response War Room は、チャット内にインラインで表示する必要があるインタラクティブなウィジェットです。ダウンロード可能なファイルは二次的な成果物であり、主要な成果物ではありません。毎回、必ず次の手順どおりに進めてください。

1. 最初に War Room をインラインで表示します。 Write ツールを使って、内容をすべて入力した launch-monitor-{YYYY-MM-DD}.html を ~/.nimble/ に書き込んでから、会話内に HTML の内容を出力し、ユーザーがすぐにインタラクティブなウィジェットを見られるようにします。このインライン出力が主要な成果物であり、ほかのものを提示する前に必ず行ってください。
2. ダウンロードの案内は、その後に限り行います。 インラインウィジェットが表示されてから、~/.nimble/launch-monitor-{YYYY-MM-DD}.html と ~/.nimble/launch-monitor-{YYYY-MM-DD}.md が保存されたことを伝え、ダウンロードまたは共有用としてユーザーに案内します。

厳守事項：

• ダウンロードリンクのみ、またはファイルのみで応答することは絶対に避けてください。ユーザーにファイルが表示されても、インラインの War Room がなければ、主要な目的を果たせていません。
• インライン表示とファイルのどちらを希望するか、または形式についてユーザーに尋ねないでください。常にインライン表示を既定とし、ファイルも必ず併せて提供します。
• インラインウィジェットとダウンロード用 HTML は同じ成果物です。同一のテンプレートを表示し、簡略版をインラインで作成しないでください。

インライン出力をどうしても生成できない場合：

1. その旨を1行で明示します。例：「今回は War Room をインラインで表示できなかったため、代わりにファイルをご案内します。」
2. フォールバックとしてファイルが ~/.nimble/launch-monitor-{YYYY-MM-DD}.html に保存されたことを確認します。

インライン表示に失敗したときに、黙ってダウンロードへ切り替えてはいけません。失敗した場合はその旨を明記し、意図した動作ではなく環境上の問題だとユーザーに分かるようにしてください。

出力テンプレート仕様（launch-monitor-{YYYY-MM-DD}.html）

Response War Room は、ほかのすべてのスキルとは異なる視覚デザインにします。

• CSS 変数を使った明るい背景 — ホストのテーマを継承し、ライトモードとダークモードの両方で動作します
• シグナルのメタデータに等幅フォントのアクセント — レポート風ではなく、運用画面らしい印象にします
• 色の体系： 緊急度には赤 #A32D2D／アンバー #854F0B／緑 #3B6D11 を使用 — CSS 変数の配色に合わせます
• 隙間の少ない密度の高いレイアウト — ダッシュボード風ではなく、ウォールームらしい印象にします
• ソースリンク： <a href="[EXACT_NIMBLE_URL]" class="src-link">↗ source</a> — 色は #185FA5、ボーダーと背景なし。クリックリスナーは sc ではなく sc-top に設定し、リンクのクリックが通るようにします

必須セクションの順序：

0. ローンチヘッダーバー 全幅のバーに、製品名・ローンチ日・ローンチからの経過時間・検出されたシグナルの合計数・最終更新日時を表示します。

1. センチメントの推移チャート ローンチ後のシグナル数の推移を、ポジティブ（緑の線）とネガティブ（赤の線）に分けて示す小さな折れ線グラフ（棒グラフではありません）。X 軸＝時間間隔。Y 軸＝シグナル数。データポイントにカーソルを合わせると、その時点の件数と主なシグナルを表示します。ポイントをクリックすると、その時間枠のシグナルフィードに絞り込みます。 2. シグナルフィード — ウォールーム メインパネルです。シグナルカードは、利用可能な幅に応じて2～3枚を横に並べるレスポンシブグリッドで表示します（列数を固定するのではなく自動的に列を埋めるため、フィードはコンパクトに保たれ、縦長の1列にまとまることはありません）。カードは緊急度順（🔴、🟡、🟢の順）に並びます。各カードには次の内容が表示されます。

• 上段：緊急度ドット＋アクションバッジ＋タイプタグ＋シェブロン（すべて .sc-header 内で1行に表示）
• 見出し（font-size 12px、font-weight 500）
• 1行のコンテキスト（font-size 11px、控えめな色）
• 下段：メタデータ＋↗ ソースリンク — margin-top:auto と上罫線でカード下部に固定し、同じ行のカードが視覚的に揃うようにします
• 展開すると推奨アクションを表示します — カードをクリックして展開します（クリックリスナーは .sc ではなく .sc-top に設定し、ソースリンクのクリックを通過させます）

グリッドレイアウトの CSS： .feed { display:grid; grid-template-columns:repeat(auto-fill,minmax(215px,1fr)); gap:8px } — auto-fill によって、収まる限りの約215px幅の列を並べます（一般的な表示幅では横に2～3列）。これによりフィードを短く保ちます。狭い幅で1列にまとまる可能性があるため、固定の repeat(2,...) に戻さないでください。 .no-sigs は両方の列にまたがります： grid-column:1/-1

フィード上部のフィルターバー：

• メイン：表示タブ — All / 🔴 Act now / 🟡 Monitor / 🟢 Good / Mischar. — クリック可能な統計カードと連動
• サブ：折りたたまれた「Refine」ボタン → 展開するとアクションタイプとシグナルタイプのピルを表示
• 適用中のフィルターは「Clear all」付きの解除可能なチップで表示

すべてのフィルターは重ねて適用されます。シグナル数はリアルタイムで更新されます。「一致するシグナルはありません」の空状態は全幅にまたがります。

3. 誤認トラッカー 専用パネルです — 誤認が見つかった場合にのみ表示します。2列レイアウトです。

左列：主張（発言内容、ソース、リーチ） 右列：訂正（正確な内容＋推奨する返信文）

各行には、推奨する訂正文をクリップボードにコピーする COPIED ボタンがあります。ステータスバッジ：SPREADING（取り上げられている場合）／CONTAINED（単一のソースの場合）／CORRECTED（すでに対処済みの場合）。

4. 競合対応パネル 競合モニタリングが有効な場合にのみ表示します。競合ごとに1枚のカードを表示し、次の内容を含めます。

• 競合名
• 競合の対応（コンテンツの公開、ツイート、対抗発表、沈黙）
• 緊急度の評価
• 推奨する対抗策

5. カバレッジの概要 コンパクトな統計行：シグナル総数 · 報道での言及 · コミュニティスレッド · ソーシャルメディアでの言及 · 誤認 · 競合の動き · 平均センチメントスコア

インタラクション要件（JS のクリックハンドラー — CSS の hover は使用しない）：

• シグナルカード：クリックして推奨アクションのテキストを展開／折りたたみ
• ベロシティチャート：データポイントをクリックして、その時間帯のフィードに絞り込む
• フィルターボタン：3つのフィルター行はそれぞれ独立して重ねて適用
• 誤認のコピーボタン：訂正文をクリップボードにコピー
• すべてのフィルターに、一致するシグナル数をリアルタイムで表示

スタイル：

• 背景：var(--color-background-primary) — 外側は透明にし、ホストのスタイルを継承
• カード背景：var(--color-background-primary)、枠線は 0.5px solid var(--color-border-tertiary)
• セクションの背景：var(--color-background-secondary)
• テキスト：var(--color-text-primary) / var(--color-text-secondary) — ハードコードは禁止
• 等幅フォント：メタデータフィールドには 'SF Mono', 'Fira Code', monospace
• 緊急度の色：赤 #A32D2D · アンバー #854F0B · 緑 #3B6D11
• アクションバッジの色：RESPOND/ESCALATE は赤の色合い · CORRECT はアンバーの色合い · AMPLIFY は緑の色合い · WATCH はグレーの色合い
• ソースリンク：color: #185FA5 — インラインの <a href> タグを使用し、枠線や背景は設定しない
• 暗い背景色のハードコードは一切使用しないでください

---

Markdown 出力仕様（launch-monitor-{YYYY-MM-DD}.md）

# Launch Monitor — [Product Name]
**Launch date:** [DATE]
**Monitored window:** [DATE RANGE]
**Generated:** [TIMESTAMP]
**Total signals:** [N]

## TL;DR
[2-3 sentences: overall sentiment read, count of act-now items, single most urgent signal or mischaracterization]

## Summary
- Act now: [N] | Monitor: [N] | Good signals: [N] | Noise: [N]
- Mischaracterizations found: [N]
- Competitor moves: [N]
- Overall sentiment: [Positive / Mixed / Negative / Trending negative]

## Signal Feed

### 🔴 Act Now
- **[RESPOND/CORRECT/ESCALATE]** | [Signal type] | [Headline]
  Context: [One sentence]
  Source: [outlet] · Reach: [estimate] · [Time since launch]
  Action: [Suggested action]

### 🟡 Monitor
...

### 🟢 Good Signals
...

## Mischaracterizations
| Claim | Source | Reach | Correct version | Status |
|---|---|---|---|---|
| [What was said] | [Source] | [Reach] | [Accurate version] | SPREADING/CONTAINED |

## Competitor Moves
- **[Competitor]:** [What they did] — [Suggested counter-move]

## Source Index
- [URL] | [Source] | [Date] | [Urgency] | [Action]

## What This Means
[2-3 sentences: what the signal pattern implies for launch trajectory; the single most important action for the team to take right now]

---

保存済みの設定

オンボーディング後、1度だけ次のように尋ねます。

"次回から質問を省略できるよう、設定を保存しますか？いつでも '設定を変更' と伝えれば更新できます。"

保存する内容：製品名、主要な競合、ローンチ期間の設定、詳細度の設定。

---

配布

出力をインラインで表示し、ファイルを保存した後、references/memory-and-distribution.md に従って共有を提案します（コネクターの検出、AskUserQuestion のフロー、Notion／Slack の選択肢）。

スキル固有の振り分け：launch-monitor-{YYYY-MM-DD}.md を Notion に送信します（レポート全文）。Act Now シグナルは Slack にのみ投稿します。~/.nimble/business-profile.json の integrations に保存先が設定されていればそれを使用し、設定されていなければユーザーに確認して次回に備えて保存します。

---

再実行時の動作

日付範囲の計算には、references/nimble-playbook.md の Smart Date Windowing パターンに従い、プロファイルの last_runs.launch-monitor を使用します。

ユーザーから監視の再実行または更新を依頼された場合：

「前回の実行日時以降の新しいシグナルを調査し、ウォールームを更新します。監視リストに追加するものはありますか？」

前回の実行以降に発生した新しいシグナルのみを提示します。未解決の誤った記述と未完了のアクション項目は引き継ぎます。

---

関連スキル — 次のステップ

ウォールームを提示した後、## What This Means セクションで関連する次のステップを提案します。

• 継続的なブランド監視： アクティブなローンチ期間が終了したら（通常、ローンチ後2～4週間）、継続的なブランド健全性の追跡を brand-mention-monitor に引き継ぐことを提案します。このスキルは、ローンチ時の急増ではなく、定常的な監視に最適化されています。
• 競合他社のフォローアップ： ローンチ期間中に競合他社が大きな動きを見せた場合は、より詳細で継続的な競合情報の収集に competitor-intel を提案します。これは、メッセージング、ポジショニングの変化、対抗するナラティブの展開を継続的に追跡します。
• 消費者の感情： 製品が消費者向けで、初期の利用データが蓄積されている場合は、ローンチ時の報道サイクルにとどまらず、実際のユーザーが製品をどのように体験しているかを追跡するために consumer-sentiment-monitor を提案します。

---

重要度のしきい値

以下のシグナルは除外します。

• 同じ名前の別の製品について明らかに言及しているもの（コンテキストのプロファイリングでフィルタリング）
• 自動化されたボットやスパムアカウント
• 新しい情報を含まない重複報道（通信社記事の転載）
• 拡散の見込みがなく、リーチが一桁のもの

以下はフラグを立てますが、優先度は上げません。

• 製品を正確に説明している中立的な報道
• 対応不要のポジティブなシグナル