Spezifikationsgestütztes Dokumentenverfassen: Warum es einfaches ChatGPT übertrifft

Komplexe, regulierte Dokumente – Richtlinien, Kontrollnarrative, CAPA-Berichte, Genehmigungspakete – mit einer generischen Chat-Oberfläche zu verfassen, ist verlockend: Sie fügen einen Prompt ein und erhalten einen Entwurf. Das Problem sind Konsistenz, Struktur und Konformität. Einmalige Prompts erzwingen keine Workflows, führen keine Prüfungen durch und geben dem Modell keine Möglichkeit zur Selbstkorrektur. Spezifikationsgestütztes Dokumentenverfassen in Rakenne kehrt das um: Skills definieren Workflows, laden Referenzen und nutzen Extension-Tools, damit der Agent validieren, korrigieren und die Qualität sichern kann. Dieser Artikel erklärt, warum dieser Ansatz „normalem Prompting in ChatGPT“ deutlich überlegen ist, und zeigt konkrete Beispiele sowie Ergebnisvergleiche.

Warum spezifikationsgestützt besser ist als Ad-hoc-Prompting

Kurz: Spezifikationsgestütztes Verfassen gibt dem LLM eine Spezifikation (Workflow + Referenzen + Struktur) und Werkzeuge (Extensions) zum Prüfen und Korrigieren. Einfaches Prompting nicht.

Wie Rakenne-Skills spezifikationsgestütztes Verfassen umsetzen

In Rakenne ist jeder Skill ein kleines Paket, das der Pi-Agent auslösen kann. Es umfasst in der Regel:

1. SKILL.md — Name, Beschreibung (wann zu verwenden) und einen Workflow: geordnete Schritte (z. B. Scope definieren → Referenz laden → Entwurf → Validieren).
2. Referenzen — Markdown-Dateien (z. B. Standards, Kriterienlisten, Schemas), die der Agent lädt, wenn der Skill aktiv ist, damit der Entwurf an die Vorgaben angepasst bleibt.
3. Extension-Tools (optional) — TypeScript-Tools, die beim Agenten registriert sind (extension.ts) und deterministische Prüfungen am Dokument durchführen (Abdeckung, Logik-Gates, Vollständigkeit). Der Agent ruft sie auf, liest das Ergebnis und überarbeitet, bis die Prüfungen bestehen.

Der Projektkontext (Dokumenttyp, Domäne, Glossar) steht in AGENTS.md im Workspace, sodass jede Konversation in diesem Projekt denselben Rahmen hat.

Im Folgenden nutzen wir echte Rakenne-Skills, um Workflows, Prüfungen und Selbstkorrektur zu veranschaulichen, und vergleichen dann die Ausgaben.

Beispiel 1: HIQA-Medikamentenrichtlinie (Workflow + Referenz)

Skill: HIQA Designated Centre Medication . Erstellt eine Medikamentenrichtlinie für irische Designated Centres in Einklang mit HIQA-Standards.

Workflow im Skill:

1. Scope definieren — Zentrumstyp, Selbstverabreichung vs. verabreichte Medikamente, bestehende Verfahren.
2. Referenz laden — references/hiqa-nssbh.md für NSSBH Theme 3 (sichere Versorgung, Arzneimittelsicherheit) lesen.
3. Entwurf — Eine Richtlinie erstellen mit: Bestellung, Lagerung, Verschreibung, Verabreichung, Selbstverabreichung, MAR-Charts, Fehler/Vorfälle, Entsorgung, Schulung, Überprüfung.
4. Querreferenz — Mit Meldewesen und Betreuungs-/Unterstützungsplanung abgleichen.

Die Referenzdatei enthält HIQAs acht Themen und Governance-Erwartungen, damit das Modell nicht rät.

Rakenne (mit Skill): Der Agent folgt dem Workflow, bezieht NSSBH Theme 3 und zugehörige Governance-Texte aus der Referenz und erstellt eine Richtlinie mit klaren Abschnitten (Bestellung, Lagerung, Verabreichung, Fehler, Schulung usw.) und explizitem Bezug zu „NSSBH Theme 3“ und „Designated Centre“.

Einfaches ChatGPT: Sie könnten prompten: „Schreiben Sie eine Medikamentenrichtlinie für ein Pflegeheim in Irland.“ Das Modell liefert oft eine generische „Medikamentenrichtlinie“, die überall gelten könnte: vage „regelmäßige Überprüfung“, „geeignetes Personal“, kein Bezug zu HIQA oder NSSBH. Es gibt keine Gewähr, dass Theme 3 (oder Lagerung, MAR, Fehler, Entsorgung) systematisch abgedeckt ist, und keinen festen Schritt „Referenz laden, dann entwerfen“.

Beispiel 2: SOC-2-Kontrollnarrative (Workflow + Validierungstools)

Skill: SOC 2 Control Narrative Author . Erstellt SOC-2-Dokumentation mit Kontrollnarrativen, TSC-Zuordnung und Evidenz-Platzhaltern.

Workflow:

1. Scope — Welche TSC-Kategorien (Security immer; optional Availability, PI, Confidentiality, Privacy).
2. Kontrollnarrative — Für jedes in-scope Kriterium (CC1–CC9, A1, PI1, C1, P1–P8): Narrativ + Evidenzreferenz.
3. Evidenz — Evidenz-Platzhalter pro Narrativ ergänzen.
4. Validieren — Extension-Tools ausführen und korrigieren, bis sie bestehen.

Extension-Tools:

• check_trust_services_criteria_coverage — Stellt sicher, dass jedes in-scope TSC-Kriterium ein Narrativ und eine Evidenzreferenz hat; kennzeichnet nicht zugeordnete Kriterien.
• soc2_narrative_reliability_check — Wendet das SOC-2-Reliability-Rubrik an: kennzeichnet vage Formulierungen („wird regelmäßig überprüft“, „das Management gewährleistet Sicherheit“) und fordert Konkretisierung (wer, wie, wann, wo, benannte Technologie).

Rakenne (mit Skill): Der Agent erstellt Narrative und führt beide Tools aus. Fehlt bei CC4 die Evidenzreferenz oder steht „Zugriff wird regelmäßig überprüft“, liefern die Tools FAIL mit konkreten Befunden. Der Agent überarbeitet (fügt Evidenz hinzu, präzisiert „vierteljährlich durch das Security-Team per IdP-Zugriffsbericht“) und führt erneut aus, bis PASS.

Einfaches ChatGPT: Sie bitten um „SOC-2-Kontrollnarrative für Security“. Sie erhalten oft Text, der „Kontrollen“ und „Richtlinien“ erwähnt, aber nicht systematisch CC1–CC9 abdeckt, kein Kriterium Narrativ + Evidenz zuordnet und genau die vage Sprache verwendet, die das Rubrik ablehnt („regelmäßig überprüft“, „angemessene Kontrollen“). Es gibt keine automatische Prüfung; Lücken und Vagheit fallen erst bei der Audit-Vorbereitung auf.

Beispiel 3: CAPA-Bericht (Workflow + Logik-Gates)

Skill: CAPA Report . Berichte zu Korrektur- und Vorbeugemaßnahmen für Abweichungen (ISO 9001 / ISO 13485).

Workflow:

1. Abweichung — Befund, Scope, Eindämmung.
2. Ursache — Abschnitt 5 Whys ausfüllen (Why 1 … Why 5). Keine Maßnahmen vorschlagen, bevor das erledigt ist.
3. Gate — root_cause_logic_gate auf das Dokument anwenden. Nur bei Bestehen fortfahren.
4. Korrektur- / Vorbeugemaßnahmen — Maßnahmen, Verantwortliche, Fristen.
5. Umsetzung — Durchführung dokumentieren.
6. Wirksamkeitsprüfung — Ein zukünftiges Datum für die Verifikation setzen. verification_of_effectiveness_timer vor dem Schließen ausführen; nicht schließen, bis er besteht.

Extension-Tools:

• root_cause_logic_gate — Prüft auf Abschnitt Root Cause / 5 Whys und mindestens fünf unterscheidbare Why-Stufen. Schlägt fehl, wenn das Dokument vor einem vollständigen 5 Whys zu „Lösungen“ springt.
• verification_of_effectiveness_timer — Stellt sicher, dass ein Wirksamkeitsprüfungsdatum existiert und in der Zukunft liegt. Verhindert vorzeitiges Schließen der CAPA.

Rakenne (mit Skill): Der Agent erstellt Abweichung und Ursache. Hat er nur drei Why-Stufen oder springt zu „wir schulen die Mitarbeiter“, liefert das Gate FAIL mit „Why-Stufen erkannt: 3/5. Schließen Sie die 5-Whys-Analyse ab, bevor Sie Lösungen vorschlagen.“ Der Agent ergänzt Why 4 und Why 5, führt das Gate erneut aus und fährt mit den Maßnahmen fort. Vor dem Schließen muss er ein zukünftiges Wirksamkeitsdatum setzen; ist „2025-01-15“ in der Vergangenheit, schlägt der Timer fehl und der Agent muss ein zukünftiges Datum setzen.

Einfaches ChatGPT: Sie bitten um „eine CAPA zu einem Audit-Befund zu Dokumentenkontrolle“. Oft erhalten Sie einen Absatz Ursache und eine Maßnahmenliste in einem Zug – kein erzwungenes 5 Whys, kein Gate, keine Prüfung, ob die Wirksamkeitsprüfung in der Zukunft geplant ist. Das Ergebnis wirkt plausibel, würde aber eine strenge ISO-9001/13485-Prüfung nicht bestehen.

Beispiel 4: FedRAMP-Genehmigungspaket (Workflow + Vollständigkeitsprüfung)

Skill: FedRAMP Authorization Package . SSP, Anhänge, SAP, SAR, POA&M.

Workflow (vereinfacht): System kategorisieren → Systembeschreibung → Genehmigungsgrenze → Datenflüsse → Kontrollimplementierungen (mit Baseline-Referenz) → SSP-Anhänge → Validieren mit fedramp_package_completeness_check. Korrigieren und erneut ausführen, bis PASS. Eigene Teil-Workflows für SAP/SAR und POA&M; dasselbe Tool kennzeichnet fehlende Kontrollen, fehlende Anhangsabschnitte oder POA&M-Positionen ohne Sanierungsplan oder überfällig ohne Begründung.

Rakenne (mit Skill): Der Agent folgt dem Workflow, lädt Baseline- und Anhangsreferenzen, erstellt Abschnitte und führt die Vollständigkeitsprüfung aus. Lücken (z. B. nicht implementierte Kontrollen ohne Begründung, fehlender PIA-Abschnitt) werden gemeldet; der Agent füllt sie und validiert erneut.

Einfaches ChatGPT: Sie bitten um „ein FedRAMP-SSP für ein SaaS-Produkt“. Sie erhalten eine lange Erzählung, die wie ein SSP aussehen mag, aber nicht der echten FedRAMP-Struktur, der kontrollweisen Implementierung oder der Anhangs-Checkliste entspricht. Es gibt keine Möglichkeit, Baseline-Abdeckung oder Anhangsvollständigkeit zu prüfen; Lücken entdecken Sie später manuell.

Zusammenfassung: Gleiches Modell, andere Ergebnisse

Das zugrundeliegende LLM kann dasselbe sein. Der Unterschied liegt darin, wie es genutzt wird:

• Einfaches Prompting: Einmalig oder hin und her ohne festen Workflow, ohne autoritative, vom Skill geladene Referenzen, ohne Validierungstools. Die Ausgabe ist generisch, die Struktur driftet, das Modell kann sich nicht zuverlässig „prüfen und korrigieren“.
• Spezifikationsgestützt in Rakenne: Skills definieren Workflow, Referenzen und Extension-Tools. Der Agent folgt dem Workflow, lädt die richtigen Referenzen, entwirft und führt dann Tools aus, die PASS/FAIL und konkrete Befunde zurückgeben. Er korrigiert, bis die Prüfungen bestehen, und hält die gewünschte Struktur und Qualität.

Für komplexe, regulierte Dokumente – Richtlinien, Kontrollnarrative, CAPAs, Genehmigungspakete – ist spezifikationsgestütztes Verfassen mit Workflows und Validierungstools keine kleine Verbesserung; es ist der Unterschied zwischen „vielleicht gut genug“ und „audit-tauglich und wiederholbar“.

Zum Ausprobieren: Wählen Sie einen Rakenne-Skill für Ihre Domäne, legen Sie ein Projekt mit diesem Workflow an und vergleichen Sie die strukturierte, validierte Ausgabe mit dem, was ein einzelner ChatGPT-Prompt liefert.