blog-planner

ブログプランナー

Electric ブログの記事を企画し、アウトラインを作成します。出力は、published: false を指定したドラフトの Markdown ファイルで、website/blog/posts/ に直接配置されます。著者はアウトラインをその場で進め、圧縮された箇条書きを文章に展開し、素材を差し替えていきます。

実行方法

/blog-planner [optional: path to existing draft or reference material]

ユーザーが既存の資料（ドラフト、ドキュメント、PRD、メモ）へのパスを提示した場合は、背景と内容を把握するために読み込んでください。内容を理解しつつ、構成に引きずられすぎないようにしてください。アウトラインの構成は、元資料ではなく選択した形式に基づきます。

執筆の流れ

以下のフェーズを順番に進めます。質問は一度に1つずつしてください。明確で、誠実で、役に立つ対応をしてください。質問をゲームのように演出したり、パフォーマンスをしたりせず、価値を提供したら著者の邪魔にならないようにしましょう。

フェーズ1：情報収集

アイデアの概要を把握します。

• 記事のテーマは何ですか？
• 著者は誰ですか？（Electric ブログの著者キーを使用してください：thruflo、kyle、samwillis、icehaunter、balegas、oleksii、purva）
• 参照する既存の資料はありますか？（ドラフト、PRD、RFC、デモ、PR、ドキュメントなど）。ある場合は、今すぐ読み込んでください。

フェーズ2：意図を明確にする

この記事を書く価値がある理由を明確にします。それぞれの答えが簡潔になるまで掘り下げてください。

• この記事のテーマは何ですか？ — 1文で。
• 何が興味深いのですか？ — 読者が関心を持つ理由は何ですか？ 読者を引きつける要素は何ですか？
• 読者が得るものは何ですか？ — 読んだ後、読者は読む前には知らなかった、あるいは信じていなかったどんなことを知り、信じるようになりますか？
• CTA／次のステップは何ですか？ — 読んだ後、読者に何をしてほしいですか？
• なぜ私たち／著者がこれを書くのにふさわしいのですか？ — 説得力につながる権威や経験は何ですか？

これらの答えは、出力ファイルのメタセクションにある「意図」ブロックになります。

フェーズ3：形式を選ぶ

意図に基づいて3つの形式のうち1つを提案し、著者に確認します。著者が形式を選んだ場合は、その形式を使用してください。別の形式を勧め直す必要はありません。

形式	使用する場面
ピラミッド原則	明確に伝えたい主張があり、論理的な論証を組み立てる必要がある場合。技術的な説明、「Xをどのように構築したか」、内容のある意見記事に適しています。
ベストセールスデッキ	概念やパラダイムシフトを紹介する場合。世の中の大きな変化を示し、勝者と敗者を明らかにし、約束された未来を予告してから、解決策を紹介するストーリー展開です。カテゴリーの転換をもたらす製品ローンチや、ソートリーダーシップに適しています。
リリース記事	何かをリリースした場合。それを明確に伝えます。段階的なリリースや新機能の告知に使う定番の形式です。常に出荷し続けましょう。

形式が決まったら、references/ から対応するリファレンスファイルを読み込みます。

フェーズ4：アウトラインのドラフトを作成する

選択した形式に沿って、セクション単位のアウトラインを作成します。

• アウトラインをセクションごとに提示し、フィードバックを受ける
• 箇条書きは意味を圧縮して表現します。それぞれを、最小限の言い換えで1～2文の文章に展開できるようにします
• 各セクションが構成上どのような役割を果たすのか、著者がどのようなトーンや内容を目指すべきかを説明する HTML コメントをインラインで含めます
• 素材を配置する場所には `` コメントで印を付けます
• ピラミッド原則とベストセールスデッキでは、形式固有の構成より前に TLDR と情報ボックスを置きます
• 著者が構成と内容に満足するまで反復します

アウトラインの箇条書きの書き方：

• 圧縮された表現で、直接的かつ具体的にする
• 各箇条書きでは、明確なアイデアを1つ扱う
• 箇条書きは意味を圧縮しているため、文章に展開すると新しい表現になることがよくあります。それを踏まえて最適化してください
• 「堅牢な」「スケーラブルな」「柔軟な」「活用する」「エコシステム」「画期的な」「革命的な」は避け、実際の意味を具体的に述べる
• LLM らしい表現は避けます。「注目すべき点は」「重要なのは」「結論として」「詳しく見ていきましょう」「本質的には」「今日の状況では」などは使わないでください

フェーズ 5: エートス / クリエイティブな切り口

ピラミッド原則とベストセールスデックの形式のみを対象とします。

書き手の個人的な切り口を引き出します:

• これをリアルにする特定の瞬間、体験、逸話はありますか?
• セットアップをより鮮明にするクリエイティブなフレーミングはありますか?

これを Situation/Complication(ピラミッド)または Big Change(ベストセールスデック)セクションのアウトラインビュレットに織り込みます。クリエイティブな要素が構造的にどのように機能するかを説明するコメントで注釈を付けます。これは今行うものであり、執筆フェーズで書き手が考えるために残すものではありません。

フェーズ 6: 評価

アウトラインがフェーズ 2 の意図を満たしているかを評価します。

• 構造は記事の要点に貢献していますか?
• 論理は成り立っていますか?(非公式に — 全体としてまとまっているか、博士論文の審査ではない)
• ギャップや弱いセクションはありますか?
• 読者はアウトラインに沿って意図した結論に到達できるでしょうか?
• フックは十分に強力ですか?

問題があれば提起し、書き手とともに反復します。

フェーズ 7: メタ情報を埋める

フッターのメタセクションに戻ります。以下について簡単なブリーフを起草します:

• タイトルブリーフ — 最終タイトルの方向性。タイトルは Title Case ではなく、sentence case を使用します。
• 説明ブリーフ — SEO 向け。HTML は使いません。何を伝えるべきでしょうか?
• 抜粋ブリーフ — ブログ一覧カード向け。最大 3 文の短い文。一覧表示の一貫性のために、既存の記事の抜粋と同じ語数に合わせます。
• 画像プロンプト — 以下の画像ブリーフのガイドラインを参照してください。詳細な画像ブリーフが必要な場合は、書き手に /blog-image-brief コマンドの使用を提案してください。
• 未解決の疑問 — 未解決の事項。

フェーズ 8: アセットを集める

アウトラインが固まったので、必要なアセットを棚卸しします:

• コードサンプル、図(既存または作成予定、mermaid または手動)、デモ動画、スクリーンショット、埋め込みツイート、外部ブログ記事へのリンク
• 各アセットをアウトライン内の位置にマッピングする
• 各アセットが既存か作成が必要かを記録する
• メタフッターのアセットチェックリストに記録する

フェーズ 9: ファイルを書く

アウトラインを website/blog/posts/YYYY-MM-DD-slug.md に保存します。

• ファイル名のプレフィックスには今日の日付を使用する
• 作業タイトルから slug を導出する(kebab-case)
• frontmatter で published: false を設定する
• 確定が必要な frontmatter フィールド(タイトル、説明、抜粋)には ... プレースホルダーを使用する — コメント化されたフッター内のブリーフが書き手に何を書くべきか導きます

出力形式

出力は、書き手がその場で仕上げていく実際のブログ記事ファイルです。

Frontmatter

---
title: '...'
description: >-
  ...
excerpt: >-
  ...
authors: [author-key]
image: /img/blog/slug/header.jpg
tags: [...]
outline: [2, 3]
post: true
published: false
---

タイトル、説明、抜粋には ... を使用します。これらはメタフッターのブリーフを使って書き手が記入します。タグは意図のディスカッションから設定できます。

本文の構造

すべての形式は次のパターンに従います:

1. TLDR オープナー — これが何であり、なぜ重要なのかを述べる 1〜2 の短い段落。圧縮し、セットアップもマーケティング的なトーンもなし。技術系の読者は要点をすぐに求めています。その後に主要リンクを含む情報ボックスを続けます。
2. 形式固有の本文 — 選択した形式リファレンスに従ったセクション構造。インライン HTML コメントが各セクションの目的とトーンについて書き手を導きます。
3. 次のステップ — CTA、リンク、今すべきこと。
4. *** セパレーター
5. コメント化されたメタフッター — 意図、タイトルブリーフ、説明ブリーフ、抜粋ブリーフ、画像プロンプト、アセットチェックリスト、未解決の疑問。公開前に削除するよう指示する文言を先頭に付けます。

インラインコメント

以下には HTML コメントを使用します:

• 構造的なガイダンス: このセクションが形式の論理の中で何をしているか
• トーンの指示: 書き手がこのセクションをどう書くべきか
• アセットマーカー: `` アセットが入る場所
• 書き手へのメモ: 特定のビュレットを展開するための具体的な指示

コメントは markdown ではレンダリングされず、書き手が各セクションを執筆する際に削除します。

組版ガイドライン

メタフッターに、以下をチェックリストとして記載してください。

• ウィドウやオーファンを避けるため、適切な箇所でノーブレークスペース（HTML では  、フロントマターでは \u00A0）とノーブレークハイフンを使用する
• タイトルは必ずセンテンスケースにし、タイトルケースは使用しない
• タイトル、画像、記事全体を異なる画面幅で確認する
• LLM らしい表現を避ける：「注目に値します」「重要なのは」「結論として」「詳しく見ていきましょう」「本質的には」「今日の状況において」

参考ブログ記事

優れた実例となる、Electric の著者による既存の記事です。トーン、構成、品質の参考にしてください。

ピラミッド原則／ストーリー展開：

• Durable sessions for collaborative AI — thruflo
• Bringing agents back down to earth — thruflo
• Building AI apps on sync — thruflo

優れたセールス資料／コンセプト：

• Announcing Durable Streams — kyle, samwillis
• Super-fast apps on sync with TanStack DB — thruflo

リリース記事：

• Electric 1.0 released — thruflo
• Announcing Hosted Durable Streams — kyle

画像の概要（簡易版）

画像の方向性を簡単に示す場合は、メタフッターに以下を記載してください。

• 画像の題材／コンセプト
• アスペクト比：16:9～16:10（目標サイズは約1536x950px）
• 高品質な JPG をマスターとして作成する
• 中央揃えの構図にし、重要な内容を内側のフレームに配置する （レスポンシブなトリミングで端が切り落とされます）
• ブランドカラー：#D0BCFF（紫）、#00d2a0（緑）、#75fbfd（シアン）、 #F6F95C（黄色）、#FF8C3B（オレンジ）
• ダークテーマの背景
• サイトでは OpenSauceOne フォントを使用

参考画像の分析と ChatGPT DALL-E 用の完全なプロンプトを含む詳細な画像の概要を作成する場合は、別途 /blog-image-brief コマンドを使用してください。

レビュー

著者がアウトラインを文章にまとめたら、/blog-review を使用して、アウトライン、フォーマット、実行ガイドラインに照らしてドラフトをレビューしてください。