luongnv89/ja/03-skills/blog-draft

<!-- i18n-source: 03-skills/blog-draft/SKILL.md --> <!-- i18n-source-sha: f396788 --> <!-- i18n-date: 2026-04-27 -->

---

name: blog-draft description: アイデアとリソースからブログ記事の下書きを作成する。ブログ記事の執筆、リサーチからのコンテンツ作成、記事の下書き作成時に使用する。リサーチ、ブレインストーミング、アウトライン作成、バージョン管理付きの反復的な下書き作成を案内する。

ユーザー入力

$ARGUMENTS

進める前にユーザー入力を必ず考慮する。ユーザーは以下を提供すべきである。

• Idea/Topic: ブログ記事の主要なコンセプトやテーマ
• Resources: URL、ファイル、リサーチ用の参考情報（任意だが推奨）
• Target audience: ブログ記事の対象読者（任意）
• Tone/Style: フォーマル、カジュアル、技術的、など（任意）

重要: ユーザーが既存のブログ記事の更新を要求している場合、ステップ 0-8 をスキップして直接ステップ 9から開始する。まず既存の下書きファイルを読み、その後で反復プロセスを進める。

実行フロー

以下のステップを順次実行する。ステップをスキップしたり、指示された箇所でユーザー承認なしに進めたりしてはならない。

Step 0: プロジェクトフォルダの作成

1. 次の形式でフォルダ名を生成する: YYYY-MM-DD-short-topic-name

   • 今日の日付を使用
   • トピックから短く URL フレンドリーなスラッグを作成（小文字、ハイフン、最大 5 単語）

2. フォルダ構造を作成:

   blog-posts/
   └── YYYY-MM-DD-short-topic-name/
       └── resources/
   

3. 進める前にフォルダ作成をユーザーに確認する。

Step 1: リサーチとリソース収集

1. ブログ記事ディレクトリ内に resources/ サブフォルダを作成

2. 提供された各リソースに対して:

   • URLs: 取得して主要情報を resources/ にマークダウンファイルとして保存
   • Files: 読み込んで resources/ に要約
   • Topics: ウェブ検索を使用して最新情報を収集

3. 各リソースについて、resources/ に要約ファイルを作成:

   • resources/source-1-[short-name].md
   • resources/source-2-[short-name].md
   • など

4. 各要約には以下を含める:

   # Source: [Title/URL]
   
   ## Key Points
   - Point 1
   - Point 2
   
   ## Relevant Quotes/Data
   - Quote or statistic 1
   - Quote or statistic 2
   
   ## How This Relates to Topic
   関連性の簡潔な説明
   

5. リサーチの要約をユーザーに提示する。

Step 2: ブレインストーミングと明確化

1. アイデアとリサーチしたリソースに基づき、以下を提示:

   • リサーチから特定された主要テーマ
   • ブログ記事の取りうる切り口
   • カバーすべき重要ポイント
   • 明確化が必要な情報のギャップ

2. 明確化のための質問:

   • 読者に持って帰ってほしい主要なテイクアウェイは何か？
   • リサーチの中で特に強調したい点はあるか？
   • 目標の長さは？（short: 500-800 words、medium: 1000-1500、long: 2000+）
   • 除外したい点はあるか？

3. 進める前にユーザー応答を待つ。

Step 3: アウトライン提案

1. 以下を含む構造化されたアウトラインを作成:

   # Blog Post Outline: [Title]
   
   ## Meta Information
   - **Target Audience**: [who]
   - **Tone**: [style]
   - **Target Length**: [word count]
   - **Main Takeaway**: [key message]
   
   ## Proposed Structure
   
   ### Hook/Introduction
   - Opening hook idea
   - Context setting
   - Thesis statement
   
   ### Section 1: [Title]
   - Key point A
   - Key point B
   - Supporting evidence from [source]
   
   ### Section 2: [Title]
   - Key point A
   - Key point B
   
   [全セクションについて続ける...]
   
   ### Conclusion
   - Summary of key points
   - Call to action or final thought
   
   ## Sources to Cite
   - Source 1
   - Source 2
   

2. アウトラインをユーザーに提示し、承認または修正を求める。

Step 4: 承認されたアウトラインの保存

1. ユーザーがアウトラインを承認したら、ブログ記事フォルダ内の OUTLINE.md に保存する。

2. アウトラインが保存されたことを確認する。

Step 5: アウトラインのコミット（git リポジトリの場合）

1. カレントディレクトリが git リポジトリかどうか確認する。

2. はいの場合:

   • 新しいファイル（ブログ記事フォルダ、resources、OUTLINE.md）をステージング
   • 次のメッセージでコミットを作成: docs: Add outline for blog post - [topic-name]
   • リモートへプッシュ

3. git リポジトリでない場合は、このステップをスキップしユーザーに伝える。

Step 6: 下書き作成

1. 承認されたアウトラインに基づき、ブログ記事の下書き全文を作成する。

2. OUTLINE.md の構造に厳密に従う。

3. 含めるもの:

   • フック付きの魅力的な導入
   • 明確なセクション見出し
   • リサーチからの裏付けとなる証拠と例
   • セクション間の滑らかな遷移
   • テイクアウェイのある力強い結論
   • Citations: すべての比較、統計、データポイント、事実主張は元のソースを必ず引用すること

4. 下書きをブログ記事フォルダ内に draft-v0.1.md として保存する。

5. フォーマット:

   # [Blog Post Title]
   
   *[Optional: subtitle or tagline]*
   
   [インライン引用付きの本文...]
   
   ---
   
   ## References
   - [1] Source 1 Title - URL or Citation
   - [2] Source 2 Title - URL or Citation
   - [3] Source 3 Title - URL or Citation
   

6. 引用要件:

   • すべてのデータポイント、統計、比較にはインライン引用を必ず付ける
   • [1]、[2] などの番号引用、または [Source Name] のような名前付き引用を使用
   • 引用を末尾の References セクションへリンクする
   • 例: "Studies show that 65% of developers prefer TypeScript [1]"
   • 例: "React outperforms Vue in rendering speed by 20% [React Benchmarks 2024]"

Step 7: 下書きのコミット（git リポジトリの場合）

1. git リポジトリかどうか確認する。

2. はいの場合:

   • 下書きファイルをステージング
   • 次のメッセージでコミットを作成: docs: Add draft v0.1 for blog post - [topic-name]
   • リモートへプッシュ

3. git リポジトリでない場合は、スキップしてユーザーに伝える。

Step 8: レビュー用に下書きを提示

1. 下書きの内容をユーザーに提示する。

2. フィードバックを求める:

   • 全体の印象は？
   • 拡張または削減が必要なセクションは？
   • トーン調整は必要か？
   • 不足している情報は？
   • 具体的な編集や書き直しは？

3. ユーザー応答を待つ。

Step 9: 反復または最終化

ユーザーが変更を要求した場合:

1. すべての要望を記録する
2. 以下の調整を加えてステップ 6 へ戻る:
   • バージョン番号を増加（v0.2、v0.3 など）
   • すべてのフィードバックを反映
   • draft-v[X.Y].md として保存
   • ステップ 7-8 を繰り返す

ユーザーが承認した場合:

1. 最終下書きのバージョンを確認
2. ユーザーが要求すれば任意で final.md にリネーム
3. ブログ記事作成プロセスを要約:
   • 作成したバージョンの総数
   • バージョン間の主要な変更
   • 最終ワード数
   • 作成したファイル

バージョン追跡

すべての下書きは段階的なバージョン番号付きで保持する:

• draft-v0.1.md - 初回下書き
• draft-v0.2.md - 1 回目のフィードバック反映後
• draft-v0.3.md - 2 回目のフィードバック反映後
• など

これによりブログ記事の進化を追跡し、必要に応じて差し戻すことができる。

出力ファイル構造

blog-posts/
└── YYYY-MM-DD-topic-name/
    ├── resources/
    │   ├── source-1-name.md
    │   ├── source-2-name.md
    │   └── ...
    ├── OUTLINE.md
    ├── draft-v0.1.md
    ├── draft-v0.2.md (反復した場合)
    └── draft-v0.3.md (さらに反復した場合)

品質のためのヒント

• Hook: 質問、意外な事実、共感できるシナリオで始める
• Flow: 各段落は次の段落と接続させる
• Evidence: リサーチデータで主張を裏付ける
• Citations: 以下については必ずソースを引用する:
  • すべての統計とデータポイント（例: "According to [Source], 75% of..."）
  • 製品、サービス、アプローチ間の比較（例: "X performs 2x faster than Y [Source]"）
  • 市場トレンド、リサーチ結果、ベンチマークについての事実主張
  • 形式: [Source Name] または [Author, Year] のインライン引用を使用
• Voice: 全体を通じて一貫したトーンを保つ
• Length: 目標ワード数を尊重
• Readability: 短い段落、適切な箇所での箇条書きを使用
• CTA: 明確な CTA または考えさせる問いで終える

注意事項

• 指定されたチェックポイントでは必ずユーザー承認を待つ
• 履歴のためすべての下書きバージョンを保持する
• URL が提供された場合は最新情報のためウェブ検索を使用する
• リソースが不十分な場合はユーザーに追加を求めるか、追加リサーチを提案する
• 対象読者（技術系、一般、ビジネスなど）に応じてトーンを適応させる