newsletter-generation
ユーザーがニュースレター、メールダイジェスト、週次まとめ、業界ブリーフィング、またはキュレーションコンテンツの作成・執筆を求めた際に使用するスキルです。トピックに基づいたリサーチや複数ソースからのコンテンツ収集、メール・Web配信向けのプロフェッショナルなフォーマット整形をサポートします。「〇〇についてニュースレターを作成して」「週次ダイジェストを書いて」「テック系ニュースをまとめて」といったリクエストで起動します。
description の原文を見る
Use this skill when the user requests to generate, create, write, or draft a newsletter, email digest, weekly roundup, industry briefing, or curated content summary. Supports topic-based research, content curation from multiple sources, and professional formatting for email or web distribution. Trigger on requests like "create a newsletter about X", "write a weekly digest", "generate a tech roundup", or "curate news about Y".
SKILL.md 本文
ニュースレター生成スキル
概要
このスキルは、複数のソースから厳選されたコンテンツとオリジナルの分析・コメンタリーを組み合わせた、プロフェッショナルで綿密にリサーチされたニュースレターを生成します。Morning Brew、The Hustle、TLDR、Benedict Evans などのパブリケーションの最新のニュースレターベストプラクティスに従い、情報提供的で魅力的、かつ実用的なコンテンツを作成します。
出力は Markdown 形式の完全で公開可能なニュースレターで、メール配信プラットフォーム、Web パブリッシング、または HTML への変換に適しています。
コア機能
- 指定されたトピックに関して複数の Web ソースからコンテンツをリサーチし厳選
- トピック焦点型または複数トピックのニュースレターを一貫した声で生成
- 魅力的なヘッドライン、サマリー、オリジナルコメンタリーを作成
- 最適な読みやすさとスキャン性のためにコンテンツを構成
- 複数のニュースレター形式に対応(日次ダイジェスト、週間ラウンドアップ、深掘り、業界ブリーフィング)
- 関連リンク、ソース、帰属表示を含める
- トーンとスタイルをターゲットオーディエンスに適応(技術者向け、経営層向け、一般向け)
- 一貫したブランディングと構造を持つ繰り返しニュースレターシリーズを生成
このスキルを使用する時期
常にこのスキルを読み込む場合:
- ユーザーがニュースレター、メールダイジェスト、またはコンテンツラウンドアップの生成を求める
- ユーザーがトピックのニュースや進展の厳選されたサマリーをリクエストする
- ユーザーが繰り返しニュースレター形式を作成したい
- ユーザーが分野の最近の進展をブリーフィングにまとめるよう求める
- ユーザーが複数の厳選されたアイテムを含むフォーマット済みのメール対応コンテンツを必要とする
- ユーザーが「週間ラウンドアップ」「月刊ダイジェスト」または「朝のブリーフィング」をリクエストする
ニュースレターワークフロー
フェーズ 1: 計画
ステップ 1.1: ニュースレター要件を理解する
主要なパラメータを特定します:
| パラメータ | 説明 | デフォルト |
|---|---|---|
| トピック | カバーすべき主要なサブジェクト領域 | 必須 |
| 形式 | 日次ダイジェスト、週間ラウンドアップ、深掘り、業界ブリーフィング | 週間ラウンドアップ |
| ターゲットオーディエンス | 技術者向け、経営層向け、一般向け、またはニッチコミュニティ向け | 一般向け |
| トーン | プロフェッショナル、カジュアル、ウィット、または分析的 | カジュアルプロフェッショナル |
| 長さ | 短編(5 分読)、中編(10 分)、長編(15 分以上) | 中編 |
| セクション | コンテンツセクションの数と種類 | 4-6 セクション |
| 頻度コンテキスト | 1 回限りまたは繰り返しシリーズの一部 | 1 回限り |
ステップ 1.2: ニュースレター構造を定義する
形式に基づいて、適切な構造を選択します:
日次ダイジェスト構造:
1. トップストーリー (1 アイテム、詳細)
2. クイックヒット (3-5 アイテム、簡潔)
3. 本日の統計/引用
4. ウォッチリスト
週間ラウンドアップ構造:
1. エディターズノート/イントロ
2. トップストーリー (2-3 アイテム、詳細)
3. トレンド & 分析 (1-2 アイテム、オリジナルコメンタリー)
4. クイックバイツ (4-6 アイテム、簡潔なサマリー)
5. ツール & リソース (2-3 アイテム)
6. もう 1 つ / クロージング
深掘り構造:
1. イントロダクション & コンテキスト
2. 背景 / なぜそれが重要か
3. 主要な進展 (詳細な分析)
4. エキスパートの視点
5. 次は何か / 含意
6. さらに詳しく読む
業界ブリーフィング構造:
1. エグゼクティブサマリー
2. 市場の進展
3. 企業ニュース & 動き
4. 製品 & テクノロジーアップデート
5. 規制 & ポリシー変更
6. データ & メトリクス
7. 見通し
フェーズ 2: リサーチ & キュレーション
ステップ 2.1: マルチソースリサーチ
Web 検索を使用して徹底的なリサーチを実施します。ニュースレターの品質は、リサーチの品質と最新性に直結します。
検索戦略:
# 最新のニュースと進展
"[topic] news [現在月] [現在年]"
"[topic] latest developments"
"[topic] announcement this week"
# トレンドと分析
"[topic] trends [現在年]"
"[topic] analysis expert opinion"
"[topic] industry report"
# データと統計
"[topic] statistics [現在年]"
"[topic] market data latest"
"[topic] growth metrics"
# ツールとリソース
"[topic] new tools [現在年]"
"[topic] open source release"
"best [topic] resources [現在年]"
重要: 常に
<current_date>を確認して、検索クエリが正しい時間的コンテキストを使用していることを確認します。ハードコードされた年を使用しないでください。
ステップ 2.2: ソース評価と選択
各ソースを評価し、最良のコンテンツを厳選します:
| 基準 | 優先度 |
|---|---|
| 最新性 | 過去 7-30 日間のコンテンツを優先 |
| 権威性 | 一次ソース、公式アナウンスメント、確立されたパブリケーションを優先 |
| ユニークさ | 新しい視点を提供する、または過小報道されているストーリーを選択 |
| 関連性 | すべてのアイテムがニュースレターの指定トピックに明確に関連 |
| 実用性 | 読者が行動を起こせるコンテンツを優先(ツール、インサイト、戦略) |
| 多様性 | ニュース、分析、データ、実用的なリソースのミックス |
ステップ 2.3: ディープコンテンツ抽出
主要なストーリーについては、web_fetch を使用して全記事を読み、以下を抽出します:
- コアファクト — 何が起こったか、誰が関与しているか、いつか
- コンテキスト — なぜこれが重要か、背景情報
- データポイント — 具体的な数値、メトリクス、または統計
- 引用 — 関連するエキスパートの引用または公式声明
- 含意 — これが読者にとって何を意味するか
フェーズ 3: 執筆
ステップ 3.1: ニュースレターヘッダー
すべてのニュースレターは一貫したヘッダーで始まります:
# [ニュースレター名]
*[タグライン or 説明] — [日付]*
---
[オプション: 中身についての 1 文プレビュー]
ステップ 3.2: セクション執筆ガイドライン
トップストーリー / フィーチャアイテム:
- ヘッドライン: 魅力的で明確、利点指向(クリックベイトではない)
- フック: 読者に注目させる冒頭文(1-2 文)
- 本文: 主要なファクトとコンテキスト(2-4 パラグラフ)
- なぜそれが重要か: 読者の世界との関連性を結びつける(1 パラグラフ)
- ソースリンク: 常にオリジナルソースに帰属し、リンクを付ける
クイックバイツ / 簡潔なアイテム:
- 形式: 太字ヘッドライン + 2-3 文のサマリー + ソースリンク
- 焦点: アイテムごとに 1 つの重要な要点
- 効率性: 読者はクリックスルーなしに重要なインサイトを得られるべき
分析 / コメンタリーセクション:
- 声: トレンドや進展に関するニュースレターのユニークな視点
- 構造: 観察 → コンテキスト → 含意 → (オプション) 実用的な要点
- 証拠: すべての主張がデータまたはソース情報によって裏付けられている
ステップ 3.3: 執筆基準
| 原則 | 実装 |
|---|---|
| スキャン可能 | ヘッダー、太字テキスト、箇条書き、短いパラグラフを使用 |
| 魅力的 | 時系列ではなく、最も興味深い角度からスタート |
| 簡潔 | すべての文が価値を提供する — フィラーを容赦なくカット |
| 正確 | すべてのファクトがソース化され、すべての数値が検証されている |
| 帰属的 | 常にオリジナルソースにクレジットを与えてインラインリンクを付ける |
| 人間的 | プレスリリースではなく、知識豊かな友人のように執筆 |
オーディエンス別のトーン調整:
| オーディエンス | トーン | 例 |
|---|---|---|
| 技術者向け | 正確、用語の説明なし、専門知識があるものと想定 | "新しい API は gRPC ストリーミングをフローコントロールウィンドウを介したバックプレッシャー処理でサポートします。" |
| 経営層向け | インパクト重視、ボトムライン、戦略的 | "この買収は Company X に企業セグメントで 40% の市場シェアをもたらし、Incumbent Y の価格設定力に直接脅威をもたらします。" |
| 一般向け | アクセス可能、アナロジー、概念を説明 | "それはデータのユニバーサル翻訳機のようなものと考えてください — あらゆるアプリが新しい言語を学ぶことなく任意のデータベースと通信できるようにします。" |
フェーズ 4: 組立と仕上げ
ステップ 4.1: ニュースレターを組立てる
選択した構造テンプレートに従って、すべてのセクションを最終ドキュメントに統合します。
ステップ 4.2: フッター
すべてのニュースレターは以下で終わります:
---
*[ニュースレター名] は [それが何かの説明] です。*
*[購読/共有/フィードバック方法]*
*Sources: All links are provided inline. This newsletter curates and summarizes
publicly available information with original commentary.*
ステップ 4.3: クオリティチェックリスト
ファイナライズする前に、以下を検証します:
- すべてのファクトクレームがソースリンク付き — ソース化されていない主張なし
- すべてのリンクが機能している — 検索結果からの確認済み URL
- 日付参照が実際の現在日付を使用 — ハードコードまたは想定日なし
- コンテンツが最新 — すべての主要アイテムが期待されたタイムフレーム内
- 重複ストーリーがない — 各アイテムは 1 回のみ表示
- 一貫したフォーマット — ヘッダー、箇条書き、リンクが全体で同じスタイル
- バランスの取れたカバレッジ — 単一ソースまたは観点に支配されていない
- 適切な長さ — 指定された長さターゲットに適合
- 魅力的なオープニング — 最初の 2 文で読者が続きを読みたくなる
- 明確なクロージング — ニュースレターが記憶に残る、または実用的な注記で終わる
- 校正済み — タイプミス、破損したフォーマット、不完全な文がない
ニュースレター出力テンプレート
# [ニュースレター名]
*[タグライン] — [完全な日付、例: 2026 年 4 月 4 日]*
---
[プレビュー文: "今週: [トピック 1]、[トピック 2]、[トピック 3]。"]
## 🔥 トップストーリー
### [ヘッドライン 1]
[フック — これが重要な理由を 1-2 文で。]
[本文 — 主要なファクト、コンテキスト、含意をカバーする 2-4 パラグラフ。]
**なぜそれが重要か:** [読者の興味や業界インパクトに関連付ける 1 パラグラフ。]
📎 [ソース: パブリケーション名](URL)
### [ヘッドライン 2]
[上記と同じ構造]
## 📊 トレンド & 分析
### [トレンドタイトル]
[リサーチからのデータによって裏付けられた、新興トレンドに関するオリジナルコメンタリー。]
[主要なデータポイントを明確に提示 — インラインスタット短い比較を検討。]
**ボトムライン:** [1 文の要点。]
## ⚡ クイックバイツ
- **[ヘッドライン]** — [2-3 文のサマリーと主要な要点。] [ソース](URL)
- **[ヘッドライン]** — [2-3 文のサマリー。] [ソース](URL)
- **[ヘッドライン]** — [2-3 文のサマリー。] [ソース](URL)
- **[ヘッドライン]** — [2-3 文のサマリー。] [ソース](URL)
## 🛠️ ツール & リソース
- **[ツール/リソース名]** — [それが何をするか、なぜ有用か。] [リンク](URL)
- **[ツール/リソース名]** — [説明。] [リンク](URL)
## 💬 もう 1 つ
[クロージングの考え、洞察に満ちた引用、または前向きな声明。]
---
*[ニュースレター名] は最も重要な [トピック] ニュースと分析を厳選します。*
*これが有用でしたか? 同僚と共有してください。*
*すべてのソースはインラインでリンクされています。ビューとコメンタリーはオリジナルです。*
適応例
テクノロジーニュースレター
- 絵文字使用: ✅ 中程度(セクションヘッダー)
- セクション: トップストーリー、ディープダイブ、クイックバイツ、オープンソーススポットライト、デベロッパーツール
- トーン: 技術的カジュアル
ビジネス/ファイナンスニュースレター
- 絵文字使用: ❌ 最小限からなし
- セクション: マーケット概要、ディール流、企業ニュース、データコーナー、見通し
- トーン: プロフェッショナル分析的
業界固有ニュースレター
- 絵文字使用: 中程度
- セクション: 規制アップデート、市場データ、イノベーションウォッチ、人事異動、イベント
- トーン: エキスパート権威的
クリエイティブ/マーケティングニュースレター
- 絵文字使用: ✅ 自由
- セクション: キャンペーンスポットライト、トレンドウォッチ、今週バイラル、好きなツール、インスピレーション
- トーン: 熱心プロフェッショナル
出力処理
生成後:
- ニュースレターを
/mnt/user-data/outputs/newsletter-{topic}-{date}.mdに保存 present_filesツールを使用してニュースレターをユーザーに表示- セクション、トーン、長さ、または焦点エリアを調整するオプションを提供
- ユーザーが HTML 出力を希望する場合、Markdown は標準ツールを使用して変換できることを注記
注記
- このスキルは包括的なトピックカバレッジのための
deep-researchスキルとの組み合わせで最も効果的です — 深い分析が必要なニュースレターの場合は両方を読み込みます - 常に検索の時間的コンテキストとニュースレーター内の日付参照に
<current_date>を使用 - 繰り返しニュースレターの場合、読者が期待を発展させるよう一貫した構造の維持を提案
- キュレーション時は、量より質 — 15 の平凡なアイテムより 5 つの優れたアイテム
- すべてのコンテンツを適切に帰属 — ニュースレターは透明なソースを通じて信頼を構築
- 読者がアクセスできないペイウォール内のコンテンツのサマリーを避ける
- ユーザーが含める特定の URL または記事を提供する場合、キュレートされた検出と一緒に組み込む
- ニュースレターは読者がすべてのリンクをクリックスルーしなくてもサマリーから十分な価値を得られるようにする十分な価値を提供すべき
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- bytedance
- リポジトリ
- bytedance/deer-flow
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/bytedance/deer-flow / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。