Prometheus

Was macht Prometheus?

Ein allgemeines Meta-Prompting-Framework zum Erstellen von Prompts für LLM-Agenten. Funktioniert mit jeder agentischen CLI (Claude Code, Gemini CLI, Cursor, andere) und für die nicht-CLI-Nutzung. Deckt alle sieben Prompt-Formen ab: agentische Schleifen, einmalige Aufgaben, Workflow-Ketten, Sub-Agent-Prompts, System-Personas, LLM-als-Richter-Bewerter und Agenten-Teams.

Das Framework basiert auf klassischem Kontext-Engineering (Anthropics „richtige Höhe“, „kleinster tragfähiger Token-Satz“, „Beispiele vor Regeln“) und auf quantensemantischen Prinzipien (Prompts sind Operatoren, keine Schlüsselfinder; Reihenfolge ist strukturell; Mehrdeutigkeit ist ein Feature; Kombination ist nicht-additiv).

Wann diese Fähigkeit verwendet werden soll

Auslösen, wenn der Benutzer mit einer Prompt-Entwurfsarbeit für einen LLM-Agenten beginnt. Häufige Formulierungen:

• „Hilf mir, einen Prompt für [Aufgabe] zu schreiben“
• „Ich brauche einen System-Prompt für [Zweck]“
• „Richte mir einen [Claude Code / Gemini CLI / etc.]-Prompt für [Projekt] ein“
• „Entwirf einen LLM-als-Richter-Prompt für [Bewertung]“
• „Ich baue einen Sub-Agenten, der [X] macht, hilf mir, seine Anweisungen zu schreiben“
• „Starte eine agentische Schleife für [Aufgabe]“

Nicht auslösen für: einfache Frage-Antwort, Code-Vervollständigungsanfragen oder Aufgaben, bei denen der Benutzer die Antwort möchte, nicht einen Prompt, um die Antwort später zu erhalten.

Kernhaltung: Prompts sind Operatoren

Die tiefste Neuausrichtung, auf der dieses Framework ruht, aus der quantensemantischen Literatur: Ein Prompt „extrahiert“ nicht die richtige Antwort aus einem Modell. Ein Prompt ist ein Operator, der eine Antwort durch Transformation des semantischen Zustands des Modells konstruiert. Jeder Abschnitt eines Prompts ist eine Matrix, die bestimmte Interpretationen verstärkt, andere unterdrückt, Basiszustände mischt, um neuartige Lesarten zu erzeugen.

Dies ist keine Metapher. Es ändert die Entwurfspraxis:

• Wir „finden nicht die richtigen Schlüsselwörter“ – wir entwerfen Transformationen.
• Reihenfolge ist strukturell – Operatoren kommutieren nicht.
• Das Kombinieren von Abschnitten erzeugt Interferenz, keine Addition.
• Jede Anweisung zerstört Information; entwerfen Sie entsprechend.
• Mehrdeutigkeit in der Benutzerabsicht ist eine Überlagerung, kein zu beseitigender Fehler.

Die Fähigkeit wendet diese Prinzipien konkret an, nicht als Beiwerk. Siehe references/quantum-principles.md für die operative Abbildung und operators/ für den Abschnitt-als-Operator-Katalog.

Drei Betriebsmodi

Das Framework arbeitet in einem von drei Modi, abhängig davon, was der Benutzer mitbringt:

Von-Grund-auf-Modus (Standard). Der Benutzer beschreibt eine Aufgabe; das Framework erzeugt einen Prompt. Sechs Phasen: Forminferenz → adaptive Befragung → Operator-Design-Entwurf → Prüfung → ehrliche Bewertung → Auslieferung.

Refactoring-Modus. Der Benutzer hat einen vorhandenen Prompt und möchte ihn prüfen, reparieren oder umschreiben. Sechs Phasen (1R bis 6R): Empfangen und Parsen → Absichtswiederherstellungs-Befragung → Modusauswahl (Prüfung / gezieltes Refactoring / vollständiges Umschreiben) → Anwenden des Modus → ehrliche Bewertung → Auslieferung. Vollständige Vorgehensweise dokumentiert in references/refactor-mode.md.

Verwaltungsmodus. Der Benutzer zeigt auf ein vorhandenes verwaltetes Agentenpaket und möchte es über seine Lebensdauer hinweg betreiben – seine Ausführungen überwachen, eine Zielverletzung analysieren, es anpassen, es anhalten und mit demselben inneren Zustand neu starten. Dies ist das Framework als Agenten-Manager, nicht nur als Designer: eine MAPE-K-Schleife (Monitor / Analyze / Plan / Execute) über den Prompt des Agenten, ausgedrückt durch die Operatoralgebra. Vollständige Vorgehensweise in references/manage-mode.md; Paketlayout, Lebenszyklus und Ledger in references/agent-state.md.

Moduserkennung. Erkennen Sie den Refactoring-Modus automatisch, wenn die Eröffnungsnachricht des Benutzers einen eingefügten Prompt enthält, gefolgt von einer Aufforderung zur Prüfung, Verbesserung, Reparatur oder zum Refactoring. Direkte Aufrufe wie „Refaktoriere diesen Prompt“, „Prüfe diesen Prompt“, „Was ist falsch an diesem Prompt“ lösen sofort den Refactoring-Modus aus. Erkennen Sie den Verwaltungsmodus automatisch, wenn der Benutzer auf einen vorhandenen Agentenpaketpfad zeigt oder ein Lebenszyklusverb dagegen aufruft – „Verwalte diesen Agenten“, „Führe einen Anpassungszyklus durch“, „Warum hat mein Agent sich verschlechtert?“, „Starte meinen Agenten neu.“ Wenn die Erkennung mehrdeutig ist (ein Prompt wird eingefügt, aber die Anfrage ist unklar), fragen Sie einmal: „Ich sehe einen Prompt – möchten Sie, dass ich ihn refaktoriere, oder haben Sie ihn als Kontext für eine andere Aufgabe verwendet?“ Standardmäßig wird der Von-Grund-auf-Modus verwendet, es sei denn, die Signale für Refactoring oder Verwaltung sind klar.

Die drei Modi teilen die Infrastruktur (den Formkatalog, den Operator-Katalog, die Prüfliste, die Verifiziererspezifikationen), führen aber unterschiedliche Vorgehensweisen aus. Der Verwaltungsmodus insbesondere verwendet die Von-Grund-auf- und Refactoring-Mechanismen als Unterprogramme wieder (die Prüfliste, die Refactoring-Untermodi, der ausführungsübergreifende Verifizierer), anstatt neue analytische Mechanismen hinzuzufügen. Die Von-Grund-auf-Vorgehensweise folgt; die Refactoring-Vorgehensweise ist in references/refactor-mode.md; die Verwaltungsvorgehensweise ist in references/manage-mode.md.

Von-Grund-auf-Vorgehensweise (sechs Phasen)

Phase 1 – Forminferenz, kein Routing

Die Aufgabenbeschreibung des Benutzers kommt als semantischer Zustand in Überlagerung an. Stellen Sie keine Routing-Frage. Inferieren Sie die Form aus den bereits vorhandenen Signalen, im Geiste von §2.4 Bayesianisches Sampling.

1. Lesen Sie die Anfrage des Benutzers sorgfältig. Extrahieren Sie Signale: Verben (bauen / entwerfen / klassifizieren / benoten / bewerten / extrahieren / zusammenfassen), Substantive (System / Dokument / Pipeline / Schleife / Agent / Persona / Richter), Skalenmarker (einmalig vs. fortlaufend, mehrfach vs. einzelner Aufruf) und Tool-Erwähnungen (Claude Code, Gemini CLI, etc.).

2. Generieren Sie eine interne A-posteriori-Verteilung über plausible Formen. Der Formkatalog befindet sich in templates/shape-catalog.md. Legen Sie sich noch nicht fest – behalten Sie Gewichte bei.

3. Wählen Sie die Form mit der höchsten A-posteriori-Masse nur, wenn die zweitplatzierte Form deutlich zurückliegt. Wenn zwei oder mehr Formen innerhalb von ~30 % voneinander liegen, ist die Inferenz mehrdeutig und Sie sollten mittels einer gezielten Klärungsfrage disambiguieren. Formulieren Sie es als erzwungene Wahl zwischen den beiden obersten Formen, nicht als offene Routing-Frage.

4. Domäne (Engineering / Forschung / Schreiben / Betrieb / generisch) ist eine sekundäre Achse, orthogonal zur Form. Inferieren Sie sie auf die gleiche Weise. Ein einmaliger Schreib-Prompt und ein agentischer Engineering-Prompt wenden beide dieses Framework an, nur mit unterschiedlichem Abschnittsinhalt.

5. Erkennen Sie Signale für harte Argumentation während desselben Durchlaufs. Mathematische / logische Aufgaben, mehrschrittige Planung, Code-Analyse oder Debugging, Probleme mit mehreren Einschränkungen oder jede Aufgabe, bei der der Benutzer erwähnt, dass das Modell beim ersten Versuch versagt, sind Signale, dass das kognitive-Werkzeuge-Gerüst (gemäß references/reasoning-patterns.md) eine strukturelle Voreinstellung beim Entwurf sein sollte, keine optionale Erweiterung. Zwei oder mehr Signale + Tool-Aufruf-Laufzeit → das Gerüst auf Legacy- und Strong-Tiers einschließen, wo das zitierte empirische Ergebnis zutrifft. Auf dem Frontier-Tier ist das Gerüst eine durch M5 ausgelöste Option, keine Voreinstellung – siehe references/reasoning-patterns.md §Tier-Gating.

6. Inferieren Sie die Substrat-Fähigkeitsstufe – eine dritte Achse, orthogonal zu Form und Domäne, aus der Laufzeitantwort gelesen: Frontier (die neuesten Modelle der Laufzeit mit hoher Befolgungsfähigkeit), Strong (aktuelle Mainstream-Modelle), Legacy (ältere oder kleinere Modelle). Unbekannt → Strong annehmen. Tier-Bedingungen: Standard-Operatorstärke in Phase 3 (Prinzip 9 in references/quantum-principles.md – vorschreibende Operatoren überprojizieren auf Substraten mit hoher Befolgungsfähigkeit), Gerüstauslöseschwellen (Punkt 5 oben), Prefill-Verfügbarkeit und Reasoning-Control-Parameter-Hinweise in Phase 6.

Phase 2 – Adaptive Befragung (operatorbewusst)

Die Befragung ist selbst eine Sequenz von Operatoren, die auf die Absicht des Benutzers angewendet werden. Gemäß §5.6 kollabiert jede Frage unwiderruflich Mehrdeutigkeit. Kollabieren Sie nicht zu schnell.

Durchführungsregeln:

• Obergrenze von insgesamt 6 flachen Fragen, einschließlich aller Disambiguierungsfragen aus Phase 1 (3 universelle – Einsatzumgebung überspringbar, wenn offensichtlich – plus 2–3 formspezifische). Harte Obergrenze. Co-Authoring-Durchläufe (Formen 3, 6, 7) sind gemäß den Durchführungsregeln von templates/interview-branches.md ausgenommen.
• Eine Frage pro Zug. Züge mit mehreren Fragen erzeugen flachere Antworten.
• Überspringen Sie Fragen, deren Antworten bereits in der Anfrage des Benutzers enthalten sind. Wiederholtes Fragen ist informationszerstörende Wiederholung.
• Die Reihenfolge der Fragen ist wichtig (§2.3, §5.1). Stellen Sie zuerst die breiteste Rahmenfrage, dann die einschränkenden Einschränkungen, zuletzt das Format. Die erste Frage legt den Unterraum fest, in dem alle späteren Fragen operieren.
• Bewahren Sie Überlagerung, wo die Kosten des Fragens niedrig und die Kosten eines Fehlers hoch sind (§4.1). Für architekturelle Entscheidungen (Form, Zielgruppe, Tool) bewahren. Für taktische Entscheidungen (Dateiname, Groß-/Kleinschreibung) standardmäßig vorgehen und weitermachen.

Fragenbänke pro Form befinden sich in templates/interview-branches.md. Zwei Fragen sind universell über alle Formen hinweg:

1. Tool / Laufzeit. „Wo wird dieser Prompt ausgeführt? (Claude Code, Gemini CLI, OpenAI API, generisches LLM, anderes?)“ Beeinflusst die Benennung von Gedächtnisdateien und toolspezifische Angebote.
2. Erledigungsdefinition / Erfolgskriterium. „Woher wirst du wissen, dass der Prompt funktioniert hat? Sei überprüfbar, nicht bauchgefühlbasiert.“ Liefert die Bewertungsmatrix für die Selbstevaluation in Phase 5.

Beenden Sie die Befragung mit einer Zusammenfassungs-Kollaps: Geben Sie die von Ihnen inferierte Form, die von Ihnen gesammelten Schlüsseleinschränkungen und die Voreinstellungen an, die Sie für alles Nicht-Spezifizierte zuweisen. Geben Sie dem Benutzer eine Chance zum Widerspruch vor dem Entwurf. Dies ist der bewusste Messschritt (§1.2) – machen Sie ihn explizit, damit der Benutzer dem Kollaps widersprechen kann.

Phase 3 – Operator-Design-Entwurf

Entwurf ist Operatordesign (§5.3), nicht Abschnittsfüllen. Für jeden von Ihnen eingeschlossenen Abschnitt:

1. Identifizieren Sie die Basiszustände, die der Abschnitt transformiert – welche Interpretationen sollten verstärkt, unterdrückt oder gemischt werden?
2. Wählen Sie die Stärke – starke Operatoren (Persona, harte Einschränkungen) projizieren aggressiv; schwache Operatoren (Stilpräferenzen, Formatierung) kommutieren mit den meisten anderen. Kalibrieren Sie die Standardstärke auf die Substratstufe (Prinzip 9): Auf der Frontier-Stufe bevorzugen Sie kurze allgemeine Anweisungen gegenüber Aufzählungen und reservieren Sie Intensitätssprache („KRITISCH“, „MUSS“, wiederholte Verbote) für Einschränkungen mit nachgewiesenen Fehlermodi; auf Legacy-Stufen ist eine stärkere Projektion oft gerechtfertigt. Die Fähigkeitssperre für Rollen mit destruktiven Fähigkeiten bleibt auf jeder Stufe geschichtet und laut – ihre Rechtfertigung ist Risiko, nicht Substratschwäche.
3. Platzieren Sie in der Operatorsequenz gemäß §5.1: breiteste Rahmung zuerst, einschränkend als nächstes, Format zuletzt.
4. Prüfen Sie auf Interferenz mit benachbarten Abschnitten (§5.4) – erzeugt die Kombination emergentes Verhalten, beabsichtigt oder nicht?

Verwenden Sie templates/shape-catalog.md für formspezifische Grundgerüste. Verwenden Sie operators/ für die abschnittsweisen Operatorbeschreibungen (was jeder Abschnitt verstärkt, unterdrückt, mischt; seine Stärke; seine Kommutierungseigenschaften). Für Aufgaben, die keine vollständige Formauswahl rechtfertigen (klein, wohldefiniert, einzigartig), ist templates/minimum-viable-prompt.yaml das Fallback-Gerüst – sechs Slots (System / Anweisungen / Beispiele / Einschränkungen / Zustand / Abfrage) und nichts weiter.

Für argumentationsintensive Aufgaben, bei denen strukturierte Dekomposition monolithische Gedankenketten übertrifft, konsultieren Sie references/reasoning-patterns.md – es dokumentiert das kognitive-Werkzeuge-Untermuster (IBM Zürich, +16,6 % auf AIME2024) und wann es innerhalb der gewählten Form aufgerufen werden soll.

Wenn die Ausgabe des Prompts von einem anderen LLM-Agenten konsumiert wird und nicht einem Menschen angezeigt wird (am häufigsten in Form-4-Sub-Agent/Tool-Prompts und Form-6-LLM-als-Richter), konsultieren Sie references/agent-consumability.md. Das Ausgabedesign ändert sich, wenn der Konsument ein Agent ist: greppbare Fehlermarker, aggregat-zuerst-Struktur, kompaktes Stdout mit ausführlichen Logs, deterministisches-aber-abweichendes Sampling und sichtbare Zustandsübergänge.

Für Form 7 (Agententeam) ist die Topologieentscheidung grundlegend und muss der rollenspezifischen Erstellung vorausgehen. Konsultieren Sie references/agent-team-topologies.md für die vier kanonischen Topologien (Orchestrator-Worker, Parallelisierung-Sektionierung, Parallelisierung-Abstimmung, Evaluator-Optimierer) mit ihren Operatorprofilen, Rollendefinitionen und häufigen Fehlermodi. Wählen Sie zuerst die Topologie, erstellen Sie dann den Prompt jeder Rolle mit ihrem individuellen Formgrundgerüst und prüfen Sie dann die rollenübergreifende Kohärenz.

Universelle Entwurfsregeln gelten für alle Formen:

• Richtige Höhe. Spezifisch genug zum Handeln, flexibel genug, damit das Modell sich anpassen kann. Spröde Hartcodierung und vage Handbewegungen sind duale Fehlermodi.
• Kleinster tragfähiger Token-Satz. Entfernen Sie alles, was keinen bestimmten Fehlermodus adressiert oder ein konkretes Verhalten ermöglicht. Jeder Token kostet Aufmerksamkeit.
• Beispiele vor Regeln. Wenn eine Regel tragend ist, schreiben Sie ein ausgearbeitetes Beispiel. Beispiele sind tragende Operatoren, die abstrakte Anweisungen verankern. Aber Beispiele haben ihre eigene Mehrdeutigkeitsoberfläche – jeder stille Werturteil innerhalb eines Beispiels wird zu einer Regel, die das Modell zurückentwickelt. Fragen Sie vor dem Ausliefern eines Beispiels: Was lehrt dieses Beispiel stillschweigend über das hinaus, was ich beabsichtigt habe? Wenn Sie unsicher sind, ersetzen Sie es durch einen saubereren Fall.
• Abschnittsreihenfolge nach Operatorstärke. Stärkste Operatoren zuerst.
• Fehlermodi als VERBOTE. Jeder adressiert eine bestimmte bekannte scharfe Kante mit konkreter Konsequenz. Allgemeine Warnungen verschwenden Tokens.

Phase 4 – Prüfung (strukturell und quantenmechanisch)

Führen Sie die Prüfliste in references/audit-checklist.md aus. Die Prüfliste kombiniert klassische Kontext-Engineering-Prüfungen (richtige Höhe, kleinster Token-Satz, Beispiele vorhanden, Haltbarkeit der Langzeithorizont-Unterstützung) mit quantensemantischen Prüfungen:

• Operatorkatalog vollständig. Jeder Abschnitt hat ein klares Verstärkungs-/Unterdrückungs-/Mischungsprofil. Kein Abschnitt ist „Dekoration“.
• Reihenfolge optimiert. Stärkste Operatoren zuerst. Testen Sie, indem Sie benachbarte Abschnitte gedanklich vertauschen und fragen: „Ändert dies das Verhalten?“ Wenn ja, haben Sie nicht-kommutierende Paare korrekt identifiziert.
• Interferenz geprüft. Wenn zwei Abschnitte wahrscheinlich interagieren (z. B. Persona + Ton + Format), bestätigen Sie, dass die Kombination das beabsichtigte emergente Verhalten erzeugt, nicht unerwünschte Auslöschung.
• Informationserhaltung. Wichtiger Kontext wird so früh wie möglich geladen (er überlebt mehr Projektionen). Dinge, die mehrdeutig bleiben sollten, werden als solche gekennzeichnet, nicht vorschnell kollabiert.
• Messbewusst. Wenn der Prompt ein Bewertungskriterium enthält (z. B. LLM-als-Richter), stellen Sie sicher, dass das Kriterium so definiert ist, dass es die Antwort des Modells nicht unzulässig beeinflusst.

Phase 5 – Ehrliche Bewertung

Bewerten Sie Ihren Entwurf anhand derselben Kriterien, die Sie dem Benutzer in Phase 2 entlockt haben. Wenn Sie keine klaren Erfolgskriterien haben, fragen Sie sich: „Würde ich diesen Prompt verwenden, um die beschriebene Aufgabe zu erledigen? Wenn nicht, warum?“

Bewerten Sie ehrlich. Wenn der Prompt nicht funktionieren wird (unwahrscheinlich, zu vage, fehlende Kontextverwaltung für eine agentische Schleife), sagen Sie es. Bieten Sie einen überarbeiteten Entwurf oder eine explizite Einschränkung an: „Dieser Prompt wird wahrscheinlich für Aufgaben scheitern, die [X] beinhalten. Verwenden Sie ihn für [Y].“

Für Form 6 (LLM-als-Richter) umfasst die Bewertung einen Verifizierer. Das Framework liefert einen Verifizierer, der die Ausgaben des Prompts validiert. Siehe templates/verifier.json für das Schema.

Phase 6 – Auslieferung und toolbewusste Formatierung

Der letzte Schritt transformiert den entworfenen Prompt in ein auslieferbares Artefakt. Die Transformation ist selbst eine Operatorsequenz.

1. Wählen Sie das Ausgabeformat basierend auf dem in Phase 2 identifizierten Tool/der Laufzeit. Dies ist nicht nur Kosmetik – Tools wie Claude Code erwarten Prompts in CLAUDE.md; Gemini CLI hat möglicherweise andere Konventionen; API-orientierte Prompts könnten einen JSON-Block benötigen.
2. Wenden Sie toolspezifische Formatierung an. Fügen Sie bei Bedarf Konfigurationseinträge hinzu (z. B. [claude config] für Claude Code).
3. Dokumentieren Sie Einschränkungen. Fügen Sie einen sichtbaren Abschnitt hinzu, der dokumentiert, wofür dieser Prompt ausgelegt ist und wo er bekanntermaßen scheitert.
4. Geben Sie einen initialen Testplan. Was ist der minimale Validierungslauf? (Eine einmalige Ausführung? Ein 3-Schritte-Durchlauf?) Wie erkennt der Benutzer einen Fehler?

Das ausgelieferte Artefakt ist nicht „der Prompt“ – es ist ein Prompt eingebettet in seine Betriebsdokumentation: eine selbstdokumentierende, testbare, begrenzte Operatorspezifikation.

Auswirkungen auf die Zusammenarbeit

Die Standard-Durchführungsregeln für Phase 2 erlauben Co-Authoring-Durchläufe für: (3) Workflow-Ketten – insbesondere wenn die Kette Eingabe-/Ausgabeschemata zwischen Schritten umfasst, (6) LLM-als-Richter-Prompts – der Benutzer hat möglicherweise domänenspezifische Bewertungskriterien im Kopf, die nicht offensichtlich sind, und (7) Agententeam-Prompts – Topologie und Rollen erfordern häufige Iteration.

Wenn in Phase 1 die Aufteilung der Benutzerarbeit am Prompt ≥ 50 % beträgt (d. h. der Benutzer entwirft die Hälfte der Abschnitte), behandeln Sie den Durchlauf als Co-Authoring. Der Benutzer entwirft Abschnitte; das Framework prüft sie gegen die Prüfliste und macht Vorschläge. Das Framework schreibt niemals einen Abschnitt um, den der Benutzer geschrieben hat, ohne zu fragen.

Konfiguration

Abhängig von Ihrem Agenten-CLI/Tool können Sie diese Konfigurationseinträge hinzufügen:

# Claude Code
[claude config]
tools = ["Read", "Write", "Edit", "Bash", "Glob"]

# Gemini CLI
[gemini config]
enable_code_execution = true

Verweise

Dieses Framework verlässt sich auf eine Reihe von Referenzdokumenten, die tiefere Details, Verfahren und Kataloge enthalten. Jedes ist vom Hauptframework aus über seinen Dateipfad verlinkt (wobei angenommen wird, dass die Dateien im selben Skill-Repository vorhanden sind):

• references/quantum-principles.md – Die betriebliche Abbildung der quantensemantischen Prinzipien auf die Prompt-Design-Praxis. Enthält die 10 Prinzipien, die Operatorsequenzalgebra und eine formale Definition von Projektionsoperatoren.
• references/audit-checklist.md – Die vollständige Prüfliste, die in Phase 4 verwendet wird. Hebt die Checkliste aus dem Hauptdokument in eine ausführbare Referenz.
• references/refactor-mode.md – Die vollständige 6-phasige Vorgehensweise zum Refactoring bestehender Prompts. Enthält Absichtswiederherstellungsproben, Modusauswahlbäume und Auslieferungsformate.
• references/manage-mode.md – Das vollständige MAPE-K-Verfahren (Monitor / Analyze / Plan / Execute) zum Verwalten eines laufenden Agenten über die Operatoralgebra. Erfordert das Agentenpaket-Setup aus references/agent-state.md.
• references/agent-state.md – Paketlayout, Lebenszyklus-Ledger und Zustandsverwaltungs-Datenschemata für den Verwaltungsmodus.
• references/reasoning-patterns.md – Das kognitive-Werkzeuge-Muster (IBM Zürich, +16,6 % auf AIME2024) und die Tier-Gating-Regeln dafür.
• references/agent-consumability.md – Ausgabedesign-Änderungen, wenn der Prompt-Konsument ein LLM-Agent und kein Mensch ist.
• references/agent-team-topologies.md – Die vier kanonischen Teamtopologien mit Operatorprofilen, Rollendefinitionen und häufigen Fehlermodi.
• templates/shape-catalog.md – Die sieben Prompt-Formen mit ihren Operatorsequenzen, typischen Abschnitten und häufigen Variationen.
• templates/interview-branches.md – Fragenbänke, geordnet nach Form, mit Durchführungsregeln.
• templates/verifier.json – Das Schema für den LLM-als-Richter-Verifizierer.
• templates/minimum-viable-prompt.yaml – Das Fallback-Gerüst mit sechs Slots.
• operators/ – Verzeichnis mit abschnittsweisen Operatorbeschreibungen.