Varnan-Tech/opendirectory

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. タイトルとカバー生成

• タイトル: 形式: "How [Company] [Achieved X] by [Core Strategy]"。具体的で非常に説明的なものにしてください。
• カバー: 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ダッシュ（—）を使用しないでください。
• 常にシンプルで会話調の英語を使用し、接続詞を使ってください。コーポレートジャーゴン（「シナジー」「レバレッジ」「エコシステムプレイ」「ディスラプション」など）は避け、平易な言葉に置き換えてください。
• すべての主張は、証拠や論理に裏付けられているように感じられる必要があります。具体的な数値を使用してください。
• 各H3サブセクションは、概念を表す文で始め、メカニズムを説明し、1つの例を示すようにしてください。
• MDX本文内でタイトルを繰り返さないでください。 タイトルはフロントマター内にのみ存在する必要があります。TL;DRの直前に<h1>や# [タイトル]を含めないでください。
• 結論セクションは絶対に書かないでください。テイクアウェイの段落かFAQで終わらせてください。

MDXは以下の正確な構造に従う必要があります:

---
title: "How [Company] [Achieved X] by [Core Strategy]"
description: "[ハードな数値を含む1〜2文の説得力のある要約]"
date: "YYYY-MM-DD"
slug: "[URLに適したスラッグ（例: company-name-case-study）]"
image: "[PUBLIC_IMAGE_URL]"
readingTime: "[X] Min"
published: true
---

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

**TL;DR**
* **課題:** [彼らが取り組んだ市場の核となる困難な問題]
* **解決策:** [彼らが具体的に構築したもの、または異なる方法で行ったこと]
* **結果:** [2〜3のハードな指標 — ダウンロード数、収益、ユーザー数、成長率]
* **投資/戦略:** [彼らが行った唯一の重要な戦略的賭け]

## 問題
[ビフォーの状態を描く: この会社のソリューションが登場する前の世界はどのようなものだったか？誰が苦しんでいて、代わりに何を強いられていたか？生々しく、開発者/創業者の言葉を使って描写する。長さ: 2〜3段落。箇条書きは禁止。]

## 実行とGTM戦略
[以下から2〜4つのH3サブセクションに分割: a) 流通戦略、b) 収益化レイヤー、c) 技術的/プロダクトの堀、d) 内部ドッグフーディングの瞬間、e) タイミングの洞察]
### [H3サブセクション]
[概念文。メカニズム。1つの例。]

## 結果とテイクアウェイ
[箇条書きで3〜5のハードな指標（ダウンロード数、収益、顧客数、コンバージョン率、節約時間）]

**小さなスタートアップが彼らから学べること:**
[対象読者に直接結びつく、実用的で具体的なテイクアウェイ。教訓を会社の具体的な戦略に直接結びつけてください。一般的なアドバイスは禁止。]

---

## よくある質問

<FAQSection>
  <FAQItem question="[AEO質問1 - 例: 彼らの主要な成長戦略は何でしたか？]">
    [2〜4文で完全に回答。空白のままにしないでください。]
  </FAQItem>

  <FAQItem question="[AEO質問2 - 例: どのように収益化していますか？]">
    [2〜4文で完全に回答。空白のままにしないでください。]
  </FAQItem>
  
  <FAQItem question="[プロモーション質問 - 例: 私のスタートアップでもこれを再現できますか？]">
    [戦略を説明する回答の後、自社ブランド/製品へのさりげないピッチ: 「[Company]のような予測可能な流通エンジンを構築したいなら、[YourBrand](https://yourdomain.com)はまさにそのような成長ループを設計する専門家です。お客様に合うかどうか、戦略相談を予約してください。」]
  </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ログを含めましたか？含めていない場合、パイプライン全体は失敗です。