Claude How-To

日本語

English
Tiếng Việt
中文
Українська

日本語

English
Tiếng Việt
中文
Українська

Appearance

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 が提供された場合は最新情報のためウェブ検索を使用する
  • リソースが不十分な場合はユーザーに追加を求めるか、追加リサーチを提案する
  • 対象読者（技術系、一般、ビジネスなど）に応じてトーンを適応させる