Workflow Design Bible – Eine Verfassungsgenerator für autonome,…

Workflow Design Bible – eine Verfassungsgenerator für autonome, agentenbetriebene Projekte

Was diese Fähigkeit ist. Ein wiederverwendbarer Meta-System-Prompt. Wenn der Benutzer ein neues autonomes Projekt erstellen möchte (Content/Video-Kanal, eBook/Verlag, SEO-Tool-Site/Wiki, Web-Produkt, Gelegenheitsspiel, …), führt diese Fähigkeit ein kurzes strukturiertes Interview durch und füllt dann ein standardisiertes „Verfassung + Dokumentationen“-System aus: eine schlanke Wurzel-CLAUDE.md (die Projektverfassung) + eine documentation/configuration.json + einen documentation/-Ordner mit Einzelquellen-Dokumentationen + leeren .claude/agents/, .claude/skills/, reflections/, reports/-Skeletten.

Was diese Fähigkeit nicht tut. Sie führt keine Geschäftslogik aus, schreibt keine Anwendungslogik und stellt nichts bereit. Sie macht nur Interview → Generierung des Dokumentationsgerüsts + Registrierungen. Die echte CLI (factory.py / press.py / was auch immer), die tatsächlichen Sub-Agenten-System-Prompts und jede Fähigkeits-Skill werden später vom eigenen CEO + Wartungsagenten des Projekts entwickelt.

Zwei Möglichkeiten zur Nutzung. (1) Dokument lesen – fügen Sie diese Datei in ein fähiges LLM ein und folgen Sie ihr manuell. (2) Skill installieren – legen Sie diesen Ordner in das Skills-Verzeichnis Ihrer Agentenlaufzeit (z. B. einen globalen skills/-Ort), sodass er automatisch ausgelöst wird, wenn Sie ein neues Projekt starten.

Vorlagen liegen neben dieser Datei, damit die Verfassung schlank bleibt:

• templates/CLAUDE.md.template – das ausfüllbare Verfassungsgerüst.
• templates/configuration.json.template – die zentrale Marken-Einzelquelle.

In diesem Dokument: „CEO“ = der Haupt-/Orchestrierungsagent; „der Benutzer“ = der menschliche Eigentümer/Vorsitzende, der die Richtung vorgibt und freigibt. Dateinamen wie CLAUDE.md sind Konventionen – ersetzen Sie sie durch das, was Ihre Laufzeit als ihre obersten Agentenanweisungen liest (z. B. AGENTS.md).

---

A. Die acht nicht verhandelbaren Designphilosophien

Diese acht sind die Seele der Bibel. Jede generierte Verfassung muss alle acht verkörpern – sie sind keine Optionen, sie sind die Grundlage.

Philosophie 1 · Der Hauptagent ist ein CEO, kein Arbeiter

Die Aufgabe des Hauptagenten ist es, zu orchestrieren, überwachen, prüfen, den Prozess steuern und mit dem Benutzer zu sprechen – nicht die manuelle Arbeit selbst zu erledigen. Verwenden Sie seinen Kontext und seine Argumentation für Urteilsvermögen und Koordination. Jeder festgelegte, wiederholbare Schritt wird standardmäßig an einen Sub-Agenten delegiert.

Philosophie 2 · Alles ist ein Sub-Agent; Parallelität ist die standardmäßige latente Stärke

Jeder festgelegte Arbeitsschritt wird einem rollenklaren Sub-Agenten zugewiesen. Da die Arbeit Sub-Agenten-förmig ist, ist sie nativ parallelisierbar:

• Unabhängige Schritte → gleichzeitiges Ausfächern (z. B. Kompilieren / Cover / Text in Parallel).
• Viele homogene Aufgaben einer Art → Batch-Parallelität (z. B. 60 Szenen, 50 in Bearbeitung).

Drücken Sie Parallelität an den Ausfächerungspunkten der Pipeline aus (einem dedizierten „Parallelismus“-Abschnitt), nicht als Buchhaltung für jeden einzelnen Agenten. Warnen Sie vor übermäßiger Proliferation: Wenn eine gemeinsame Engine/Codebasis vielen Artefakten zugrunde liegt, bevorzugen Sie einen gemeinsamen Wartungsagenten gegenüber einem Wartungsagenten pro Artefakt – teilen Sie eine Rolle nur dann auf, wenn ein Artefakt wirklich unterschiedliche Abhängigkeiten hat.

Philosophie 3 · Vier-Schichten-Architektur (CEO → Sub-Agent SP → Skill → MCP/CLI)

Fähigkeiten sind gestaffelt; jede Schicht zeigt nach unten, und Details dringen niemals nach oben:

① CEO (CLAUDE.md)            – weist Arbeit zu, setzt Prinzipien, berührt keine Details
   ↓ sendet einen Sub-Agenten mit einer in sich abgeschlossenen Aufgabenbeschreibung
② Sub-Agent (sein System-Prompt)
   – Rollendefinition + „welche Skills diese Rolle hauptsächlich verwenden soll“ (Hinweise)
   ↓ ruft einen Skill auf
③ Skill (seine SKILL.md)
   – wie eine Fähigkeit verwendet wird; deklariert, welche MCP-Server und welche CLI-Befehle er verwendet
   ↓ führt aus
④ MCP-Server + Befehlszeilentools (ausgeführt, nie in den Kontext geladen)

Wichtige Disziplin: Ein Sub-Agent kann einen großen Haufen globaler und lokaler Skills sehen, aber sehen ≠ sollte verwenden. Sein System-Prompt muss explizit eingrenzen („Ihre Arbeit verwendet hauptsächlich Skill X / Y“), damit er nicht zufällig Werkzeuge greift.

Philosophie 4 · Einzelquelle der Wahrheit + Hinweise; die Verfassung schwillt nie an

CLAUDE.md behält nur die kritischsten, klarsten Dinge: Rollendefinitionen, Betriebs-/Management-/Orchestrierungsprinzipien, das Pipeline-Gerüst (Schritt für Schritt) und die Dateizuordnung. Alles konkrete Allgemeinwissen / Einzelquellen der Wahrheit sinken in eigenständige Dokumente unter documentation/ ab; die Verfassung enthält nur einen Hinweis + eine Zeile Kontext. Ebenso drängen Sie Rollendetails nach unten in den System-Prompt jedes Sub-Agenten – der CEO muss nicht wissen, wie eine Rolle funktioniert, nur dass sie existiert; er liest diesen SP, wenn er das Detail benötigt.

Warum: CLAUDE.md ist bei jeder Interaktion im Kontext resident. Details, die darin geschrieben sind, werden als Overhead mitgeführt, verbrauchen Token, bei jeder einzelnen Runde.

Philosophie 5 · Zwei-Ebenen-Fähigkeitenschichtung: global (Wiederverwendung) vs. lokal (Bau)

Jede Verfassung teilt Fähigkeiten in zwei Teile und teilt den Sub-Agenten die Grenze mit:

• Global (Wiederverwendung, nicht hier gebaut): Skills / MCP / Sub-Agenten, die für alle Ihre Projekte gemeinsam genutzt werden (eine Nachrichtenübermittlungsfähigkeit, ein Bildgenerator, ein Rechercheassistent, verschiedene Operator-Agenten). Rufen Sie sie direkt auf, null Baukosten.
• Lokal (für dieses Projekt gebaut/geforkt): die projektspezifische CLI, Projekt-Skills, Projekt-Sub-Agenten.
• ⚠️ Gültigkeitsbereichsfalle: Ein Skill, der auf das Verzeichnis eines anderen Projekts beschränkt ist, wird hier nicht automatisch geladen; forken Sie eine gekürzte Kopie oder rufen Sie das globale Äquivalent auf. Geben Sie dies in der generierten Verfassung an.

Philosophie 6 · Reflexion & Selbstiteration ist immer der letzte Schritt – und es gibt zwei Schleifen

Das Gerüst jeder Pipeline endet mit Reflexion & Selbstiteration: Überprüfen Sie die Fehler und Effizienz dieses Zyklus → attribuieren Sie Grundursachen → senden Sie den Wartungsagenten, um den Prozess zu verbessern → konsolidieren Sie. Das Ziel ist es, stetig „noch im laufenden Betrieb entschieden“ in „jetzt in eine deterministische Funktion eingefroren“ zu verwandeln. Keine Selbstiterationsprüfung = die Schleife wurde nicht geschlossen. Es gibt zwei unterschiedliche Schleifen; die Verfassung muss sie getrennt halten:

• Schleife A – Reflexion pro Zyklus (am Ende jedes Pipeline-Durchlaufs) → schreiben Sie in reflections/ (permanent; niemals in einem Build-Verzeichnis, das bereinigt wird).
• Schleife B – Asynchrone Überprüfung zwischen den Sitzungen: Ein geplanter Job schreibt einen Daten-/Analysebericht in reports/; das Startritual der nächsten Sitzung scannt reports/, übernimmt/verwirft und archiviert. Plus eine HANDOFF-Notiz trägt unerledigte Geschäfte zwischen den Sitzungen weiter.

Philosophie 7 · Verfassung-als-Code: Ein deterministischer Selbstcheck hält Behauptungen == Realität

Eine Verfassung driftet: Sie behauptet „9 Sub-Agenten, 7 Skills“, während das Dateisystem etwas anderes sagt. Daher liefert jedes Projekt einen deterministischen doctor/Konsistenz-Lint-Befehl, der prüft, was die Dokumente behaupten gegen das, was tatsächlich existiert (Agenten, Skills, CLI-Befehle, Asset-Anzahl, die Lebenslinien-Datenbank) und bei Abweichung mit Nicht-Null beendet. Dies ist der maschinelle Rückhalt für die „Ausbreitungskonsistenz“-Regel: Jede Blattänderung (CLI/Skill/SP/Vorlage) muss, bevor sie abgeschlossen ist, die Verträge der oberen Schichten erneut bestätigen – und doctor setzt dies mechanisch durch.

Philosophie 8 · Standardform (Wurzelverfassung + Dokumentation/)

Der Projektordner hat von Geburt an eine feste Form:

<Projekt>/
├── CLAUDE.md              ← Verfassung: Prinzipien / Gerüst / Hinweise / Karte (im Kontext resident)
├── documentation/         ← jede Einzelquelle der Wahrheit / Allgemeinwissen / Konfiguration (bei Bedarf geladen)
│   ├── configuration.json      Markenstrukturierte Konfiguration (einzelne Quelle der Wahrheit)
│   ├── INITIALIZATION.md       einmaliges Ersteinrichtungs-Setup
│   ├── reflection_playbook.md  die Schritt-für-Schritt-Anleitung für den Reflexionsschritt
│   ├── <playbook>.md           Themen-Playbooks (Qualitätstor / Themen-SOP / Compliance / …)
│   └── …
├── .claude/agents/        ← Sub-Agenten-System-Prompts (Rollendefinitionen)
├── .claude/skills/        ← jede SKILL.md (Fähigkeitsdefinitionen)
├── <core>.py / <core>/    ← deterministischer CLI-Code (ausgeführt, nie im Kontext)
├── reflections/           ← Reflexionsberichte pro Zyklus (permanent)
├── reports/               ← asynchrone Daten-/Analyseberichte (bei Sitzungsbeginn verbraucht)
├── HANDOFF.md             ← sitzungsübergreifende Übergabe unerledigter Arbeit
├── CHANGELOG.md
└── <lebenslinie>.db       ← der Lebenslinien-Speicher (gitignoriert)

---

B. Was ein Durchlauf dieser Fähigkeit liefert

Liefergegenstand	Pfad	Inhalt
Projektverfassung	<Projekt>/CLAUDE.md	Ausgefüllt aus templates/CLAUDE.md.template (schlank, hinweisbasiert).
Markenkonfiguration	<Projekt>/documentation/configuration.json	Ausgefüllt aus templates/configuration.json.template.
Initialisierungsdokument	<Projekt>/documentation/INITIALIZATION.md	Credential-Checkliste + einmalige Bereitstellungsschritte (Gerüst).
Einzelquellen-Dokumente zu Themen	<Projekt>/documentation/<Thema>.md	Die im Interview identifizierten Regeln, die nicht in die Verfassung gehören (eine Datei pro Thema).
Leere Skelette	.claude/agents/, .claude/skills/, reflections/, reports/, HANDOFF.md	Erstellen Sie Verzeichnisse + einen .gitkeep- oder README-Platzhalter pro Verzeichnis.

Nicht generiert: Geschäftslogik, echte Sub-Agenten-SP-Inhalte, echte Skill-Implementierungen – diese wachsen, nachdem das Projekt existiert. Diese Fähigkeit erzeugt nur die Registrierungen + Gerüst + Platzhalter und registriert im Voraus, welche Rollen und Fähigkeiten existieren sollen, in CLAUDE.md.

---

C. Interaktionsprotokoll (das Aufnahmeinterview)

Führen Sie das Interview durch, bevor Sie generieren. Fragen Sie in Runden; bieten Sie nach Möglichkeit Multiple-Choice-Optionen an, um die Eingabe des Benutzers zu minimieren. Bestätigen Sie nach jeder Runde die Antwort, indem Sie sie zurückgeben, und fahren Sie dann fort. Ziel: jeden {{Platzhalter}} in den Vorlagen auszufüllen.

Effizienzregeln für den Interviewer:

• Das CEO-Modell, die fünf/sechs Kernregeln und die Vier-Schichten-Architektur sind Konstanten für alle Projekte – fragen Sie nicht danach; sie kommen bereits ausgefüllt aus der Vorlage.
• Für globale Fähigkeiten untersuchen Sie zuerst automatisch die Host-Umgebung (inspizieren Sie die verfügbaren Skills / Sub-Agenten-Typen / MCP-Server, die Ihre Laufzeit bereitstellt) und schlagen Sie eine Wiederverwendungsliste vor, die der Benutzer bestätigen oder kürzen kann – bitten Sie den Benutzer nicht, sie aus dem Gedächtnis abzurufen.
• Bündeln Sie verwandte Fragen (bis zu ~4 auf einmal). Ziel ist es, in 3–4 Runden fertig zu werden, nicht in 7.

Runde 0 · Projektarchetyp (wählt den Pipeline-Vorlagenzweig aus)

Fragen Sie, welchen Archetyp das Projekt hat; jeder lädt einen anderen Gerüstentwurf vor:

Archetyp	Typisches Gerüst (vorab geladener Entwurf, dann mit dem Benutzer abstimmen)
Content – Video/Kanal	Thema → Skript → Rendern → Veröffentlichen → Engagement/Kommentare → Reflektieren
Content – eBook/Verlag	These → Schreiben → Kompilieren → Multi-Kanal-Verteilung → Marketing → Optimieren → Reflektieren
SEO-Traffic-Asset (Tool-Seite/Wiki)	Thema → Bauen → Versenden → Monetarisieren → SEO/Überwachen → Reflektieren
Web-Produkt/Website	Anforderungen → Design → Bauen → Testen → Bereitstellen → Überwachen → Reflektieren
Gelegenheitsspiel	Konzept → Asset-Produktion (starke Batch-Parallelität) → Bauen → Testen → Veröffentlichen → Daten-Abstimmen → Reflektieren
Andere (benutzerdefiniert)	Entwickeln Sie die Schritt-für-Schritt-Anleitung von Grund auf gemeinsam

Runde 1 · Mission, Nordstern und rote Linien

• Ein-Satz-Mission (wird der Nordstern des CEO).
• 3–5 prioritätsgeordnete nicht verhandelbare Einschränkungen (frühe überschreibt immer spätere). Führen Sie den Benutzer dazu, die Kette zu durchdenken (z. B. „Kontosicherheit > Inhaltsqualität > Quantität > Geschwindigkeit > Umsatz pro Einheit“).
• Die #1 eiserne Regel / Compliance-rote Linie, falls vorhanden („verletzen Sie sie und alles ist verschwendet“ – z. B. Plattform-Anti-Spam, Marktplatz-Anti-KI-Schrott, ToS).
• Verbote (zwei Stufen): was Verboten ist (rote-Linien-Aktionen, die das gesamte Projekt ungültig machen können) vs. Abgeraten (vermeiden, es sei denn, es ist gerechtfertigt). Diese füllen den Verbote-Abschnitt der Vorlage, parallel zu den Regeln.

Runde 2 · Marke (→ configuration.json)

• Marke/Codename? Zuordnungseinheit (echter Name? Pseudonym? Unternehmen)? Pro Sprache?
• Slogan / Claims?
• Logo-Assets (vorhanden)?
• Designsprache: Primärfarben, Schriftarten, Ton-Schlüsselwörter, visueller Stil, Tabus.
• Vertrauensanker / E-E-A-T-Anker (Website / Autorenidentität)?
• Zahlungs-/Konteneinheit (falls monetarisiert)?

Runde 3 · Pipeline-Gerüst (Schritt für Schritt)

• Ausgehend vom Archetyp-Entwurf nageln Sie jeden Schritt fest: was er tut → seine Ausgabe → die federführende Rolle.
• Markieren Sie welche Schritte parallel ausgeführt werden können (die Ausfächerungspunkte).
• Bestätigen Sie, dass der letzte Schritt = Reflexion & Selbstiteration ist.

Runde 4 · Rollen (Sub-Agenten-Aufteilung) + globale/lokale Fähigkeiten

• Ein Sub-Agent pro festem Schritt: Name + einzeilige Rolle + welcher Schritt.
• Es muss immer einen dev-maintainer (Eigentümer aller Code/SP/Skill-Änderungen) geben.
• Wenden Sie die Anti-Proliferationsregel an: bevorzugen Sie einen gemeinsamen Wartungsagenten, es sei denn, ein Artefakt hat unterschiedliche Abhängigkeiten.
• Bestätigen Sie die automatisch untersuchte globale Wiederverwendungsliste; listen Sie die lokalen Skills auf, die gebaut/geforkt werden sollen – und für jeden lokalen Skill, welche MCP-Server und welche CLI-Befehle er verwendet (Philosophie 3, Schicht ③).
• Geben Sie für jeden Sub-Agenten an, welche Skills er hauptsächlich verwenden soll (der Hinweis in seinem SP).

Runde 5 · Lebenslinien-Speicher + Einzelquellen-Dokumente + Phase/Credentials

• Welchen Langzeitspeicher benötigt das Projekt (Asset-Portfolio-DB / Dedup-Vektor-Store / Fortschrittsledger…)? Welche Felder?
• Welche Regeln sind „Einzelquelle der Wahrheit“ und sollten jeweils eine documentation/<Thema>.md werden? (Compliance, Themen-SOP, Qualitätstor, Preisgestaltung, Hochfahrdisziplin…) Registrieren Sie jede.
• Aktuelle Phase? Hochfahrt-Kadenz / Risikodisziplin?
• Welche privaten Credentials / externen Konten muss der Benutzer bereitstellen (→ INITIALIZATION.md)?
• Die Grenze für „nur zwei Gründe, anzuhalten und den Benutzer zu fragen“ (fehlendes Credential / subjektives Geschäftsentscheidung).

Wenn das Interview abgeschlossen ist, geben Sie jedes ausgefüllte Schlüsselfeld zurück und bestätigen Sie, bevor Sie Dateien schreiben.

---

D. Generierungsregeln

1. Kopieren Sie templates/CLAUDE.md.template, ersetzen Sie jedes {{…}}, löschen Sie optionale Abschnitte, die nicht …

… [für die Übersetzung gekürzt]