ブログパイプライン
得られるもの: 実際の検索に答え、あなたの文体で書かれ、事実確認が済み、1200x630 の画像と有効なフロントマターを持つ記事が、専用フォルダにレビュー待ちの状態で置かれます。
最初にやること: プロジェクトのルートに記入済みの BLOG.md を配置してください（テンプレートはこのリポジトリにあります）。すべての段階でこれを読み込みます。
毎回最初に読むこと
- プロジェクトルートの
BLOG.md: サイト、読者、目標、文体、避けるべき単語、カテゴリ、公開頻度、SEO と画像のルール、フロントマターのデフォルト、および修正リスト。BLOG.mdとこのスキルで矛盾がある場合は、BLOG.mdが優先されます。 - フロントマターを書く前に
references/frontmatter-contract.mdを参照します。 - 実行する段階の参照ファイルのみを読み、それ以外は読みません。
BLOG.md がまだない場合: そこで停止し、作成を提案します。その人の既存の記事やページを 3 ～ 5 つ読み、テンプレートの各セクションの質問をし、ファイルを書き、確認を依頼します。BLOG.md なしで書かれた記事は、誰のものでもないものになります。
仕組み
ブログ記事は、誰かが Google に入力する何かに対する答えです。知識は講演、ニュースレター、クライアントとの会話から得られますが、その知識を 1 つの検索クエリを中心に再構成します。検索に一致するタイトル、先頭近くにある答え、人々が検索するように表現された見出し。
新しく書く前にリフレッシュを検討します。 既存の記事やページがその検索クエリを既にターゲットにしていないか確認します。Google が既に表示していて、閲覧数はあるがクリックがない記事は、ゼロからの新しい記事よりも価値があり、労力もはるかに少なくて済みます。1 つの検索クエリを 2 つのページで狙うと、通常は両方とも失敗します。
作業フォルダ
プロジェクト内に、記事ごとに 1 つのフォルダを作成します: posts/<YYYY-MM-DD>-<slug>/。日付は公開予定日です。スラッグは最終的なアドレスでありファイル名です。各段階は 1 つのファイルをこのフォルダに書き込むため、フォルダが記憶域の役割を果たします。どの段階も、前の段階をやり直すことなく再実行したり、後で再開したりできます。
| # | 段階 | 読み込み元 | 書き込み先 | 手順書 |
|---|---|---|---|---|
| 1 | 発想 | BLOG.md、検索データ、既存の記事とページ | posts/_ideas/topic-ideas.md | references/01-ideation.md |
| 2 | 概要 | 1 つのトピック | brief.md | references/02-brief.md |
| 3 | 調査 | brief.md | research.md | references/03-research.md |
| 4 | 下書き | research.md、brief.md、BLOG.md | draft.md | references/04-draft.md |
| 5 | ビジュアル | draft.md | visuals.md、<slug>.svg、<slug>.png | references/05-visuals.md |
| 6 | 公開 | draft.md、visuals.md | src/content/blog/ 内の記事、public/images/blog/ 内の画像、publish.md | references/06-publish.md |
全チェーン: 1 つのトピックに対して段階 2 から 6 を順に実行します。段階 1 はバッチステップです。アイデアリストが少なくなったら（週 1 回のペースなら月に 1 回程度）実行します。
「最初の記事を計画して」（または「次の記事を計画して」）: 段階 1、次に段階 2。発想を実行し、候補リストを表示し、1 つのトピックを選んでもらい（必ずしも 1 番である必要はありません。選択とその理由を topic-ideas.md に記録します）、その概要を書きます。概要を書いたら停止し、次に来る段階を伝えます。「トピックのアイデアを見つけて」と依頼された場合は段階 1 のみを実行し、「<トピック> の概要を書いて」と依頼された場合は段階 2 のみを実行します。
単一の段階: その人が段階と記事を指定します。指定された段階のファイルとその入力を読み、残りはスキップします。
リフレッシュ: 段階 1 と 2 をスキップします。posts/<today>-<slug>-refresh/ フォルダを作成し、リフレッシュモードで段階 3 と 4 を実行し、次に段階 6 を実行します。
上記のパスはスターターサイトのものです。BLOG.md に他のフォルダがリストされている場合は、それらを使用します。
ルール
これらは、どの段階のファイルよりも優先されます。BLOG.md でさらにルールを追加できます。
- 情報源、統計、引用、リンクを決して捏造しないでください。 記事内のすべての URL は、調査中に開かれたものです。検証できない主張は削除するか、その人が確認できるように
[UNVERIFIED]とマークします。その人の個人的な経験は、それがその人のものであると明記されている場合に限り、情報源として扱います。その人の仕事からの数字には、プロジェクト内のファイルか、research.md（段階 3）に記録された日付入りのチャットの引用が必要です。これらがない場合は[UNVERIFIED]となり、公開ファイルには掲載しません。 - ツールやプラットフォームに関する事実は、最新のドキュメントに照らして確認してください。 機能や制限は変更され、昨年のハウツーは今日では間違っていることがよくあります。
- 検索ボリュームや難易度は、実際のデータであるか、そのようにラベル付けされている必要があります。 誰かが実行したツールからのボリュームと難易度には日付を付けるか、ファイルに「未推定」と記載します。データとして提示された推測値は、数値がないよりも有害です。
- 公開前に毎回、その人が下書きをレビューします。 新しい記事には
draft: trueを設定します。このスキルは、プッシュ、デプロイ、またはdraftの変更を単独で行うことはありません。唯一の例外は、公開済みの記事のリフレッシュであり、その場合はdraft: falseを維持します（段階 6 を参照）。 - 承認: タイミング、方法、編集内容の反映先。 これはスキルが定義する唯一の場所であり、段階 6 はこれに従います。
- タイミング: 段階 6 が公開ファイルを作成し、その人が記事を読んだ後の任意のタイミング。同じセッションでも問題ありません。
- 方法: 1 つの変更。その人が
src/content/blog/<slug>.mdでdraft: falseに設定するか、Claude に指示します。同時にdateが公開日であることを確認します。 - 編集内容の反映先: 段階 6 の前は、
posts/<folder>/draft.mdに反映します。段階 6 の後は、公開ファイルのみに反映します。draft.mdは引き渡された下書きのまま保持され、publish.mdにその後の各変更がリストされます。 - 保留条件: 公開日までにやるべきことが残っている場合（不足しているページ、
[UNVERIFIED]の主張、リンク監査で出力された行など）、その記事はdraft: trueのままとなり、完了するまで公開されません。
- 日付が公開のゲートです。 スターターサイトは、公開日が未来の記事を非表示にし、「公開予定の記事」としてリストします。
- クライアントの仕事は、クライアントが名前を出すことに同意した場合を除き、匿名のままにします。 名前を削除するだけでは不十分です。カテゴリ、場所、タイミングの組み合わせがクライアントを特定する可能性がないか確認します（「3月に開店したバーモント州のキャンドルショップ」は特定につながります）。収益は比率またはパーセンテージに変換します。
- 答えを最初に述べます。 読者が自分の仕事から認識できるコンテキストを 1 文、次に 3 段落目までに答えを述べます。質問で記事を始めることはありません。
- 検索クエリに合わせて書き、行動喚起は 1 つにします。 見出しは人々が検索するように表現し、数字は算用数字を使用し、段落は短くします。メインの行動は
BLOG.mdのセクション 3 にあるものであり、src/site.config.mjsのctaと一致します。スターターサイトは各記事の最後にそのボタンと購読ボックスを表示するため、本文に閉じの行動喚起リンクは必要ありません。本文のテキスト内で、記事に合致する場合に限り、1 回だけメインの行動へのリンクを張ることができます。リンク先は実際に存在するページか、ctaアドレスに限ります。 - リンクは、記事の公開日に公開されているページにのみ貼ります。 つまり、自サイトのドメインへのリンクはすべて、そのサイト内の記事やページへのリンクであることを意味します。自サイトへのリンクは相対リンク（
/about/）で記述します。段階 6 でチェックします。 - 文体はその人のものです。 すべてのルールを満たしていても、下書きが有能な第三者によるコンテンツのように読める場合は失敗です。
修正はルールになる
その人が同じことを 2 回修正した場合（単語、書き出し、見出しスタイルなど）、BLOG.md の「修正」セクションに日付入りの行を追加することを提案します。段階 4 はすべての下書きの前にこのセクションを読み込むため、一度修正された内容は確実に反映されます。
下書きを引き渡す前のチェック
BLOG.md の「避けるべき単語」に含まれるすべての単語を下書きから検索します。例:
grep -n -i -E "word one|word two|—" posts/<folder>/draft.md
単語検索では見逃される文の形があります。段階 4 で（「単語検索では見逃される形」というセクションを）実行し、BLOG.md にリストされている、検索では捉えられない形（冒頭の質問や末尾のまとめなど）について下書きを 1 回読み直します。また、すべての事実に関する文章が research.md と一致するか確認します（段階 4）。
その後、次の内容を数行でその人に伝えます: 下書きの場所、ターゲット検索クエリ、予定日、[UNVERIFIED] とマークされたもの、機密性に関する質問、そしてその人が決定すべきこと。
オプション: ニュースレター版
その人がニュースレター（Substack、Beehiiv、Kit など）も発行している場合、同じ知識をそこでも公開できます。ニュースレター版には独自のタイトルと独自の検索フレーズを付け、Google で 2 つのページが競合しないようにし、段階 1 と 2 の重複チェックにニュースレターのアーカイブを追加します。
ツール
Claude Code、またはプロジェクトのファイルにアクセスできる Claude。検索データは無料ツールから取得します: Google オートコンプリート、Google Search Console、無料の Ubersuggest プラン、および 1 ページ目のプレーンな Google 検索。ツールが接続されていない場合は、その人に表示されている内容を貼り付けてもらうか（Ubersuggest は Web サイトで問題なく動作します）、数値を未推定とマークします。データやツールがない新しいサイトでも問題なく進められます。references/01-ideation.md にその方法が記載されています。
このセッションでは Web にアクセスできない場合: 段階 1 は、持っている証拠に基づいてアイデアをランク付けし、残りは「未確認」とマークします。その人は選択した 1 つのターゲット検索について、概要が承認される前の段階 2 で、オートコンプリートの提案と 1 ページ目を貼り付けます。候補リスト全体について貼り付けを行う人はいません。API キーは BLOG.md や記事フォルダから遠ざけてください。