ニュースレター作成

ニュースレター作成 は何をしますか？

製品アップデートメールや機能発表ニュースレターを作成します。件名、プレビューテキスト、メール構成、対象読者に適したコンテンツを扱います。

入力の解決

引数（指定された場合）は次の順序で解決します：

1. 既存のマーケティング概要へのパス（.md ファイルで「エグゼクティブサマリー」または「キーメッセージ」を含む） -> マーケティング概要
2. 既存のブログ記事へのパス（.md ファイルでブログ記事構成） -> ブログ記事
3. 既存の変更履歴へのパス（.md ファイルで Added/Fixed/Changed セクション、または CHANGELOG.md） -> 変更履歴
4. GitHub URL または #\d+ パターンに一致 -> PR
5. ... または .. を含む -> Git参照範囲
6. 既存のファイル/ディレクトリに解決 -> コードベース機能
7. それ以外 -> 自由記述テキスト

引数が指定されていない場合は、次のように尋ねます：「ニュースレターの内容は何ですか？マーケティング概要、ブログ記事、変更履歴、PR URL/番号、Git参照範囲、ファイル/ディレクトリパス、または更新内容の説明を提供できます。」

複数の解釈が一致する場合は、ユーザーに確認します。

処理フロー

digraph newsletter {
    rankdir=TB;
    "入力の解決" [shape=box];
    "フェーズ1: 発見" [shape=box];
    "フェーズ2: 設定" [shape=box];
    "フェーズ3: 作成" [shape=box];
    "フェーズ4: レビュー" [shape=box];
    "承認済み？" [shape=diamond];
    "フェーズ5: 出力" [shape=box];

    "入力の解決" -> "フェーズ1: 発見";
    "フェーズ1: 発見" -> "フェーズ2: 設定";
    "フェーズ2: 設定" -> "フェーズ3: 作成";
    "フェーズ3: 作成" -> "フェーズ4: レビュー";
    "フェーズ4: レビュー" -> "承認済み？";
    "承認済み？" -> "フェーズ3: 作成" [label="修正"];
    "承認済み？" -> "フェーズ5: 出力" [label="はい"];
}

フェーズをスキップしないでください。 質問は自然なペースで行ってください。ユーザーが複数の質問に一度に回答した場合は、まとめて回答を受け入れ、先に進みます。

ユーザーが「デフォルトでいい」「あなたが選んで」などと言った場合は、コンテキストに基づいて適切なデフォルトを選び、選択内容を伝え、先に進む前に一度確認を求めます。

確認なしに仮定しないでください。

フェーズ1: 発見

ステップ1 - 入力を分析

入力タイプ	読むべき内容
マーケティング概要	問題提起、価値提案、対象読者、キーメッセージを抽出。ステップ3へスキップ。概要に製品コンテキストがない場合は、ステップ2も実行。
ブログ記事	見出し、要点、対象読者、CTAを抽出。ステップ3へスキップ。製品コンテキストがない場合は、ステップ2も実行。
変更履歴	すべてのエントリを抽出。ダイジェストメールのベースとして使用。ステップ3へスキップ。
PR	Diff、PR説明、レビューコメント、コミットメッセージ（gh pr view、gh pr diff）。大規模PR（20ファイル以上）の場合は、ユーザー向け変更に焦点を当てる。
Git参照	ref間の git diff と git log。広い範囲の場合は、コミットメッセージとユーザー向け変更を優先。
コードベース機能	指定されたファイル/ディレクトリを読む。
自由記述テキスト	ユーザーの説明を解析。詳細が不足している場合、ユーザーに詳細または特定のファイル/PRを指定するよう依頼。それでも詳細がない場合のみ、自由質問にフォールバック。

ユーザー向け変更には、新機能、UI変更、API変更、パフォーマンス改善、バグ修正、ドキュメント更新が含まれます。内部変更には、リファクタリング、テスト追加、CI変更、依存関係のバンプが含まれます。不明な場合は、見つかった内容をリストアップし、どれが関連するかユーザーに尋ねます。

エラーハンドリング：

• gh が利用不可 -> ユーザーに通知、gh auth login を提案、代替入力を提供
• 無効なPR/ref -> ユーザーに確認を依頼
• ファイルが見つからない -> 正しいパスを依頼

ステップ2 - 製品コンテキストを広く読む

存在する場合に読む：README、docs/、package.json（または同等のもの）。

何も見つからない場合、次のように尋ねます：「リポジトリに製品コンテキストが見つかりませんでした。製品とその対象ユーザーについて簡単に説明していただけますか？」

ステップ3 - 理解を提示し形式を決定

構造化された概要を提示します：

「ニュースレターのベースとして以下を使用します：」

• 更新A - 短い説明
• 更新B - 短い説明

「追加、削除、修正はありますか？」

次に、更新の数に基づいてメール形式を決定します：

• 単一の主要な更新 -> 単一機能メール（焦点を絞り、詳細に）
• 複数の更新 -> ダイジェストメール（優先順位付きリスト、最も重要なものを詳しく）

形式をユーザーに確認します。

入力にユーザー向け変更が見つからない場合は、ユーザーに伝えて停止します：「この入力にユーザー向け変更は見つかりませんでした。ニュースレターの対象となるものはありません。」

ユーザーがスコープと形式を確認するまで先に進まないでください。

フェーズ2: 設定

以下の質問をします：

Q1 - 対象読者： 「このメールの送信先は誰ですか？」（全ユーザー、パワーユーザー、新規ユーザー、特定のプラン層、開発者、非技術ユーザー、その他）

Q2 - 出力形式： 「メールの形式は何を希望しますか？」

• コピーのみ - 件名、プレビューテキスト、本文テキスト、CTAテキスト（メールツールに貼り付け）
• Markdown - ほとんどのメールツールがインポート可能な整形済みMarkdown

Q3 - トーン： リポジトリの既存コンテンツ（README、docs、ブログ記事）を読み、製品のVoiceを検出します。その後確認します：

「既存のコンテンツから、トーンは[例：会話調で開発者に親しみやすい]ようです。それに合わせますか、それとも別の方向にしますか？」

分析する既存コンテンツがない場合は、ユーザーに希望するトーンを直接尋ねます。

Q4 - CTA： コンテキストから最も適切なコールトゥアクションを推測します：

• 新機能 -> 「今すぐ試す」「新機能を見る」
• 改善 -> 「チェックする」「違いを見る」
• オープンソース -> 「今すぐ更新」「リリースを見る」

「CTAは [推測したCTA] を提案します。それで良いですか、それとも別のものにしますか？」

フェーズ3: 作成

件名

異なるアプローチで 3～5件の件名オプション を生成します：

• メリット重視（「レポートのPDFエクスポートが可能に」）
• 好奇心を刺激（「検索機能を再構築しました」）
• 特定の機能名（「ダークモードを導入」）
• 質問形式（「まだエクスポートの完了を待っていますか？」）
• 緊急性・タイムリー（「今週の新機能：リクエストのあった3つの機能」）

1つを推奨し、なぜそれが最も効果的か説明します。また、他のオプションのトレードオフも説明します。

ルール：

• 30～50文字が最適（モバイルでの切り捨てを回避）
• 具体的であること、一般的ではない（「新機能：PDFエクスポート」が「製品アップデート - 2026年3月」より優れる）
• スパムトリガーワード（無料、今すぐ購入、今すぐ行動）は使用しない

プレビューテキスト

各件名オプションに対してプレビューテキストを生成します。プレビューテキストは、受信トレイプレビューに表示される2行目のテキストです。

ルール：

• 40～130文字
• 件名を拡張し、繰り返さない
• 主なメリットや成果を含める

メール本文

単一機能メール構成：

1. 問題提起 - この機能が解決する課題を一文で説明
2. 変更内容 - ユーザーのメリットを示す言葉で更新内容を2～3文で説明（「レポートの読み込みが高速化」であり「SQLクエリ実行計画を最適化」ではない）
3. ビジュアルプレースホルダー - <!-- TODO: 機能の動作を示すスクリーンショットまたはGIFを追加 --> とキャプチャ内容の説明
4. CTAボタン - 単一の明確なアクション

ダイジェストメール構成：

1. リード更新 - 最も重要な更新に単一機能メールの完全な処理（問題、変更内容、ビジュアル、CTA）を適用
2. セカンダリ更新 - 1行の説明とリンク付きの簡潔な箇条書き
3. クイック修正/改善 - 小さな変更のグループ化されたリスト
4. クロージングCTA - 単一のアクションまたは「すべての更新を見る」

作成ルール

• 何を作ったかではなく、ユーザーのメリットを先頭に
• 会話調で、企業風ではない
• 短い段落（最大2～3文）
• 1段落に1つのアイデア
• 生成コンテンツにダッシュは絶対に使用しない。--- 文字は使用不可。代わりにカンマ、コロン、ピリオド、括弧を使用。
• 専門用語は使わない。「レポートの読み込みが高速化」が「SQLクエリ実行計画を最適化」より優れる
• 重要なフレーズは太字にしてスキャンしやすく
• スキャンしやすく保つ。短い方が良い。メールの読了に60秒以上かかる場合は長すぎる。

セグメントバリエーション

プライマリメール生成後、次のように尋ねます：

「異なる対象セグメント向けのバリエーションを生成しますか？（例：開発者向けのより技術的なバージョン、非技術ユーザー向けのよりシンプルなバージョン）」

「はい」の場合、セグメントごとにトーン、深さ、機能の強調を調整して、要求されたバリエーションを生成します。

フェーズ4: レビュー

完全なメールを提示します：

「ニュースレターはこちらです：」

件名オプション：（各オプションに推奨とプレビューテキスト）

1. 件名：「...」/ プレビュー：「...」
2. 件名：「...」/ プレビュー：「...」
3. 件名：「...」/ プレビュー：「...」

本文： [メール全文]

「件名を選び、変更が必要かどうか教えてください。」

ユーザーが件名を選択し、承認するか修正をリクエストするのを待ちます。承認された場合のみ出力に進みます。

フェーズ5: 出力

常に最終承認済みメールをターミナルに表示します。

次に尋ねます：「これを emails/<slug>.md に保存しますか？それとも別のパスにしますか？」

ディレクトリが存在しない場合は作成します。ファイルが既に存在する場合は、上書きするか、バージョン付きコピーを作成するか尋ねます。

エラーハンドリング

• gh が利用不可 -> ユーザーに通知、代替入力を提供
• 無効なPR/ref -> ユーザーに確認を依頼
• 製品コンテキストがない -> ユーザーに製品の説明を依頼
• 既存のメールディレクトリがない -> デフォルトで emails/ を使用、作成

このスキルが行わないこと

• メールの送信やスケジュール設定
• 購読者リストやセグメンテーションロジックの管理
• メールテンプレートやデザインシステムの作成
• ブログ記事やソーシャルコピーの生成（/blog-post または /social-copy を使用）