knock-product-messaging-strategy

プロダクトメッセージング戦略スキル

プロダクトを、単発の通知を寄せ集めたものではなく、一貫性のあるメッセージングシステムにします。このスキルでは、効果的なメッセージングに関するプロダクトリーダー向けガイドを、Knock で利用できる計画とリソースを作成するエージェントの手順として具体化します。

関連マニュアル：

• アプリ内メッセージングのベストプラクティス
• トランザクションメール
• 通知インフラストラクチャ

出力要件（必須）

計画の全文をリポジトリのルートにある knock-plan.md に書き込みます。チャットは最小限にとどめ、ステータスと確認のみを伝えます。rules/knock-plan-file.md に従ってください。

推奨事項の概要、分類表、チェックリストの全文をチャットに貼り付けないでください。コンテキストの共有や knock-setup への引き継ぎには、計画ファイルを信頼できる情報源として使用します。

概要

メッセージングシステムを設計または監査する際は、以下のルールファイルを順番に確認します。詳細な調査結果はその都度 knock-plan.md に記載し、チャットでは説明しません。

1. データ基盤とトリガー — 意味のあるプロダクト上のタイミングとイベントペイロード
2. 受信者と担当 — 誰が、なぜメッセージを受け取るべきか
3. 配信戦略 — チャネル、エスカレーション、タイミング、停止条件
4. 配信量とバッチ処理 — 頻度制御とダイジェスト
5. 関連性と設定 — パーソナライズと設定の分類
6. 測定とレビュー — 成果、疲労の兆候、ローンチチェックリスト
7. Knock で適用 — 計画をワークフロー、ガイド、オーディエンス、設定に対応付ける

このスキルの使い方

プロダクトのメッセージングシステムを設計する

1. プロダクトについて調査します（コードベース、イベント、ロール、ライフサイクル）。必要に応じて、確認の質問は最大 3 つまでにします。
2. rules/data-foundation-and-triggers.md に従って、意味のあるタイミングと必要なイベントデータを洗い出し、knock-plan.md に記載します。
3. 価値の高いタイミングごとに、次のルールファイルを使って受信者、配信、配信量、設定を決定し、チャットではなく計画ファイルを更新します。
4. 成長への効果に基づいて優先順位を付けます。アクティベーション、リテンション、収益回復、そして優先度の低い通知の順です。
5. 計画内で実装準備完了とする前に、すべての候補を rules/measurement-and-review.md に照らして確認します。
6. rules/apply-in-knock.md を使って、計画内の Knock の構成を充実させます（または、ユーザーから明示的に依頼された場合に限りリソースを作成します）。接続されている場合は、Knock MCP / CLI を優先して使用します。
7. チャットでは、knock-plan.md を示すステータスを 1 行で伝えた後、どの項目を実装するかを尋ねます。確認の質問は最後に置き、太字にします。

既存の通知プログラムを監査する

1. 現在のワークフロー、ガイド、チャネル、設定カテゴリを knock-plan.md の「監査」セクションに一覧化します。
2. 各項目を rules/measurement-and-review.md のレビューチェックリストに照らして評価します。
3. 停止条件の不足、対象受信者の条件が広すぎること、チャネルでのスパム、設定の不足をファイル内で指摘します。
4. チャットでは、ステータスを 1 行で伝えた後、次に実行する修正／統合／廃止の項目を尋ねます。

セットアップまたは実装に引き継ぐ

• 戦略の承認後に Knock を新規セットアップする場合は、knock-setup に進みます。
• コピーやチャネルごとの書式設定には、knock-notification-best-practices を使用します。
• アプリ内ガイドの UI には、knock-in-app-ui を使用します。
• ローカルでのリソース管理には、knock-cli を使用します。

knock-setup に引き継ぐ際は、knock-plan.md のセットアップへの引き継ぎを更新し、同じリストをチャットでも渡します（ユーザーから依頼がない限り、優先順位を付け直しません）。

### Setup handoff
- **plan.** knock-plan.md
- **confirmed.** [names or indexes]
- **skipped.** [names or indexes]
- **deferred / blocked.** [names + reason]

knock-setup は confirmed を確定済みの情報として扱い、詳細を knock-plan.md から読み取り、再調査を省略する必要があります。

ルールファイルのリファレンス

• rules/knock-plan-file.md — 計画ファイルのパス、構成、チャットの簡潔さに関するルール
• rules/data-foundation-and-triggers.md — イベント、ペイロード、モーメントの種類
• rules/recipients-and-ownership.md — 受信者の選定とエスカレーション
• rules/delivery-strategy.md — チャネルの段階的な利用とタイミング
• rules/volume-and-batching.md — 頻度、クールダウン、ダイジェスト
• rules/relevance-and-preferences.md — コンテキスト、パーソナライズ、設定
• rules/measurement-and-review.md — 成果、通知疲れ、リリース基準
• rules/apply-in-knock.md — 決定事項をKnockのプリミティブにマッピング

クイックリファレンス

4つのモーメントの種類

1. ユーザーが求めた成果 — エクスポート完了、決済送信（通常は即時）
2. 共同作業 — メンション、割り当て、承認（即時またはまとめて通知）
3. 製品またはアカウントの状態変化 — インテグレーション停止、使用上限、決済失敗
4. 時間に基づく条件 — トライアル終了、オンボーディング未完了、承認期限超過

構築前に必ず確認すること

• トリガーは、曖昧な非アクティブ状態の推測だけでなく、意味のある状態変化を表している
• 受信者は、次のアクションに責任を持つ人である
• 主要チャネルとエスカレーション経路を定義している
• 停止／キャンセル条件を定義し、遅延後に再確認する
• 設定カテゴリを割り当てる（またはトランザクション／サービス上重要であることを明示する）
• 成功指標は開封率だけでなく、製品の成果である

成長施策の優先順位

1. アクティベーション／価値実現までの時間
2. コアループのエンゲージメント（コラボレーション、習慣）
3. 収益の保護（決済失敗、トライアル、上限）
4. 状態を正確に捉えた再エンゲージメント／呼び戻し
5. お知らせと教育（割り込み度が最も低い）