Skills
エージェント向けにパッケージ化された専門スキルと手順を 96,981 件掲載。コマンド 1 行でインストールできます。
マーケティング・グロース
ユーザーが Product Hunt でのローンチ、PH への投稿準備、またはローンチ当日の計画（hunter、最初のコメント、タイミング、アップボート）を希望する場合に使用します。「Product Hunt」「launch on Product Hunt」「PH launch」「Product Hunt submission」「hunter」「Product of the Day」「upvotes」「Product Hunt first comment」に言及した場合も使用します。PH 以外の複数プラットフォームへのディレクトリ掲載や、そのまま貼り付けられる文案には directory-submission を使用します
ユーザーが「コメント、DM、メンションをトリアージして」「このスレッドへの返信を下書きして」「このファン投稿を再投稿できる？」「受信箱の SLA とエスカレーション経路を設定して」と依頼した場合に使用します。語調の検出（誠実／皮肉／演技的／パラソーシャル関係、感情反転表を含む——コメディの語調での「ひどすぎる」は称賛）を備えた優先順位付きトリアージキュー、コメント投稿者の分類（監視のみの荒らし／激怒者／誤解している人／不満を抱く顧客／支持者）と対応レベル、チャネルごとの SLA、危機対応経路までのエスカレーションマトリクス、モデレーション段階と自社スペースのルール、日付入りの許可記録をチャネル台帳に送る UGC のキュレーションと権利管理モードを作成します。返信はすべて人が投稿する優先順位付きの下書きで、自動送信は一切ありません。ローンチ期間中のフィードバックトリアージには使用せず、launch-feedback-synthesizer を使用してください。コメント・DM・メンションのトリアージ／語調検出／返信下書き／UGC 許可
ユーザーが「広告が疲弊しているか」「規模拡大に伴って CTR が低下する理由」「クリエイティブをローテーションする／オーディエンスを広げるべきか」と尋ねた場合に使用します。フリークエンシー、CTR、CVR の低下を配信初期のベースラインと比較し、クリエイティブのローテーション／オーディエンスの拡大／現状維持のトリガーと、広告セットごとの疲弊状況を提示します。代替クリエイティブの作成には ad-creative-builder、RQS スコアや拒否判定には ad-account-auditor を使用してください。广告疲劳检测/频次管理/换素材还是扩人群
ユーザーが「ニュースレターを収益化」「スポンサー料金表を作成」「有料購読の収益を試算」などと依頼したときに使用します。収益モデル（有料プラン、広告 / スポンサー枠と CPM / 固定料金表、紹介 / ブーストのループ）、購読者リストの成長 ↔ 収益予測、SEND-D レバーに関する誠実なオファー / 開示チェックを作成します。プログラム全体の評価や D1 の実行には使用せず、email-quality-auditor を使用してください。リターン計算には roi-calculator、クリック後のページには landing-optimizer を使用してください。邮件newsletter变现/赞助刊例/付费订阅测算
ユーザーが「リストの健全性を継続的に監視する」「反応が減った／エンゲージメントのない購読者を定期的に検出する」「開封率が下がり続ける／バウンスが増えている理由を調べる」「再同意依頼と整理の作業リストを作る」と依頼した場合に使用します。定期的な SEND リスト減衰・抑制リストの変動監視を実行します。エンゲージメントの最終時期別コホート（30／90／180／365 日）、ハードバウンスとスパム苦情の傾向とベンチマークの比較、抑制リストの増加／漏れの確認、SEND S（リスト衛生）および E（エンゲージメント減衰）のサブ項目に紐付く、セグメント別の再同意依頼／配信終了／整理の作業リストが含まれます。送信前の一度限りの認証チェックには使用せず、deliverability-qa を使用してください。同意／抑制レコード自体には使用せず、consent-registry を使用してください。EQS の計算や拒否判定の適用には使用せず、email-quality-auditor を使用してください。メールリストの健全性監視／抑制リストの変動／休眠ユーザーの整理
ユーザーが「ブランドへの言及を監視」「ソーシャルリスニングを設定」「今週、話題が急増したか」「これらのアカウントで購入の兆候を監視」などと依頼したときに使用。常時稼働するキー不要のリスニングを実行します。バージョン管理されたリスニングクエリアーキテクチャ（スペルミスや中国語名を含むブランドのバリエーション、除外語、HN Algolia / Bluesky / GDELT / Tavily 向けのソース別構文）、6 種類（危機 / バグ / 見込み客 / 賞賛 / 質問 / スパム）に分類してそれぞれ SLA に従って振り分ける言及スキャン、急増フラグ付きの 7 日間ローリングベースライン（危機トリガーの入力）、B2B トリガーのウォッチリスト（資金調達 / 採用 / ローンチの兆候）、および対象範囲の明示的な開示（X/IG/TikTok/LinkedIn/小红书の数値は実測値ではなく、プロキシ指標として表示）を提供します。ローンチ期間のテレメトリー（T-0→T+30 の順位およびレビューのポーリング）には使用せず、launch-monitor を使用してください。舆情监听/品牌提及监测/基线突刺/触发信号
ユーザーがソーシャルチャネルの登録／照会、チャネルの状態、投稿頻度、ガバナンス、語調の調整、UGC の許可、または支持活動に関する事実の記録を依頼した場合に使用します。追記専用の channels イベントストリームと派生ビューを通じて整理します。ECHO スコアリングには使用せず、social-quality-auditor を使用してください。チャネル選定には使用せず、channel-portfolio-planner を使用してください。チャネル台帳／アカウント記録／UGC 許可記録
ユーザーが「アーリーアクセスプログラムを設計して」「ウェイトリストとベータ段階を設定して」「ベータの移行基準を定義して」と依頼した場合に使用します。ウェイトリスト→コンセプト→アルファ→ベータ→GA の段階構成を作成し、各段階の目的とオプトインの意味、各段階の定量的な移行基準（推定と明記）、コホートの参加制限と招待数の調整計画、テスター募集とローンチ当日のソーシャルプルーフ準備、すべてのステータス変更で購読者に通知するフィードバックループ仕様、紹介ループの仕組み（招待コード、不正防止）を作成します。ウェイトリスト獲得戦略や登録フローの仕様には使用せず、list-growth-designer を使用してください。正式な段階記録には使用せず、launch-registry を使用してください。ウェイトリスト／ベータ段階／アーリーアクセス／移行基準／フィードバックループ
ユーザーが「現在、各タッチポイントで何を伝えているか整理」「現在のメッセージを棚卸し」「伝えていることと意図のギャップを特定」と依頼した場合に使用。ナラティブのベースラインを作成します。ホームページ、料金ページ、ドキュメント、資料、ソーシャルプロフィール、メールのフッターなど、自社が管理するすべてのタッチポイントの現時点での訴求を個別に一覧化し、各項目に Measured / User-provided / Estimated のラベルを付与します。さらに、意図したメッセージとのタッチポイントごとのギャップ分析と、Evaluate フェーズで今後のずれを測定するためのドリフトベースラインのスナップショットを作成します。規範となるメッセージの作成には message-system-architect、タッチポイントの評価や拒否判定には narrative-quality-auditor を使用してください。現状のナラティブ棚卸し／各タッチポイントの表現／意図とのギャップ／ドリフトベースライン
構造、コード例、開発者読者向けの慣例を踏まえた技術ブログ記事の執筆。記事の種類、コードのフォーマット、説明の深さ、開発者特有のエンゲージメントパターンを扱う。用途：エンジニアリングブログ、開発者向けチュートリアル、テクニカルライティング、開発者向けコンテンツ、ドキュメント記事。トリガー：technical blog、dev blog、engineering blog、technical writing、developer tutorial、tech post、code tutorial、programming blog、developer content、technical article、engineering post、coding tutorial、technical content
ユーザーが「ローンチのフィードバックをトリアージ」「レビュー、コメント、掲示板の投稿をテーマ別に分類」「『要望を受けて、対応しました』のフィードバックループを構築」などと依頼したときに使用します。フィードバックテーマの要約（テーマごとの頻度、深刻度、代表的な引用）、重複統合と通知ルールを含む open→planned→started→completed/declined のステータスループ、リリース済み変更の告知素材、規約に準拠したソーシャルプルーフ収集プロトコル（ストアレビューへのインセンティブ付与は行わない）を作成します。収集したソーシャルプルーフの再利用や拡散には使用せず、content-amplifier を使用してください。推薦コメント獲得のためのアウトリーチ実施には使用せず、outreach-manager を使用してください。反馈分诊/状态环/社证收割/评测合规
ユーザーが「ブランドナラティブを監査して」または「このメッセージはブランドの規範に沿っているか」と依頼した場合に使用します。TALE の真実性、システム、または有効性の各プロファイルを個別に実行し、単一の複合評価に平均化することはありません。差別化、ブランド規範、ランディングページとの一貫性、証拠の完全性を確認します。ローンチ準備度には使用せず、launch-readiness-auditor を使用してください。ソーシャル運用には使用せず、social-quality-auditor を使用してください。ブランドナラティブの階層別監査／公開前の一貫性確認
ユーザーが「ローンチ当日を指揮して」「ローンチ当日のランブック／ウォールームを作成して」「プッシュ後に CONTINUE か ROLLBACK かを判断して」と依頼した場合に使用します。ローンチ前提条件のゲートチェック（launch-readiness-auditor の SHIP 判定と launch-registry の正式日付の両方が必須。いずれかが欠ける場合はスキルを停止）、日付と担当者を含む時間帯別ランブック（午前の不可逆なプッシュ、日中の監視ループ、夕方の集約）、不可逆なアクションごとに事前定義した停止基準に照らして行う強制的な観察ウィンドウ判定、ロールバック手順を含む P0～P3 のインシデント段階、レジストリ提案プロトコル用の T-0 ステータス行を作成します。チャネルへの投稿内容やプラットフォームルールには使用せず、community-launch-runner を使用してください。メディアへの返信には使用せず、press-media-relations を使用してください。ローンチ日ランブック／ウォールーム／観察ウィンドウ／ロールバック判定／ローンチ日指揮
ユーザーが「リリース日を決めて」「リリース期間を計画して」「禁輸期間と解禁時刻を設定して」と尋ねた場合に使用します。業界イベントの周期と競合のリリースカレンダーを基に、候補期間ごとの競合・追い風・リスクを比較する表、リリース週にまとめて公開するか段階的に公開するかの判断、ストア審査のバッファ（Estimated と表示）、および解禁時刻とタイムゾーンを含む禁輸期間の定義を作成し、候補としてリリース登録簿に提出します。文化的なタイミング自体の判断には使用せず、trend-spotter を使用してください。リリース当日の実行には使用せず、launch-day-conductor を使用してください。发布择时/发布窗口/竞品日历/禁运期窗口/审核缓冲
ユーザーが「プリファレンスセンターを構築して」「配信頻度の段階的引き下げを設定して」「退会ではなく段階的な引き下げを提示して」または「トピック／配信頻度のプリファレンスページを設計して」と依頼した場合に使用します。プリファレンスセンターのフィールド仕様、頻度／トピックの段階的引き下げ（即時の配信停止に代わる段階的な選択肢）、プリファレンスと配信抑制の対応表、および提示するプリファレンスセンター／頻度オプションに関する SEND N 次元のサブ項目メモを作成します。ライフサイクルフローマップや配信頻度のガバナンスには使用せず、email-sequence-designer を使用してください。同意／配信抑制の記録自体には使用せず、consent-registry を使用してください。EQS の計算や N1 の配信停止拒否判定には使用せず、email-quality-auditor を使用してください。メールのプリファレンスセンター／配信頻度の段階的引き下げ設計／配信停止に代わる引き下げ
ユーザーが「ローンチ用のメディアリストを作成」「ローンチのプレスリリースを執筆」「報道解禁前にメディアへ売り込む」などと依頼したときに使用します。3 段階のメディア・アナリストリスト（第 1 層：独占取材候補、第 2 層：専門メディア、第 3 層：コミュニティとニュースレター）、ローンチ登録日を基準にした報道解禁前の売り込み時期の概要、架空の引用や数値を含まない標準構成のプレスリリース草稿、アナリスト向けブリーフィングの概要を作成します。プレスキット素材には使用せず、launch-asset-packager を使用してください。フォローアップの手順設計には使用せず、outreach-manager を使用してください。ローンチ後のニュース反響の監視には使用せず、launch-monitor を使用してください。媒体名单/禁运期pitch/新闻稿/分析师简报
ユーザーが「週次のソーシャルレポートを実施」「エンゲージメント率の分母は何か」「今週の勝ち投稿と次サイクルの変更点は何か」と依頼した場合に使用。オーガニックソーシャル指標の辞書（すべての率に分母を明記。ERR はリーチ基準、ERI はインプレッション基準、ER はフォロワー基準とし、期間をまたいで固定）、投稿ごとの集計は平均ではなく中央値とし、オーガニックとブーストを分離、EMV は明示的なラベル付きの経営層向け換算にのみ使用（スコアには一切含めない）、従業員を除外した CHAOSS／Orbit 形式のコミュニティ健全性分析、次のカレンダーサイクルで利用する最良／最悪パフォーマーの書き戻しを作成します。金額ベースの ROI 計算や ECHO プロファイルの結果ゲート判定には使用せず、roi-calculator と social-quality-auditor を使用してください。ソーシャル週次レポート／エンゲージメント率の分母／指標辞書／振り返り結果の書き戻し
ユーザーが「自社のシェア・オブ・ボイスを追跡して」「競合と比べて会話のどれだけを占めているか」「今四半期の SOV の推移を見たい」と尋ねた場合に使用します。固定された競合パネルを基に、プラットフォームおよび期間ごとに SOV% = ブランドへの言及数 ÷（ブランドとパネル内の競合への言及数）を算出します。パネルを切り替えるとトレンドは無効になるため、ECHO O3 ルールに従って系列を再開し、中断を記録します。感情加重 SOV（人手でコード化されていない場合、感情は Estimated と表示）と、Wikipedia のページビューに基づく注目シェアの代替指標も提供します。キー不要のリスニングコネクター、gdelt.py のニュースエコー、ユーザーのエクスポートデータを使用し、公開カウントのみを扱います。非公開プラットフォームはスクレイピングしません。バックリンクやオフサイト SEO シグナルには使用せず、offsite-signal-analyzer を使用してください。声量份额/竞品声量对比/提及份额/注意力份额
ユーザーが「このローンチを記録」「ローンチ日／エンバーゴを確認」「ステージ移行を記録」「提出内容／成果を更新」と依頼した場合に使用。追記専用の launches イベントストリームでローンチ情報を管理し、楽観的リビジョンと、そこから生成される記録／カレンダービューを提供します。RAMP のスコアリングには launch-readiness-auditor、ティア／期間の計画には launch-tier-planner を使用してください。ローンチ台帳／ローンチカレンダー／ステージとエンバーゴの記録
ユーザーが「ローンチの振り返り／事後分析を実施」「チャネル別にローンチ結果と目標を比較」「次回のローンチで何を継続・中止するか決定」と依頼した場合に使用。構造化された D1/W1/M1 の振り返りを作成します。内容は、チャネル別の実績と目標の比較表（UTM による自社分析データを正確な値として、プラットフォームの自己申告値を参考値として扱い、すべての数値に Measured / User-provided / Estimated のラベルを付与）、最大の未達項目に対する 5 Whys 分析、チャネルごとの継続／中止／変更の判断、次回ローンチに向けた 3～5 件の実行可能な学び、ローンチ台帳に提出する成果スナップショットです。リターン計算（CPA / ROI）には使用せず、roi-calculator を使用してください。ステークホルダー向けレポートの執筆には report-generator、指標の詳細分析には performance-analyzer を使用してください。ローンチ振り返り／チャネル別アトリビューション／5 Whys／継続・中止
ユーザーが「リリースの規模を計画して」「このリリースはどの程度の規模にすべき？」「停止基準を含むリリースリスク台帳を作成して」と尋ねた場合に使用します。ティアの決定（Tier 1 全チャネルの旗艦リリース / Tier 2 ターゲット型 / Tier 3 変更履歴レベル）、リリース種別の宣言（新製品/機能/再リリース/共同マーケティングの分担を含む提携）、工数調整マトリクス（ティアごとのチャネル強度とアセット範囲）、D0/W1/M1 の KPI 目標（Estimated と表示）、リスク台帳（発生可能性 × 影響範囲、担当者、緩和策、停止基準/ロールバック閾値）、T-8w から T+4w までのタイムラインの骨子を作成します。リリース日や期間の選定には使用せず、launch-window-planner を使用してください。クリエイターチャネル向けのリリースキャンペーンには使用せず、campaign-planner を使用してください。发布分级/发布类型/风险登记册/kill criteria
ユーザーが「拡大展開の前にメッセージをテスト」「メッセージ・マーケットフィットのパネルを設計」「新しいタグラインの 5 秒理解度テストを実施」と依頼した場合に使用。TALE Evaluate フェーズ用のメッセージテスト設計仕様を作成します。仮説、パネルと参加者募集の基準、理解度／5 秒／メッセージ・マーケットフィット（Wynter 形式）の手順、規範となるメッセージから選んだテスト素材、成功基準、停止／修正の判断ルールを含み、有料展開の拡大前にメッセージを検証します。テストを設計しますが、実験の実施や主張の判定は行いません。パネルや A/B 実験の実施には send-experiment-designer または ad-test-designer、結果分析には performance-analyzer、メッセージ自体の作成には message-system-architect を使用してください。メッセージテスト／理解度テスト／パネル設計／5 秒テスト／メッセージ・マーケットフィット
ユーザーが「すべてのタッチポイントにナラティブをどう届けるか計画して」「タッチポイント別のメッセージ適合仕様を書いて」「基本方針をもとに各クリエイティブ担当者向けのブリーフを作って」と尋ねた場合に使用します。narrative-registry の基本方針を、主要な各タッチポイント（ホームページ、料金ページ、ストア掲載、営業資料、ソーシャルプロフィール、ドキュメント、メール）に適用し、各タッチポイントが含めるべき主張、柱、根拠、反論の捉え直しを定めたメッセージ適合仕様を作成します。各分野のクリエイティブ担当者（content-writer、ad-creative-builder、email-creative-builder、social-creative-builder、message-house-builder）向けの引き継ぎブリーフも作成し、どこでも一貫したストーリーを伝えます。完成済みのタッチポイント別コピーには使用せず、各分野のクリエイティブ担当者を使用してください。ティア別のローンチアセット一覧には launch-asset-packager、タッチポイント間の一貫性評価には narrative-quality-auditor、主張の裁定には offer-claims-registry を使用してください。ナラティブ展開／タッチポイント別メッセージ適合／クリエイティブ引き継ぎブリーフ／キャンバスへの反映
ユーザーが有料キャンペーンの変更を「振り返る」、「この広告変更は効果があったか」、「変更前後の ROAS／CPA を比較」と依頼した場合に使用。固定の振り返り期間で対照群と比較して ROAS／CPA を読み取り、計算は roi-calculator に委任したうえで、Promote / Keep-testing / Rollback / Unproven の判断を返します。RQS のスコアリングや拒否判定には ad-account-auditor、ROI 比率の計算には roi-calculator、チャネル横断の集計には performance-analyzer を使用してください。有料広告の振り返り／ROAS の再評価／広告効果のアトリビューション
ユーザーが「メールの A/B テストを設計」「件名／CTA の多変量テストを設定」「配信時間テストを実施」「ホールドアウトグループを作成」、または「このメール結果は統計的・実務的に意味があるか」と依頼した場合に使用。反証可能な仮説、セルごとに変数を 1 つに絞ったマトリクス、サンプルサイズ／MDE／期間／検出力の計画、自社 ESP データに基づく効果と不確実性の評価を作成します。事前に決定し、オーナーが承認したアクションルールのみを適用します。このヘルパーが業務上のアクションを選ぶことはありません。EQS／拒否判定やメールの執筆には使用しません。メール A/B テスト設計／多変量テスト／配信時間テスト／ホールドアウトグループ／有意性の判定
ユーザーが「このプラットフォームの規範カードを作成して」「ここでの文字数制限と折り返し位置は？」「LinkedInで最初のコメントにリンクを置く慣習は文書化されているのか、それとも俗説か」「古くなったプラットフォームカードはどれか」と尋ねた場合に使用します。references/platforms/パック内の、日付とバージョンが付いたプラットフォーム別規範カード（文字数制限、折り返し位置、ハッシュタグの規範、形式／アスペクト比の仕様、リンクと最初のコメントの配置、開示ラベルの仕組み、アルゴリズム上の重点項目（例：小红书の検索＋保存の重み付け））を管理します。各項目に「プラットフォーム公式資料あり（公式文書、実測）」または「推定・俗説（出典明記）」のラベルと、最終確認日・次回レビュー日を付け、レビュー期限を過ぎたカードは信頼せず、古いものとしてフラグを立てます。既存のパックをそのまま拡張し、二つ目のパックは作りません。運用するチャネルの選定には使用しません。channel-portfolio-plannerを使用してください。プラットフォーム規範カード／文字数制限／折り返し位置／ハッシュタグ／アルゴリズム上の重点／期限切れフラグ
ユーザーが「ローンチ週の後も勢いを維持」「GTM として変更履歴／リリースノートの頻度を計画」「この更新は再ローンチに値するか」と依頼した場合に使用。T+1→T+30 の勢い維持計画を作成します。ローンチ機会のカレンダー（マイルストーン／出荷済みのループ／バッジの機会のみ）、告知ティアの振り分け（メジャー＝全チャネル、ミディアム＝ターゲット指定、マイナー＝変更履歴のみ）、再ローンチの妥当性判断、急増した注目を自社チャネルにつなぐ引き継ぎブリーフ、ローンチ間隔を考慮した次の Tier-1 の機会を含みます。30 日間のコンテンツ再利用マップや有料増幅の実行には content-amplifier、次回ローンチのエンドツーエンド計画には launch-tier-planner を使用してください。第 2 週の失速対策／GTM としての変更履歴／再ローンチ／次のローンチ機会
ユーザーが「全員が同じストーリーを語れるようにして」「エレベーターピッチの段階別原稿を書いて」「広報担当者向け Q&A と承認済み定型文パックを作って」と尋ねた場合に使用します。narrative-registry の基本方針、メッセージハウス、ブランドボイスから、再利用可能なイネーブルメントキットを作成します。内容はエレベーターピッチの段階別原稿（10秒／30秒／2分）、広報担当者向け Q&A（難しい質問と基本方針に沿った回答）、承認済み定型文／プロフィールのパック（25／50／100語）、表現の推奨・禁止事項一覧です。営業、サポート、創業者、パートナーが一貫したストーリーを伝えられるようにします。ローンチ当日の運用手順書には launch-day-conductor、チャネル別の完成コピーには content-writer または各分野のクリエイティブ担当者、ローンチ期間のバトルカードには sales-enablement-kit を使用してください。このキットは主張の裁定を行いません。ナラティブ・イネーブルメントキット／エレベーターピッチの段階別原稿／広報担当者向け Q&A／承認済み定型文／表現の推奨・禁止事項
ユーザーが「公開前に参加の立ち上げを計画したい」「このコミュニティでアカウント履歴や karma がどれくらい必要か」「自分たちの Discord の参加インセンティブとメンバーライフサイクルを設計してほしい」と尋ねたときに使います。コミュニティごとの公開前ウォームアップ計画を出力します。アカウント履歴・継続年数の期待値（見積もり、出典明記）、先に与え後に求める台帳の仕様、最終確認日を付したコミュニティごとのマナー + ルール要約、および channel-registry が状態遷移の証拠として求めるウォームアップ → アクティブ卒業基準を含みます。さらに、所有コミュニティ向け版（自分の Discord/Slack/フォーラム/企业微信私域向けの参加導線 + メンバーライフサイクル）もあります。公開日の投稿や T-0 のスレッドには使わず、community-launch-runner を使ってください。コミュニティのウォームアップ/先に与え後に求める/アカウント育成/卒業基準
ユーザーが「創業者の話し方を明文化して」「創業者のボイスドシエを作って」「コンテンツの柱を設定して」と尋ねた場合に使用します。ユーザー自身の投稿、メール、資料のみを対象に、特徴の80％を抽出するインタビューを行います（競合のスクレイピングや架空のペルソナ作成は行いません）。バージョン管理されたボイス記録を作成します。内容はプラットフォーム別のレジスター対応表（小红书／微信公众号を含む）、禁止フレーズ、状況別の開示文（ECHO C2 の上流）、本人の投稿のみから作成した few-shot バンク、推定配分率付きのコンテンツピラー 3～5 個です。memory/events/channels.ndjson 経由で提出し、channel-registry が voice-dossier.md として保存します。この記録は Craft フェーズの各スキルが最初に読み込みます。ブランド全体のボイス方針には brand-language-codifier、オーディエンス／ペルソナ調査には audience-mapper を使用してください。ボイスドシエ／ブランドボイス／創業者のボイス／コンテンツピラー／開示文
ユーザーが「各タッチポイントが基本方針から逸脱していないか確認して」「競合のポジショニング変更を監視して」「いつポジショニングを変更すべきか定義して」と尋ねた場合に使用します。ドリフトレポートを作成します。内容は、narrative-registry の基本方針に対する主要タッチポイントごとの経時的な自己ドリフト（wayback.py を使用。変更履歴は基準日付きで実測）、競合のポジショニング変更アラート、明示的なポジショニング変更トリガー条件、D1/W1/M1 のメッセージ変化の振り返り（意図した浸透と実際の浸透、証拠ラベル付き）です。TALE L のドリフト監査サブ項目と narrative-whiplash ガードレールの事実基盤に反映します。タッチポイント公開前の初回一貫性確認には narrative-cascade-planner、TALE プロファイル結果の算出や拒否条件の実行には narrative-quality-auditor、エコー率／AI 回答の共鳴度測定には narrative-resonance-monitor を使用してください。自己ドリフト監視／競合ポジショニング変更アラート／変更トリガー／ナラティブドリフトの振り返り
ユーザーが「ナラティブの浸透度を測りたい」「エコー率を自社の基準語彙と照合して追跡したい」「AI回答エンジンが自社ブランドをどう表現するか確認したい」と依頼した場合に使用します。共鳴レポートを作成します。内容は、エコー率（市場の言葉とnarrative-registryの基準語彙の重複度。手法を明記）、tavily.py --answerによるAI回答の認知（代理指標と明記）、固定した競合パネルでの声のシェア（share-of-voice-trackerを再利用）、bluesky.py / gdelt.py / pageviews.pyからの共鳴シグナルです。すべての数値に「実測／代理指標／ユーザー提供」のラベルを付け、TALEのE次元およびE1の証拠完全性による拒否判断の上流に提供します。声のシェアの仕組みの再構築には使用せず、share-of-voice-trackerを使用してください。自社サイトのGA4/GSC分析には使用せず、performance-monitorを使用してください。TALEプロフィール結果の採点には使用せず、narrative-quality-auditorを使用してください。主張の裁定には使用せず、offer-claims-registryを使用してください。エコー率／AI回答の認知／声のシェア／共鳴シグナル
投資家向けピッチデッキの構成、スライドごとのフレームワーク、ビジュアルデザインのルール、データの提示方法を扱います。12 枚のフレームワーク、グラフの種類、チーム紹介スライド、投資家に敬遠されがちな要素を取り上げます。用途：資金調達デッキ、投資家向けプレゼン、スタートアップのピッチ、デモデー、助成金の提案書。トリガー：ピッチデッキ、投資家向けデッキ、スタートアップのピッチ、資金調達デッキ、デモデー、ピッチプレゼン、投資家向けプレゼン、シードデッキ、シリーズ A デッキ、ピッチスライド、スタートアップのプレゼン、VC ピッチ、投資家とのミーティング
レイアウトパターン、件名の公式、配信到達性のルールを備えたメールマーケティングのデザイン。ウェルカムシーケンス、プロモーションメール、トランザクションメールのテンプレート、モバイル最適化を扱います。用途：メールマーケティング、ニュースレターのデザイン、ドリップキャンペーン、メールテンプレート、トランザクションメール。トリガー：email design、email template、email marketing、newsletter design、email layout、email campaign、drip campaign、welcome email、promotional email、transactional email、email subject line、email header image、email banner。
ブランドナラティブのカノン、タグライン、メッセージ階層、トーンや命名規則の記録・照会、またはカノンの再バージョン化をユーザーが求める際に使用します。追記専用のナラティブストリームと派生ビューを通じて、完全なバージョン管理付きカノンイベントを整理します。TALE の評価には使用しないでください——narrative-quality-auditor を使用します。システムの作成には使用しないでください——message-system-architect を使用します。ブランド叙事台账/canon 记录/语气与命名规范
出品者向けのAmazon競合モニタリングと競合インテリジェンス。競合ASINの価格変更、在庫レベル、新製品の発売、レビュー増加ペース、広告パターンを追跡します。値下げ、在庫切れ、市場の変化に関するモニタリングアラートを設定できます。12のAmazonマーケットプレイスに対応。APIキーは不要です。次の場合に使用します：（1）競合他社の価格戦略の監視、（2）競合他社の在庫や在庫パターンの追跡、（3）カテゴリー内の新製品発売の検出、（4）競合他社のレビュー増加ペースと評価の分析、（5）競合他社の不足点から市場機会を特定、（6）競合アラートとベンチマークの設定。
コンテンツの原子化——1 つのコンテンツを多様なフォーマットに変換。ブログからスレッド、ブログからカルーセル、ポッドキャストからブログ、動画から引用など。用途：コンテンツマーケティング、SNS、マルチプラットフォーム配信、コンテンツ戦略。トリガー：content repurposing、repurpose content、content atomization、content recycling、one to many content、multi platform content、cross post、adapt content、reformat content、blog to thread、blog to video、podcast to blog、content multiplication
フックの公式、フォーマット規則、エンゲージメントのパターンを踏まえた LinkedIn 投稿の作成。投稿タイプ、アルゴリズムのシグナル、文字数制限、コンテンツの柱を扱う。用途：LinkedIn 投稿、プロフェッショナル向けコンテンツ、ソートリーダーシップ、B2B コンテンツ、個人ブランディング。トリガー：linkedin post、linkedin content、linkedin writing、linkedin strategy、linkedin engagement、linkedin algorithm、linkedin hook、linkedin formatting、thought leadership、professional content、b2b content、linkedin growth
ユーザーがバイラルなフックを求めた場合、または以下の例に一致するタスクで使用します。ユーザーの動画の冒頭に 4 秒のバイラルフックと任意のデザインタイトルを追加し、その後、本編映像にハードカットします。目を引く出来事がユーザー自身のシーン内で起こり、タイトルは Seedance によってシーン内に描画されます。1 回の MCP 呼び出しでレンダリング全体を行います。Pika MCP が必要です。トリガー：「add a viral hook」「disruption hook on my video」「hook + title on my clip」「viral hook with typography」「scroll-stopper intro」。
Open Graph とソーシャル共有画像のデザイン。プラットフォームの仕様、テキスト配置、ブランディングを扱います。OG meta タグ、Twitter カード、LinkedIn プレビュー、動的生成をカバーします。用途：ソーシャル共有画像、ブログのサムネイル、リンクプレビュー、ソーシャルカード。トリガー：og image、open graph、social sharing image、twitter card、social card、link preview image、og meta、sharing preview、social thumbnail、meta image、og:image、twitter:image、linkedin preview。
ユーザーが PR の計画、プレスリリースの作成、メディアリレーションの管理を希望する場合に使用します。"public relations"、"PR"、"press release"、"media relations"、"news release"、"journalist"、"media coverage"、"product announcement"、"earned media" に言及した場合にも使用します。サイト内の「掲載実績」またはロゴページには press-coverage-page-generator を使用してください。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。