--- name: Blog Draft slug: blog-draft-2 category: Writing description: Blog Draft guides research, brainstorming, outlining, and iterative drafting of blog posts. Use it to turn ideas and resources into structured, cited article drafts with version tracking. github: "https://github.com/luongnv89/claude-howto/tree/main/ja/03-skills/blog-draft" language: Python stars: 41000 forks: 5015 install: "npx degit https://github.com/luongnv89/claude-howto/tree/main/ja/03-skills/blog-draft ~/.claude/skills/blog-draft" installs_to: ~/.claude/skills/blog-draft source_path: ja/03-skills/blog-draft/SKILL.md collection_size: 25 category_size: 1012 collection_url: "https://dirskills.com/collections/luongnv89/claude-howto" added: 2026-08-13T07:37:01.077Z last_synced: 2026-08-13T07:37:01.077Z canonical_url: "https://dirskills.com/skills/blog-draft-2" --- # Blog Draft Blog Draft guides research, brainstorming, outlining, and iterative drafting of blog posts. Use it to turn ideas and resources into structured, cited article drafts with version tracking. **Install:** ```bash npx degit https://github.com/luongnv89/claude-howto/tree/main/ja/03-skills/blog-draft ~/.claude/skills/blog-draft ``` ## README --- name: blog-draft description: アイデアとリソースからブログ記事の下書きを作成する。ブログ記事の執筆、リサーチからのコンテンツ作成、記事の下書き作成時に使用する。リサーチ、ブレインストーミング、アウトライン作成、バージョン管理付きの反復的な下書き作成を案内する。 --- ## ユーザー入力 ```text $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. 各要約には以下を含める: ```markdown # 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. 以下を含む構造化されたアウトラインを作成: ```markdown # 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. フォーマット: ```markdown # [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 が提供された場合は最新情報のためウェブ検索を使用する - リソースが不十分な場合はユーザーに追加を求めるか、追加リサーチを提案する - 対象読者（技術系、一般、ビジネスなど）に応じてトーンを適応させる