cook-the-blog

cook-the-blog ワークフロー

企業のケーススタディの作成を依頼された場合は、以下の手順に正確に従ってください。

必須のセットアップ確認： 作業を始める前に、必要な環境変数と出力先が設定されていることを確認してください（対象リポジトリ、画像バケット／ストレージ、著者のメールアドレスなど）。不足しているものがあれば、作業を中止してユーザーに確認してください。

各ステップでの必須の QA 確認： 以下の各ステップを完了するたびに、必ず厳密かつ批判的に QA を行ってください。ステップに失敗した場合、または内容を捏造している場合は、成功するまで必ずやり直してください。成功を装ってはいけません。

1. 詳細なリサーチ（Tavily）

• tavily ツール（MCP 経由）と通常のウェブ検索を使って、企業について詳しく調査してください。注： 登録上の事業名が製品名と異なるか、必ず確認してください。Reddit やその他の関連フォーラムを検索し、開発者の率直な意見を探してください。
• QA 担当者： 実際の具体的な数値や、同社の GTM 戦略の詳細を抽出できましたか？ それとも、ありきたりな内容に終わっていますか？ 内容が薄い場合は、さらに調査してください。

2. SEO キーワード調査（SerpApi 経由の Google Trends）

• Python スクリプトを実行してください：export SERPAPI_KEY="[YOUR_SERPAPI_KEY]" && python3 [PATH_TO_SEO_SCRIPT] "[Company Name]"
• 出力から、急上昇中で成長率の高いキーワードを特定してください。
• QA 担当者： スクリプトは正常に実行できましたか？ キーワードは実在し、検索ボリュームも多いものですか？ そうでない場合は、再試行するか、クエリを調整してください。

3. タイトルとカバー画像の生成

• タイトル： 形式：「[Company] が [Core Strategy] によって [Achieved X] を達成した方法」。具体的で、内容がよく伝わるものにしてください。
• カバー画像： blog-cover-cli generate コマンドを使ってカバー画像を生成してください。重要： カバー画像生成ツールに -t フラグで渡すタイトルは、合計 7～10 語程度にしてください。文字列に改行（\n）を含めないでください。通常の 1 行の文字列を渡せば、CLI が自動的に折り返します。簡潔で力強いタイトルにしてください（例：blog-cover-cli generate -t "How Baseten Scaled AI Infrastructure To a 5 Billion Valuation" -l "domain.com" -o "./cover.png"）。
• QA 担当者： 画像は実際に生成され、保存されていますか？ ファイルの存在を確認してください。

4. MDX の組み立て

調査結果をまとめ、厳密な MDX 形式でケーススタディを執筆してください。 執筆ルール（stop-slop スキルを使用）：

• トーン：鋭く、分析的で、創業者を意識したものにします。余計な内容は避けます。すべての文から学びが得られるようにしてください。
• 対象読者：スタートアップの創業初期の創業者、AI／開発者向けツールの開発者、プロダクト主導型の成長に関心のある人。
• 長さ：1,200～1,800 語。
• 視点：開発者向けに書かれた、洞察力のある投資家メモのような三人称の分析にします。
• em ダッシュ（—）は絶対に使用しないでください。
• 接続語を使った、平易で会話調の英語を常に使ってください。企業用語（「synergy」「leverage」「ecosystem play」「disruption」など）は避け、平易な表現に置き換えてください。
• すべての主張に、根拠または論理的な裏付けがあるようにしてください。具体的な数字を使ってください。
• 各 H3 の小見出しは、概念を示す文から始め、その後に仕組みを説明し、例を 1 つ示してください。
• MDX の本文でタイトルを繰り返さないでください。タイトルはフロントマターにのみ記載してください。TL;DR の直前に <h1> や # [Title] を含めないでください。
• 結論のセクションは書かないでください。締めくくりは、要点をまとめた段落または FAQ にしてください。

MDX は、以下の厳密な構成に従ってください。

---
title: "How [Company] [Achieved X] by [Core Strategy]"
description: "[1-2 sentence compelling summary with hard numbers]"
date: "YYYY-MM-DD"
slug: "[URL-friendly-slug-e.g.-company-name-case-study]"
image: "[PUBLIC_IMAGE_URL]"
readingTime: "[X] Min"
published: true
---

<div style={{ textAlign: 'left' }}>

**TL;DR**
* **Challenge:** [The core painful problem in the market they addressed]
* **Solution:** [What they specifically built or did differently]
* **Results:** [2–3 hard metrics — downloads, revenue, users, growth %]
* **Investment/Strategy:** [The one key strategic bet they made]

## The Problem
[Paint the before-state: What was the world like before this company's solution? Who was suffering, and what were they forced to do instead? Make it visceral use developer/founder language. Length: 2-3 paragraphs. No bullet points.]

## The Execution & GTM Strategy
[Break into 2–4 H3 sub-sections picking from: a) THE DISTRIBUTION STRATEGY, b) THE MONETIZATION LAYER, c) THE TECHNICAL / PRODUCT MOAT, d) THE INTERNAL DOGFOODING MOMENT, e) THE TIMING INSIGHT]
### [H3 Sub-section]
[Concept sentence. Mechanism. 1 Example.]

## The Results & Takeaways
[3–5 hard metrics in bullet points (downloads, revenue, customers, conversions, time saved)]

**What a small startup can take from them:**
[Actionable and specific takeaway connected directly to the target audience. Tie the lesson directly to the company's specific strategy. No generic advice.]

---

## Frequently Asked Questions

<FAQSection>
  <FAQItem question="[AEO Question 1 - e.g., What was their primary growth strategy?]">
    [Fully answered in 2-4 sentences. Never leave blank.]
  </FAQItem>

  <FAQItem question="[AEO Question 2 - e.g., How do they monetize?]">
    [Fully answered in 2-4 sentences. Never leave blank.]
  </FAQItem>
  
  <FAQItem question="[Promotion Question - e.g., How can my startup replicate this?]">
    [Answer explaining the strategy, followed by a subtle pitch for your brand/product: "If you are looking to build a predictable distribution engine like [Company], [YourBrand](https://yourdomain.com) specializes in engineering these exact growth loops. Book a strategy call to see if you are a fit."]
  </FAQItem>
</FAQSection>

</div>

• QA 担当者： em ダッシュは 0 個ですか？ 1,200～1,800 語ですか？ 具体的な数値が含まれていますか？ そうでない場合は、書き直してください。

5. 品質保証（QA）チェック

次に進む前に、ドラフトをもう一度自己点検してください。

• MDX ルール： MDX 形式に厳密に従っていますか？ em ダッシュは 0 個ですか？
• トーン： 歯切れがよく、分析的ですか？
• カバー画像： 画像は生成され、使用できる状態ですか？

6. アセットのアップロード

• カバー画像を、ユーザーが希望するストレージバケット（例：GCS、AWS S3、Cloudinary）にアップロードしてください。
• コマンド：適切な CLI ツールを使ってください（例：gsutil cp ./cover.png [TARGET_BUCKET]）。
• 公開 URL が MDX の image: フィールドと一致することを確認してください。
• QA 担当者： アップロードは成功しましたか？ 公開 URL にアクセスできることを確認してください。

7. GitHub への公開（直接プッシュ）

• git CLI を使用して、対象リポジトリ [TARGET_REPO_URL] をクローンします。
• 生成した MDX ファイルを対象ディレクトリ（例：blogs/）に移動します。
• ビルドチェック： コミットする前に、リポジトリ内でプロジェクトのビルドコマンド（例：npm install && npm run build）を実行し、MDX の構文によってビルドが失敗しないことを確認します。
• Git の設定： 正しい作者情報でプッシュしていることを確認します。コミットする前に git config user.name "[GIT_USER_NAME]" と git config user.email "[GIT_USER_EMAIL]" を実行します。
• 変更をコミットし、git pull upstream main --rebase && git push upstream main（または同等のリモート構成）を使用して、[TARGET_REPO_URL] のリモートブランチに直接プッシュします。
• QA テスター： ビルドは成功しましたか？Git のプッシュは成功しましたか？成功していない場合は、エラーを修正してください。

8. 検証と納品

• これを省略しないでください： タスクを完了する前に、リポジトリ内で必ず git log -1 と git status を実行し、ファイルがコミットされ、プッシュされたことを証明してください。
• ユーザーへの最終回答には、必ず以下を含めてください。
  1. SerpAPI（Google Trends）の調査結果の詳細な要約。
  2. アップロードしたカバー画像の公開 URL。
  3. 作業完了を証明する git log -1 コマンドの実際の出力。
• メール通知： 同じ最終要約を [ADMIN_EMAIL] にも必ずメールで送信してください。設定済みの送信者メールアドレスとアプリパスワードを使い、smtplib で Python スクリプトを作成・実行すれば、すぐに送信できます。
• 最終 QA テスター： メールを送信しましたか？最終メッセージに git log を含めましたか？できていない場合、パイプライン全体が失敗したことになります。