cook-the-blog Workflow
Befolge diese Schritte genau, wenn du aufgefordert wirst, eine Case-Studie für ein Unternehmen zu erstellen.
PFLICHTSETUP-CHECK: Bevor du beginnst, stelle sicher, dass die erforderlichen Umgebungsvariablen und Zielkonfigurationen vorhanden sind (Ziel-Repository, Image-Bucket/Speicher, Autor-E-Mail usw.). Fehlt etwas, STOPPE und frage den Benutzer danach.
PFLICHT-QA-CHECK BEI JEDEM SCHRITT: Nach jedem einzelnen Schritt unten MUSST du eine strenge, selbstkritische Qualitätskontrolle durchführen. Wenn ein Schritt fehlschlägt oder halluziniert wurde, MUSST du ihn wiederholen, bis er erfolgreich ist. Tue nicht so, als ob der Erfolg eingetreten wäre.
1. Tiefgreifende Recherche (Tavily)
- Verwende das
tavily-Tool (über MCP) und Standard-Websuchen, um das Unternehmen gründlich zu recherchieren. Hinweis: Überprüfe immer, ob der eingetragene Firmenname vom Produktnamen abweicht. Durchsuche Reddit und andere relevante Foren nach authentischen Entwickler-Einblicken. - QA-Tester: Hast du tatsächlich echte, harte Metriken und spezifische Details zu ihrer GTM-Strategie extrahiert, oder ist es allgemeiner Blödsinn? Falls Blödsinn, recherchiere tiefer.
2. SEO-Keyword-Recherche (Google Trends via SerpApi)
- Führe das Python-Skript aus:
export SERPAPI_KEY="[DEIN_SERPAPI_KEY]" && python3 [PFAD_ZUM_SEO_SKRIPT] "[Firmenname]" - Identifiziere die bahnbrechenden und wachstumsstarken Keywords aus der Ausgabe.
- QA-Tester: War das Skript erfolgreich? Sind die Keywords echt und haben sie ein hohes Volumen? Falls nicht, wiederhole den Vorgang oder passe die Abfrage an.
3. Titel- & Cover-Generierung
- Titel: Format:
"Wie [Unternehmen] [X erreichte] durch [Kernstrategie]". Mache ihn spezifisch und sehr aussagekräftig. - Cover: Verwende den Befehl
blog-cover-cli generate, um das Cover-Bild zu generieren. KRITISCH: Der Titel, der an den Cover-Bild-Generator mit dem Flag-tübergeben wird, sollte insgesamt etwa 7-10 Wörter enthalten. Verwende KEINE Zeilenumbrüche (\n) im String. Gib einfach einen normalen, einzeiligen String an und überlasse die automatische Textumbruch dem CLI! Schreibe einen prägnanten, aggressiven Titel (z. B.blog-cover-cli generate -t "Wie Baseten KI-Infrastruktur auf eine Bewertung von 5 Milliarden skalierte" -l "domain.com" -o "./cover.png"). - QA-Tester: Wurde das Bild tatsächlich generiert und gespeichert? Überprüfe, ob die Datei existiert.
4. MDX-Erstellung
Synthetisiere die Recherche und schreibe die Case-Study in einem strikten MDX-Format.
Schreibregeln (Verwende die stop-slop-Fähigkeit):
- Ton: Scharf, analytisch, gründerorientiert. Kein Blödsinn. Jeder Satz sollte etwas lehren.
- Zielgruppe: Gründer von Startups in der Frühphase, Entwickler von KI-/Entwickler-Tools, Enthusiasten des produktgesteuerten Wachstums.
- Länge: 1.200-1.800 Wörter.
- Perspektive: Analyse aus der dritten Person, wie ein kluges Investorenmemo, geschrieben für ein Bauherren-Publikum.
- Verwende niemals Gedankenstriche (—).
- Verwende immer einfaches und konversationelles Englisch mit Verbindungswörtern. Vermeide Unternehmensjargon („Synergie“, „Hebelwirkung“, „Ökosystemspiel“, „Disruption“ -> ersetze sie durch einfache Sprache).
- Jede Behauptung muss sich durch Beweise oder Logik gestützt fühlen. Verwende spezifische Zahlen.
- Jeder H3-Unterabschnitt sollte mit einem Konzeptsatz beginnen, dann den Mechanismus erklären und dann 1 Beispiel geben.
- Wiederhole den Titel nicht im MDX-Textkörper. Der Titel sollte nur im Frontmatter existieren. Füge KEIN
<h1>oder# [Titel]direkt vor dem TL;DR ein. - Schreibe niemals einen Fazit-Abschnitt. Beende den Text mit dem Absatz der Kernaussage oder den FAQs.
Das MDX muss dieser genauen Struktur folgen:
---
title: "Wie [Unternehmen] [X erreichte] durch [Kernstrategie]"
description: "[1-2 Sätze überzeugende Zusammenfassung mit harten Zahlen]"
date: "YYYY-MM-DD"
slug: "[URL-freundlicher-Slug-z.-B.-unternehmensname-case-study]"
image: "[PUBLIC_IMAGE_URL]"
readingTime: "[X] Min"
published: true
---
<div style={{ textAlign: 'left' }}>
**ZUSAMMENFASSUNG**
* **Herausforderung:** [Das zentrale schmerzhafte Problem im Markt, das sie adressierten]
* **Lösung:** [Was sie konkret anders gebaut oder gemacht haben]
* **Ergebnisse:** [2–3 harte Metriken — Downloads, Umsatz, Nutzer, Wachstums-%]
* **Investition/Strategie:** [Die eine wichtige strategische Wette, die sie eingegangen sind]
## Das Problem
[Schildere den Zustand vorher: Wie war die Welt vor der Lösung dieses Unternehmens? Wer litt, und was mussten sie stattdessen tun? Mach es anschaulich mit Entwickler-/Gründer-Sprache. Länge: 2-3 Absätze. Keine Aufzählungspunkte.]
## Die Umsetzung & GTM-Strategie
[Unterteile in 2–4 H3-Unterabschnitte, wähle aus: a) DIE VERTEILUNGSSTRATEGIE, b) DIE MONETARISIERUNGSEBENE, c) DER TECHNISCHE / PRODUKT-MOAT, d) DER INTERNE DOGGFOODING-MOMENT, e) DIE TIMING-ERKENNTNIS]
### [H3-Unterabschnitt]
[Konzeptsatz. Mechanismus. 1 Beispiel.]
## Die Ergebnisse & Erkenntnisse
[3–5 harte Metriken in Aufzählungspunkten (Downloads, Umsatz, Kunden, Conversions, Zeitersparnis)]
**Was ein kleines Startup davon lernen kann:**
[Handlungsorientierte und spezifische Erkenntnis, die direkt mit der Zielgruppe verbunden ist. Verknüpfe die Lektion direkt mit der spezifischen Strategie des Unternehmens. Keine allgemeinen Ratschläge.]
---
## Häufig gestellte Fragen
<FAQSection>
<FAQItem question="[AEO-Frage 1 - z. B. Was war ihre primäre Wachstumsstrategie?]">
[Vollständig in 2-4 Sätzen beantwortet. Niemals leer lassen.]
</FAQItem>
<FAQItem question="[AEO-Frage 2 - z. B. Wie monetarisieren sie?]">
[Vollständig in 2-4 Sätzen beantwortet. Niemals leer lassen.]
</FAQItem>
<FAQItem question="[Promotion-Frage - z. B. Wie kann mein Startup das wiederholen?]">
[Antwort, die die Strategie erklärt, gefolgt von einem subtilen Pitch für deine Marke/dein Produkt: „Wenn du daran interessiert bist, eine vorhersagbare Vertriebsmaschine wie [Unternehmen] aufzubauen, ist [YourBrand](https://yourdomain.com) auf die Konstruktion genau dieser Wachstumsschleifen spezialisiert. Buche einen Strategie-Call, um zu sehen, ob du passt."]
</FAQItem>
</FAQSection>
</div>
- QA-Tester: Sind 0 Gedankenstriche vorhanden? Sind es 1200-1800 Wörter? Sind harte Metriken enthalten? Falls nicht, schreibe neu.
5. Qualitätssicherung (QA)-Prüfung
Bevor du fortfährst, prüfe den Entwurf erneut selbst:
- MDX-Regeln: Folgt er strikt dem MDX-Format? Sind genau null Gedankenstriche vorhanden?
- Ton: Ist er prägnant und analytisch?
- Cover-Bild: Ist das Bild generiert und bereit?
6. Asset-Upload
- Lade das Cover-Bild in den bevorzugten Speicher-Bucket des Benutzers hoch (z. B. GCS, AWS S3, Cloudinary).
- Befehl: Verwende das entsprechende CLI-Tool (z. B.
gsutil cp ./cover.png [ZIEL_BUCKET]). - Überprüfe, ob die öffentliche URL mit dem Feld
image:im MDX übereinstimmt. - QA-Tester: War der Upload erfolgreich? Überprüfe, ob die öffentliche URL existiert.
7. GitHub-Veröffentlichung (Direkter Push)
- Verwende die
git-CLI, um das Ziel-Repository zu klonen:[ZIEL_REPO_URL] - Verschiebe die generierte MDX-Datei in das Zielverzeichnis (z. B.
blogs/). - Build-Prüfung: Bevor du committest, führe den Build-Befehl des Projekts aus (z. B.
npm install && npm run build) innerhalb des Repositorys, um sicherzustellen, dass die MDX-Syntax den Build nicht zerstört. - Git-Konfiguration: Stelle sicher, dass du mit den richtigen Autorendaten pushst. Führe vor dem Commit
git config user.name "[GIT_BENUTZERNAME]"undgit config user.email "[GIT_BENUTZER_EMAIL]"aus. - Committe die Änderungen und pushe direkt in den Remote-Branch von
[ZIEL_REPO_URL]mitgit pull upstream main --rebase && git push upstream main(oder der entsprechenden Remote-Struktur). - QA-Tester: War der Build erfolgreich? War der Git-Push erfolgreich? Falls nicht, behebe die Fehler.
8. Überprüfung & Auslieferung
- ÜBERSPRINGE DIES NICHT: Bevor du die Aufgabe abschließt, MUSST du
git log -1undgit statusinnerhalb des Repositorys ausführen, um zu beweisen, dass die Datei committed und gepusht wurde. - Deine endgültige Antwort an den Benutzer MUSS enthalten:
- Eine detaillierte Zusammenfassung der SerpAPI (Google Trends)-Recherche.
- Die öffentliche URL des hochgeladenen Cover-Bildes.
- Die tatsächliche Ausgabe des Befehls
git log -1, die beweist, dass die Arbeit erledigt ist.
- E-Mail-Benachrichtigung: Du MUSST auch genau diese endgültige Zusammenfassung per E-Mail an
[ADMIN_EMAIL]senden. Du kannst schnell ein Python-Skript mitsmtplibschreiben und ausführen, um es mit einem App-Passwort von der konfigurierten Absender-E-Mail zu senden. - Endgültiger QA-Tester: Hast du die E-Mail gesendet? Hast du das Git-Log in die endgültige Nachricht aufgenommen? Falls nicht, hast du die gesamte Pipeline fehlschlagen lassen.