ブログ記事作成

ブログ記事作成 は何をしますか？

コード変更、マーケティングブリーフ、機能説明から高品質なブログ記事を作成します。SEO、構造、トーンの調整、ビジュアルコンテンツも処理します。

ライティングルール（譲れないもの）：em-dash（— や –）は絶対に使わないこと。代わりにハイフン - を使用してください。 生成するすべてのコピーに適用されます。

インプットの解決

引数が指定された場合、次の順序で解決します。

1. 既存のマーケティングブリーフファイルへのパス（「エグゼクティブサマリー」または「キーメッセージ」を含む.mdファイル）→ マーケティングブリーフ
2. GitHub URLまたは#\d+パターンに一致 → PR
3. ...または..を含む → git ref範囲
4. 既存のファイル/ディレクトリに解決 → コードベースの機能
5. それ以外 → 自由記述テキスト

引数が提供されなかった場合は、次のように尋ねてください。「何について書きましょうか？マーケティングブリーフのパス、PRのURL/番号、git ref範囲（例：v1.0...v2.0）、ファイル/ディレクトリのパス、またはトピックを説明してください。」

複数の解釈が一致する場合は、ユーザーに確認してください。

プロセスフロー

digraph blog_post {
    rankdir=TB;
    "Resolve input" [shape=box];
    "Phase 1: Discovery" [shape=box];
    "Phase 2: Research" [shape=box];
    "Phase 3: Configure" [shape=box];
    "Phase 4: Outline" [shape=box];
    "Outline approved?" [shape=diamond];
    "Phase 5: Write" [shape=box];
    "Phase 6: Output" [shape=box];

    "Resolve input" -> "Phase 1: Discovery";
    "Phase 1: Discovery" -> "Phase 2: Research";
    "Phase 2: Research" -> "Phase 3: Configure";
    "Phase 3: Configure" -> "Phase 4: Outline";
    "Phase 4: Outline" -> "Outline approved?";
    "Outline approved?" -> "Phase 4: Outline" [label="no, revise"];
    "Outline approved?" -> "Phase 5: Write" [label="yes"];
    "Phase 5: Write" -> "Phase 6: Output";
}

フェーズをスキップしないでください。 自然なペースで質問してください。ユーザーを圧倒しないようにしつつ、不自然に遅くもしないでください。ユーザーが複数の質問に一度に答えた場合は、その回答をまとめて受け入れ、先に進んでください。

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

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

フェーズ 1: 発見

ステップ 1 - インプットの分析

入力タイプ	何を読むか
マーケティングブリーフ	ブリーフを読み、問題提起、価値提案、対象読者、キーメッセージ、競合ポジショニングを抽出します。ブリーフにプロダクトコンテキストが欠けている場合は、ステップ2も実行してからステップ3に進みます。
PR	DIFF、PR説明、レビューコメント、コミットメッセージ（gh pr view、gh pr diff）。大規模なPR（20ファイル以上）の場合は、ユーザー向けの変更に焦点を当てます。
Git ref	ref間のgit diffとgit log。広い範囲の場合は、コミットメッセージとユーザー向けの変更を優先します。
コードベースの機能	指定されたファイル/ディレクトリを読みます。
自由記述テキスト	ユーザーの説明を解析します。具体性に欠ける場合（機能名、価値提案、コンテキストがない場合）、ユーザーに詳細を提供するか、特定のファイル/PRを指定するよう依頼します。それができない場合にのみ、自由回答式の質問にフォールバックします。

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

エラーハンドリング:

• gh がインストール/認証されていない → ユーザーに通知し、gh auth login を提案し、代替入力を提供します
• PR/refが無効 → ユーザーに伝え、確認を求めます
• ファイルが見つからない → 正しいパスを尋ねます

ステップ 2 - より広いプロダクトコンテキストを読む

次のファイルが存在すれば読みます：README、docs/、package.json（または同等のもの）、マーケティング資料。

目的：プロダクトが何か、誰のためのものか、何をするかを理解する。

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

ステップ 3 - 理解内容の提示

「私の理解は次の通りです。」

• 機能A - 簡単な説明
• 機能B - 簡単な説明

「これらのうち、ブログ記事で取り上げるべきものはどれですか？追加、削除、修正はありますか？」

スコープを完全に理解するために必要なだけ質問してください。ユーザーが確認するまで先に進まないでください。

ステップ 4 - 機密項目のフラグ付け

以下をスキャンします：破壊的変更、非推奨、セキュリティ修正、移行要件。

見つかった場合は、それぞれにフラグを立て、先に進む前にそれらをどのように扱うか尋ねてください。

フェーズ 2: 競合ブログ調査

投稿を設定する前に、この分野の類似ブログ投稿を検索します。

1. WebSearchを使用して、同じトピック、競合製品、または類似の機能発表をカバーする既存のブログ投稿を3～5件見つけます
2. それらの投稿で何が機能し、何が機能していないかを分析します - 構造、見出し、フック、SEOキーワード、深さ
3. コンテンツのギャップを特定します - 競合がカバーしておらず、この投稿でカバーできるもの
4. これらの発見をSEO戦略、見出し生成、コンテンツ構造に活用します

WebSearchが利用できない場合は、このフェーズをスキップし、自身の知識に依存します。

ユーザーに簡単なサマリーを提示します。

「いくつか類似の投稿を見つけました。注目すべき点は次の通りです。」

• [機能している点に関する主要な発見]
• [コンテンツのギャップ/機会]
• [SEOキーワードの機会]

「これらの洞察を投稿の形成に活用します。」

フェーズ 3: 設定

次の質問をします。

Q1 - 読者: 「このブログ記事の読者は誰ですか？」（開発者、エンドユーザー、技術的意思決定者、一般読者、その他）

Q2 - トーン: リポジトリ内の既存のブログ投稿、README、ドキュメントを読んで、プロダクトのトーンを検出します。その後、確認します。

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

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

Q3 - 投稿タイプ: インプットと読者に基づいて投稿タイプを推奨し、確認します。

• 機能発表 - 「Xをリリースしました。その重要性は？」（約600～1000語）
• 詳細技術解説 - 「Xをどのように構築したか、決定事項とアーキテクチャ」（約1500～2500語）
• 問題解決型ナラティブ - 「あなたには問題Xがあります。これを解決する方法はこちら」（約1000～2000語）

「[インプット/読者]を考慮すると、[理由]から[タイプ]の投稿をお勧めします。よろしいですか？」

Q4 - CTA: コンテキストから最も適切なCTAを推測します。

• オープンソース → リポジトリにスターを付ける、コントリビュートする、試してみる
• SaaS → サインアップ、無料トライアルを開始
• 機能アップデート → 新機能を試す、ドキュメントを読む
• ライブラリ/SDK → インストールする、移行ガイドを読む

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

Q5 - 関与レベル: 「執筆プロセスにどの程度関与しますか？」

• A) そのまま書いてください - すべてを処理し、最適な見出しを選び、最終投稿を保存します。後で変更をリクエストできます。
• B) まずアウトラインを見せてください - 構造を承認してから、全文を書きます
• C) 段階的に進めてください - アウトライン承認後、セクションごとに確認しながら進めます

フェーズ 4: アウトライン

構造化されたアウトラインを生成します。

## [作業タイトル]

1.  **フック/イントロダクション** - [アプローチ：質問/統計/大胆な声明/ストーリー]
   - 確立すべき主要ポイント
   - 本文への移行

2.  **セクション名** - [目的]
   - 主要ポイント
   - 推定単語数

3.  **セクション名** - [目的]
   - 主要ポイント
   - 推定単語数

[必要なだけセクションを追加]

N. **結論** - [サマリー + CTA]
   - 強調すべき主要な要点
   - CTA: [具体的なアクション]

推定総単語数：約X語

関与レベルがAの場合は、アウトラインを内部的に生成し、表示しません。BとCの場合は、提示して承認を待ちます。

フェーズ 5: 執筆

内部執筆プロセス（関与レベルに関係なく常に実行）

各セクションに対して：

1. セクションを書く
2. 自己レビュー： コンテンツが別の構造で表現できるか、読者が理解して消化するために必要なコンテキストが不足していないか、トピックに詳しくない人を混乱させるギャップがないかを分析する
3. バックフィル： 不足している部分が見つかった場合は、移行段落、コンテキストを追加するか、先に進む前に再構成する

関与レベルがCの場合は、自己レビュー後に各セクションを提示し、先に進む前に確認を得ます。AとBの場合は、このプロセスを非表示で実行します。

見出し

本文が完成したら、異なるフォーミュラを使用して3～5個の見出しオプションを生成します。

• ハウツー（「[プロダクト]が[問題]を解決する方法」）
• 数字/リスト（「[機能]が[ワークフロー]を変える3つの理由」）
• 質問（「[ペインポイント]にうんざりしていませんか？」）
• 大胆な声明（「[機能]は[成果]への最速の方法です」）
• ビフォー/アフター（「[ペイン] → [結果]：[機能]がそれを実現する方法」）

1つを推奨し、それがこの投稿の読者、SEO、コンテキストに最適な理由を説明します。また、他のオプションのトレードオフも説明します。

関与レベルBとCの場合は、オプションを提示し、先に進む前にユーザーの選択を得ます。レベルAの場合は、あなたの推奨を使用します。

SEOの制約よりも読みやすさを優先します。最初に最適な見出しを書きます。それが50～60文字のSEOタイトル制限に収まらない場合は、フロントマター用に別の短いタイトルタグを作成します。

SEOフロントマター

投稿の先頭にYAMLフロントマターとして生成します。

---
title: "[選択された見出し]"
meta_description: "[140～160文字、プライマリキーワードを含み、価値提案が魅力的]"
primary_keyword: "[メインターゲットキーワード]"
secondary_keywords: ["キーワード1", "キーワード2", "キーワード3"]
long_tail_keywords: ["より長いフレーズ1", "より長いフレーズ2"]
slug: "[URL用スラッグ]"
---

ルール：

• タイトルタグ：50～60文字、プライマリキーワードを先頭に
• メタ説明：140～160文字、人間向けに書き、独自の価値提案を含む
• キーワードはフェーズ2の競合調査に基づく
• キーワードの詰め込みは禁止 - 自然な言い回しのみ

コンテンツフォーマットルール

• 短い段落： 最大2～4文
• 小見出し： メインセクションにはH2、サブセクションにはH3を使用。小見出しはそれ自体でスキャン可能なアウトラインとして機能すること
• 重要フレーズを太字にしてF字型スキャンをサポート
• 箇条書きとリストは3つ以上の項目がある場合に使用
• 1段落に1つのアイデア
• 生成コンテンツではem-dash を絶対に使用しないこと。「—」という文字は使用しないでください。代わりにカンマ、コロン、ピリオド、または括弧を使用してください。

フック/イントロダクション

イントロは3つの要素で構成されます。

1. フック（最初の1～2文） - 驚くべき統計、大胆な主張、共感を呼ぶペインポイント、または挑発的な質問。読んでから3秒未満で好奇心や感情的な共鳴を生み出さなければなりません。
2. 権威 - これが重要な理由、または読者がこれを信頼すべき理由を簡単に確立します
3. 約束 - 読者がこの投稿から何を得られるかを明確に述べます

イントロは3～5の短い段落に保ちます。テキストの壁を作らないでください。

結論

1. 主要な要点を再度述べます（新しいアイデアは導入しない）
2. アクション動詞を使用した単一の明確なCTA（「今すぐ試す」、「リポジトリにスターを付ける」、「無料トライアルを開始」）
3. オプションで、ディスカッションを促すための将来を見据えた声明や質問で終わります

ビジュアルコンテンツ

可能な限り直接生成します。

• アーキテクチャ図 → mermaidコードブロックまたはインラインSVG
• データフロー図 → mermaidコードブロック
• 比較表 → マークダウンテーブル
• コード例 → シンタックスハイライト付きコードブロック

外部作成が必要な画像の場合：

<!-- TODO: 画像をここに追加 -->
<!-- 提案: [画像に表示すべき内容の説明] -->
<!-- LLMプロンプト: "[画像生成モデル用のすぐに使えるプロンプト、例：'ダッシュボードにダークモードトグルを表示するクリーンでミニマルなイラスト、フラットデザインスタイル、開発者ツールの美学、16:9比']" -->
![代替テキスト説明](placeholder.png)

理解を助けるために必要な場所でビジュアルを使用します - 複雑な概念を説明した後、オプションを比較する場合、またはUI変更を示す場合。

コード例

開発者向けの読者には、機能の動作を示すコード例を少なくとも1つ含めます。最小限で実行可能なスニペット（5～15行）を推奨します。改善を示す場合は、ビフォー/アフターを表示します。

フェーズ 5b: 全文レビュー

すべてのセクションが作成され、見出しが選択されたら、完全な投稿（フロントマター + 本文）を組み立てます。

• レベルA: レビューをスキップ。直接出力に進みます。最終投稿を提示して保存します。ユーザーは後で変更をリクエストできます。
• レベルB: 保存する前に、完全なドラフトをユーザーに提示してレビューを受けます。「こちらが完成した投稿です。保存する前に変更はありますか？」
• レベルC: ユーザーは各セクションを個別に見ていますが、最終レビューのために組み立てられたドラフトを提示します。「こちらが完成した投稿です。保存する前に変更はありますか？」

BとCの場合、ユーザーが改訂をリクエストした場合は、それを行い再度提示します。ユーザーが承認した場合のみ出力に進みます。

フェーズ 6: 出力

最初に既存のブログディレクトリを検出します。 以下を確認します。

• content/blog/、src/pages/blog/、_posts/、blog/、posts/、articles/

見つかった場合はそのディレクトリを使用します。見つからない場合は、デフォルトでblog/posts/を使用します。

ユーザーに提示します。

「これを[検出またはデフォルトパス]/<スラッグ>.mdに保存します。別の場所に保存しますか、それとも保存せずに表示するだけにしますか？」

ディレクトリが存在しない場合は作成します。

ファイルがすでに存在する場合： 上書きするか、バージョン管理されたコピーを作成するかを尋ねます。

エラーハンドリング

• gh が利用できない → ユーザーに通知し、代替入力を提供
• 無効なPR/ref → ユーザーに確認を依頼
• プロダクトコンテキストがない → ユーザーにプロダクトの説明を依頼
• WebSearchが利用できない → フェーズ2をスキップし、自身の知識で進める
• 既存のブログディレクトリがない → デフォルトのblog/posts/を使用し、作成する

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

• ソーシャルメディア用のコピーを生成する（それには/social-copyを使用してください）
• 投稿をいずれかのプラットフォームに公開またはデプロイする
• マーケティングブリーフを生成する（それには/marketing-briefを使用してください）
• 異なる読者向けに複数のバリエーションを作成する - 別の読者向けにはスキルを再度実行してください