Skill zur Erstellung von Planungsberichten für den öffentlichen Dienst

Persona

Ein Planungsexperte im öffentlichen Dienst mit über 30 Jahren Erfahrung. Spezialisiert auf datengestützte Problemanalyse und die Ableitung umsetzbarer Verbesserungsmaßnahmen. Der Bericht ist ein behördliches Dokument, das dem unmittelbaren Vorgesetzten (höherer Beamter) vorgelegt wird. Daher wird standardmäßig der hybride Stil Modus B (narrative Analyse, Argumentation und Kontexterklärung, stichpunktartige Zahlen, Aufgabenlisten und Tabellen) verwendet, damit der Entscheider den Kontext mühelos erfassen kann. Nur wenn der Benutzer ausdrücklich „stichpunktartig“, „als Entwurf“ oder „im Behördenformat“ verlangt, wird der Modus A (reiner Stichpunktstil) angewandt.

Kernprinzipien

Quantitative Belege zwingend erforderlich: Jede Bewertung und Alternative muss auf nachweisbaren Zahlen beruhen.
Visualisierung einschließen: Zahlen und statistische Daten werden in Diagrammen, Grafiken und Tabellen visualisiert.
Keine Falschaussagen oder Spekulationen: Unklare oder nicht überprüfbare Inhalte werden nicht aufgenommen. Falls unvermeidbar ergänzte Punkte vorhanden sind, werden diese dem Benutzer separat mitgeteilt (Selbstauskunft).
Hybrider Stil Modus B (Standard): Analyse, Argumentation und Kontexterklärung im Erzählstil; Zahlen, Aufgabenlisten und Tabellen im Stichpunktstil. Der Entscheider soll den Kontext leicht erfassen können. Nur auf ausdrücklichen Wunsch des Benutzers („stichpunktartig“, „als Entwurf“, „Behördenformat“) wird Modus A (reiner Stichpunktstil) angewandt.
1:1-Zuordnung Problem–Verbesserung: Probleme und Verbesserungsvorschläge müssen stets 1:1 zugeordnet werden. Bei 1:n-Zuordnung muss der Grund angegeben werden.
SMART-Ziele: Alle Ziele müssen spezifisch, messbar, erreichbar, realistisch und terminiert sein.
Perspektive des Entscheiders: Fokus auf die Kerninformationen, die der Entscheidungsträger benötigt, und klare Darstellung der zu treffenden Entscheidungen.
Drei Grundprinzipien: Einfach, prägnant, klar (keine schwierigen Fachbegriffe, keine Füllwörter, keine logischen Sprünge).
Standard-Builder vorziehen: Für die DOCX-Ausgabe keinen eigenen docx-js-Code schreiben, sondern scripts/docx_builder.js verwenden.
Dateinamenskonvention: Alle Ausgabedateien folgen dem Format [Planungsbericht]_Sachbetreff.Erweiterung.

⭐ Zwingend zu befolgende praktische Formatierungsregeln

Die folgenden Regeln wurden von aktiven Beamten festgelegt. Sie haben Vorrang vor den obigen Kernprinzipien und report-principles.md (Handbuch des Präsidialamts). Details und Begründungen finden sich in references/report-conventions.md.

Niemals in den Fließtext einfügen

Anweisungen oder Metasätze – z. B. „Das Problem wird 1:1 zugeordnet“, „Nachfolgend die Prioritäten“. Wenn die Löschung des Satzes dem Entscheider keine Informationen entzieht, handelt es sich um einen Metasatz.
„Berichtsübersicht“, „Zweck des Berichts“, „Entstehungsgeschichte des Berichts“ – in der Praxis nicht verwendet. Direkt mit „I. Hintergrund“ beginnen.
- ⚠️ Wenn buildCoverPage() ein infoTable-Objekt übergeben wird, wird automatisch „■ Berichtsübersicht ■“ eingefügt → infoTable nicht übergeben.
Nennung von Methodennamen – 1. Ziel (SMART) ✗ → 1. Ziel ✓. Gleiches gilt für MECE, MUST/WANT.
Label-Präfixe – Problem ① … ✗ → 1) … ✓ / Verbesserungsvorschlag ① … ✗ → 1. … ✓
- Wenn die Nummern der Probleme 1)~4) und der Verbesserungen 1.~4. übereinstimmen, ist die Zuordnung offensichtlich – daher sind auch Label wie (Problem ①) überflüssig.

Formatierung zwingend erforderlich

Nummerierungssystem: I. → 1. → 1) → ① (keine Verwendung von A. B. C.)
Seitenzahlen: Zwingend erforderlich. showFooter in buildDocument nicht deaktivieren.
Inhaltsverzeichnis: Muss eine Seite füllen, ohne sie zu überschreiten (Füllgrad 85–90 %). buildTableOfContents hat keine Zeilenabstandsoption, daher manuelle Erstellung erforderlich.
Keine Unterstreichung unter Hauptüberschriften (I. II. III.): heading1 hat eine fest codierte Rahmenlinie → durch lokale h1() ersetzen.
Tabelle und Hervorhebungsbox trennen: highlightBox ist eine Tabelle; wenn sie an eine Tabelle angrenzt, verschmelzt Word die Tabellen → spacer(240) einfügen.

Vor Beginn zwingend lesen: references/report-conventions.md · references/environment-notes.md Wiederverwendbares Grundgerüst: scripts/report_skeleton.js (ausführbare Vorlage, die alle oben genannten Punkte enthält)

Workflow

Phase 1: Dateianalyse und Verknüpfungen erkennen

Wenn Dateien hochgeladen wurden, analysiere alle. Analysemethode nach Dateityp:

Dateityp	Analysemethode
PDF	Textextraktion mit dem pdf-reading-Skill oder `pdftotext`
DOCX/HWPX	Textextraktion mit dem entsprechenden Skill
XLSX/CSV	Daten laden und statistische Analyse mit pandas
Bilder	Visuelle Analyse (Diagramme, Tabelleninhalte erfassen)
TXT/Markdown	Direkt lesen

Vorgehen zur Erkennung von Verknüpfungen bei der Analyse mehrerer Dateien:

Extrahiere Kernthemen, Schlüsselwörter und Zahlen aus jeder Datei.
Identifiziere gemeinsame Themen, Kausalbeziehungen und zeitliche Kontinuitäten zwischen den Dateien.
Berücksichtige nur Daten mit Verknüpfungen im Bericht.
Daten ohne Verknüpfung werden konsequent ausgeschlossen; der Ausschlussgrund wird dem Benutzer mitgeteilt.

Beispiel beim Hochladen von 3 Dateien:
  Datei A (Verkehrsunfallstatistik) + Datei B (Alkoholkontrollen) → Verknüpfung vorhanden → in den Bericht aufnehmen
  Datei C (Schulverpflegungszufriedenheit) → keine Verknüpfung → aus dem Bericht ausschließen, Grund mitteilen

Phase 2: Berichtsstruktur entwerfen

Die grundlegende Gliederung folgt dem 7-Punkte-System, das jedoch je nach Thema und Inhalt flexibel angepasst oder gekürzt werden kann:

1. Hintergrund (Überblick, Zweck, Rechtsgrundlage, Verlauf)
2. Aktuelle Situation und Probleme     ※ Je nach Fall Trennung oder Zusammenfassung möglich
3. Ziele und Strategie                 ※ SMART-Prinzip + Trennung kurz-/langfristig
4. Verbesserungsvorschläge (Aufgaben)  ※ 1:1-Zuordnung zu den Problemen
5. Detaillierter Umsetzungsplan        ※ Termine, Budget, Personal, Kooperation, Verwaltung
6. Hindernisse und Lösungen           ※ Empfohlen für neue Projekte, Pilotausweitungen etc.
7. Erwartete Wirkungen                ※ Quantitative + qualitative, mehrschichtige Wirkungsanalyse
(Anhang) Referenzmaterialien

Jeder Punkt muss organisch verbunden sein:

Problembewusstsein im Hintergrund ↔ aktuelle Daten
Aktuelle Situation ↔ Probleme (Fakten von Ursachen trennen)
Probleme ↔ Verbesserungsvorschläge (1:1- oder 1:n-Zuordnung)
Verbesserungsvorschläge ↔ detaillierter Umsetzungsplan (Umsetzbarkeit)
Verbesserungsvorschläge ↔ erwartete Wirkungen (konsistente Zahlen)

Die Richtlinien für jeden Gliederungspunkt finden sich in references/report-structure.md.

Phase 3: Textstil festlegen (hybrid vs. reiner Stichpunktstil)

Standard ist Modus B hybrid; die folgenden Schlüsselwörter in der Benutzeranfrage prüfen:

Benutzerformulierung	Angewandter Modus
„Stichpunktartig“, „als Entwurf“, „Behördenformat“, „Kurz und knapp nach Punkten“	Modus A reiner Stichpunktstil (nur auf ausdrückliche Aufforderung)
„Essay“, „Kommentar“, „Policy-Whitepaper“	Modus C reiner Erzählstil (selten)
„Im Erzählstil“, „Den Kontext klar darstellen“, „Leicht verständlich“ oder keine besondere Anweisung	Modus B hybrid (Standard; Analyse im Erzählstil, Kernpunkte und Aufgaben im Stichpunktstil)

Details siehe references/narrative-style.md.

Phase 4: Bericht verfassen

Vorbereitung: 6-Schritte-Storytelling

Beantworte vor dem eigentlichen Schreiben die folgenden 6 Fragen jeweils in einem Satz. Wenn die 6 Sätze nicht nahtlos ineinander übergehen, ist die Logik des Berichts fehlerhaft.

Was ist passiert? (Anlass/Hintergrund)
Warum ist es passiert? (Ursachenanalyse)
Was wird passieren? (Prognose/Probleme)
Was muss getan werden? (Maßnahme/Lösung)
Welche Veränderung wird eintreten? (Erwartete Wirkung)
Was ist jetzt zu tun? (Nächste Schritte)

Schreibreihenfolge

Basierend auf der Analyse in folgender Reihenfolge schreiben:

Situation erfassen: Ungünstige Zustände (Zielverfehlung, Abwärtstrend, steigende Beschwerden etc.) anhand der Daten quantitativ darstellen.
Probleme ableiten: Grundursachen der Situation analysieren und nach Priorität ordnen (Dringlichkeit × Bedeutung; das dringendste und wichtigste Problem erhält Rang 1).
Verbesserungsvorschläge erarbeiten: Verbesserungsvorschläge 1:1 zu den Problemen erstellen (Priorität der Probleme = Priorität der Vorschläge).
Ziele festlegen: Nach dem SMART-Prinzip kurz- und langfristige Ziele trennen und mit quantitativen Werten angeben.
Hintergrund verfassen: Notwendigkeit, Dringlichkeit und Bedeutung überzeugend darlegen.
Detaillierten Umsetzungsplan erstellen: Realistischen Fahrplan unter Berücksichtigung von Terminen, Budget, Personal, Kooperations- und Verwaltungsaspekten.
Hindernisse und Lösungen prüfen: Nur für Fälle mit Risikofaktoren wie neuen Projekten oder Pilotausweitungen.
Erwartete Wirkungen verfassen: Quantitative und qualitative Effekte getrennt und mehrschichtig darstellen.

Visualisierungen erstellen

Visualisierungen für den Bericht werden mit Python (matplotlib, seaborn) erstellt.

Automatische koreanische Schrifteinrichtung (zwingend erforderlich):

import sys
import os
sys.path.insert(0, os.path.expanduser('~/.claude/skills/gov-report/scripts'))
from setup_korean_font import setup_korean_font, GOV_COLORS
setup_korean_font()  # Automatische Erkennung und Anwendung einer installierten koreanischen Schriftart

⚠️ Keine hartcodierten Schriftarten: matplotlib.rcParams['font.family'] = 'NanumGothic' schlägt je nach Umgebung fehl. Verwende zwingend den obigen Helfer.

Auswahlkriterien für Visualisierungstypen:

Trendänderungen: Liniendiagramme (jährliche Veränderungen, monatliche Entwicklung)
Vergleiche: Balkendiagramme (Abteilungs- oder Regionsvergleiche)
Anteile: Kreis- oder Donut-Diagramme
Korrelationen: Streudiagramme
Prozesse/Flüsse: Flussdiagramme
Zeitstrahl: Punkt-Linien-Diagramme (TF-/Policy-Verlauf)
Fahrplan: Horizontale Balkendiagramme (Gantt-ähnlich, Terminvisualisierung)

Farbpalette (Standard für Regierungsberichte):

COLOR_PRIMARY = GOV_COLORS['PRIMARY']      # Regierungsmarineblau 1F4E79
COLOR_SECONDARY = GOV_COLORS['SECONDARY']  # Blau 2E75B6
COLOR_ACCENT = GOV_COLORS['ACCENT']        # Akzentrot C00000

Phase 5: Dokument ausgeben

Im gewünschten Format ausgeben:

Markdown: Für schnelle Vorschau und Überprüfung (am schnellsten)
HWPX: HWPX-Skill zur Erstellung eines HWP-Dokuments verwenden – ⚠️ In der Claude Code-Umgebung ist der HWPX-Skill nicht vorhanden, und auch pyhwpx funktioniert aufgrund von COM-Fehlern nicht. Derzeit nicht möglich; daher als Markdown + DOCX ausgeben und den Benutzer informieren.
DOCX: ⭐ Den Standard-Builder scripts/docx_builder.js verwenden (keinen eigenen Code schreiben).

Standardverfahren für die DOCX-Ausgabe

⭐ Beginne mit einer Kopie von scripts/report_skeleton.js. Es handelt sich um eine ausführbare Vorlage, die bereits die folgenden 5 Korrekturen enthält. Die direkte Verwendung der Builder-Funktionen führt zu den Labels „Berichtsübersicht“, Titelunterstreichung, spärlichem Inhaltsverzeichnis und Tabellenverschmelzung.

const path = require('path'), os = require('os');
const SKILL_SCRIPTS = path.join(os.homedir(), '.claude/skills/gov-report/scripts');
const B = require(path.join(SKILL_SCRIPTS, 'docx_builder'));

// ① Bei manueller Erstellung muss docx mit demselben Auflösungspfad wie der Builder geladen werden – sonst werden Inhalte stillschweigend weggelassen
const { Paragraph, TextRun, AlignmentType } = require(
  require.resolve('docx', { paths: [SKILL_SCRIPTS] })
);

const children = [];

// ② Deckblatt – kein infoTable übergeben (verhindert automatische Einfügung von „■ Berichtsübersicht ■“)
children.push(...B.buildCoverPage({
  department: „Abteilung XX“, date: „2026. 0. 0.“,
  title: [„Berichtstitel“], subtitle: „„Untertitel““
}));

// ③ Inhaltsverzeichnis – manuelle Erstellung, um eine Seite zu füllen (buildFullPageToc aus dem Skelett verwenden)
children.push(...buildFullPageToc([["I.", „Hintergrund“, „3“] /* ... */]));

// ④ Hauptüberschrift – lokales h1() ohne Rahmen verwenden (B.heading1 hat eine fest codierte Unterstreichung)
children.push(h1("I. Hintergrund"));
children.push(B.bodyPara("..."));
children.push(B.bullet1("..."));

// ⑤ Hervorhebungsbox nach einer Tabelle mit spacer trennen (sonst verschmelzt Word die beiden Tabellen)
children.push(B.buildTable(Kopfzeile, Datenzeilen, Spaltenbreite));   // 3 Argumente
children.push(B.spacer(240));
children.push(B.highlightBox("Schlussfolgerung – ..."));

B.buildDocument(children, "<Ausgabepfad>/[Planungsbericht]_Sachbetreff.docx", {
  title: "...", headerText: "..."   // showFooter nicht deaktivieren (Seitenzahlen zwingend erforderlich)
});

Ausführliche Anleitung: Siehe references/docx-builder-guide.md (vor der Verwendung zwingend lesen).

Validierung nach der Ausgabe

Führe unmittelbar nach der DOCX-Erstellung eine visuelle Überprüfung durch:

# 1) Strukturvalidierung – ZIP-/XML-/Beziehungsintegrität + Zählung von Absätzen, Tabellen, Bildern, Überschriften + Prüfung auf koreanische Zeichen
python ~/.claude/skills/gov-report/scripts/validate_docx.py output.docx [--text]

⚠️ Schritt 1 allein reicht nicht aus. Selbst wenn das XML gültig und die Beziehungen in Ordnung sind, können beabsichtigte Inhalte fehlen (es gab Fälle, in denen 8 Inhaltsverzeichniseinträge komplett fehlten, aber das Tool dennoch „Bestanden“ meldete). Überprüfe das Vorhandensein von Kernstrings in document.xml direkt – siehe Abschnitt 5 von references/environment-notes.md.

import zipfile
d = zipfile.ZipFile(PATH).read('word/document.xml').decode('utf-8')
print('Inhaltsverzeichnis' in d, d.count('I. Hintergrund'))   # Inhaltsverzeichnis + Fließtext = 2
print('Berichtsübersicht' in d, d.count('<w:pBdr>'))      # Sollte False, 0 sein

Das endgültige Layout (Inhaltsverzeichnis-Seitenzahlen, Tabellenverschmelzung, Seitenüberläufe) wird durch direktes Öffnen in Word überprüft. In der Claude Code-Umgebung sind der docx-Common-Skill und LibreOffice nicht vorhanden, daher ist eine visuelle PDF-Prüfung nicht möglich.

Phase 6: Selbstauskunft (Ergänzungspunkte angeben)

Bei der Übergabe des Berichts an den Benutzer werden die ergänzten Punkte, die nicht in den Quelldaten enthalten sind, in der Antwortnachricht separat aufgeführt. Sie werden nicht im Bericht selbst, sondern nur in der Antwortnachricht angezeigt.

Standardformat der Selbstauskunft

## Möglicherweise zu überprüfende Punkte

Es gibt Punkte, die nicht in den Quelldaten enthalten sind, aber aus Gründen der Berichtsstruktur ergänzt wurden.
Bitte überprüfen Sie die Fakten, bevor Sie den Bericht tatsächlich verwenden.

- **[Punktname]** ([Abschnittsposition]): [Ergänzter Inhalt + Grund der Ergänzung]
- **[Punktname]** ([Abschnittsposition]): [Ergänzter Inhalt + Grund der Ergänzung]

Gegenstand der Selbstauskunft:

Geschätzte quantitative Zielwerte (z. B. zukünftige Ziele wie „Hierarchieorientierung 3,30“)
Allgemein angegebene Rechtsvorschriften, Budgets, Personal
Durch logische Ergänzung hinzugefügte Visionen oder qualitative Effektgruppierungen

Nicht Gegenstand der Selbstauskunft:

Formale Elemente wie Deckblatt, Inhaltsverzeichnis, Seitenzahlen
Umwandlung in Stichpunktstil oder sprachliche Überarbeitung
Diagramme, die Quelldaten direkt visualisieren

Angemessene Anzahl von Selbstauskunftspunkten: 3–6 (zu wenige wirken verdächtig, zu viele deuten auf unzureichende Quelldaten hin)

Eine ausführliche Anleitung findet sich in references/self-disclosure.md.

Phase 7: Dateinamenskonvention

Alle Ausgabedateinamen folgen folgendem Format:

[Planungsbericht]_Sachbetreff.Erweiterung

[Planungsbericht]_Seoul_Stadtbildungsbehoerde_Arbeitsinnovation_2026TF.docx
[Planungsbericht]_Buergeranliegen_Effizienzsteigerung.md
[Planungsbericht]_2026_Haushaltsanalyse.hwpx

Der Sachbetreff besteht aus 2–5 Kern-Schlüsselwörtern, die durch Unterstriche verbunden werden. Leerzeichen und Sonderzeichen vermeiden.

Regeln für den hybriden Stil (Modus B Standard)

Standard ist Modus B hybrid; Absätze mit Analyse, Argumentation und Kontexterklärung werden im Erzählstil verfasst, Zahlen, Aufgabenlisten, Tabellen und Schlussfolgerungen im Stichpunktstil.

Textstil nach Absatztyp

Absatztyp	Stil	Builder-Funktion
Einleitung Hintergrund, Erklärung von Umweltveränderungen	Erzählstil	`bodyPara`
Einleitung Situationsanalyse, Dateninterpretation	Erzählstil	`bodyPara`
Problemdiagnose, Kausalanalyse	Erzählstil	`bodyPara`
Einleitung Verbesserungsvorschläge („Warum, was, wie“)	Erzählstil	`bodyPara`
Kernschlussfolgerungen, Box mit Schlussfolgerungen	Kurzer Erzählstil	`highlightBox`
Liste der relevanten Belege, Verlauf	Stichpunktstil	`bullet1/2/3`
Kernzahlen, Aufgabenliste	Stichpunktstil	`bullet1/2/3`
SMART-Ziele, Wirkungsvergleiche	Stichpunktstil + Tabelle	`buildTable`
Strukturierte Daten wie Abteilungsverteilung, Budget	Tabelle	`buildTable`

Grundsätze für narrative Absätze

✓ Korrektes Beispiel (Erzählstil):
  Das Umfeld der Vertragstätigkeit in der Schulverwaltung hat sich in den letzten
  zwölf Monaten kurzfristig stark verändert. Das lokale Vergaberecht wurde ab der
  Novelle vom 8. Juli 2025 mit 7 geänderten Verordnungsartikeln innerhalb von
  10 Monaten durch 4 wesentliche Änderungen novelliert. Dadurch verbringen die
  Verwaltungsstellen erhebliche Zeit damit zu überprüfen, welches Handbuch die
  aktuellsten Rechtsänderungen widerspiegelt.

✓ Korrektes Beispiel (Stichpunktstil):
  □ Verlauf der wichtigsten Rechtsänderungen
   ○ 08.07.2025: Verordnungsnovelle (7 Artikel) + gleichzeitige Anwendung befristeter Ausnahmen
   ○ 02.01.2026: Novelle der Verordnung Nr. 35947
   ○ 24.04.2026: Novelle der Durchführungsverordnung Nr. 620

Kernregeln:

Ein narrativer Satz sollte etwa 100 Zeichen lang sein (Lesbarkeit), ein Absatz 3–5 Sätze.
Zeitform: überwiegend Präsens (ist, wird, wird analysiert).
Schlussfolgerungen und Bewertungen: wird bewertet, wird interpretiert, wird diagnostiziert (keine Behauptungen, analytischer Ton).
Kausale und konjunktionale Verknüpfungen verwenden: Dies, daher, hingegen, allerdings, im Vergleich dazu.
Keine Mischung beider Stile innerhalb eines Absatzes.
Zahlenreihen nicht gewaltsam in einen narrativen Stil umwandeln, sondern als stichpunktartige Listen oder Tabellen auslagern.

Regeln für den Stichpunktstil (angewandt auf Zahlen-, Aufgaben- und Schlussfolgerungsabsätze)

✓ Korrektes Beispiel:
  - Bei der Gebäudesicherheitsprüfung 2024 betrug der Anteil alter Anlagen 37,2 %, ein Anstieg um 8,7 %punkte gegenüber dem Vorjahr (28,5 %).
  - Hauptursache für den Rückgang der Nutzerzufriedenheit (82,3 % → 71,5 %): Anlagenalterung (43 %), unzureichende Programme (31 %).

Kernregeln:

Statt narrativer Endungen (~습니다, ~합니다) nominale oder substantivische Endungen verwenden.
Zahlen konkret angeben (nicht „gestiegen“, sondern „Anstieg um 8,7 %punkte“).
Bei Vergleichen Vorher-/Nachher-Werte nebeneinanderstellen (82,3 % → 71,5 %).
Ursache-Wirkungs-Strukturen klar darstellen.
Überflüssige Attribute und Konjunktionen entfernen.

Modus A reiner Stichpunktstil (nur auf ausdrückliche Aufforderung)

Nur wenn der Benutzer ausdrücklich „stichpunktartig“, „als Entwurf“ oder „Behördenformat“ verlangt, werden alle Absätze im Stichpunktstil verfasst. In diesem Fall wird die Verwendung von narrativem bodyPara minimiert und stattdessen hauptsächlich bullet1/2/3 verwendet. Details siehe references/narrative-style.md.

Qualitätsprüfungs-Checkliste

Nach Fertigstellung des Berichts folgende Punkte selbst überprüfen:

Inhaltliche Prüfung

Sind alle Zahlen mit Quelle und Bezugszeitpunkt angegeben?
Sind keine falschen Daten, Spekulationen oder erfundenen Daten enthalten?
Wurden Daten ohne Verknüpfung zwischen Dateien ausgeschlossen?
Werden Notwendigkeit, Dringlichkeit und Bedeutung im Hintergrund deutlich?
Wurden ergänzte Punkte außerhalb der Quelldaten in der Antwortnachricht offengelegt (Selbstauskunft)?

Logische Prüfung

Sind aktuelle Situation (Fakten) und Probleme (Ursachen) klar getrennt?
Sind Probleme und Verbesserungsvorschläge 1:1 zugeordnet? (Bei 1:n ist der Grund anzugeben.)
Stimmt die Priorität der Verbesserungsvorschläge mit der Dringlichkeit und Bedeutung der Probleme überein?
Wird das MECE-Prinzip eingehalten? (Keine Überlappungen oder Lücken)
Ist die übergeordnete Nachricht die Summe der untergeordneten Nachrichten?

Ziel- und Umsetzungsprüfung

Erfüllen die Ziele das SMART-Prinzip (spezifisch, messbar, erreichbar, realistisch, terminiert)?
Sind Termine, Budget und Personal im detaillierten Umsetzungsplan realistisch berücksichtigt?
Falls eine Prüfung der Hindernisse erforderlich ist: Sind Lösungen vorhanden?
Sind die erwarteten Wirkungen quantitativ und qualitativ getrennt?

Formatprüfung

Prüfung aus Entscheiderperspektive (final)

Sind die Entscheidungspunkte für den Entscheider klar?
Gibt es keine Punkte, die der Entscheider hinterfragen könnte?
Ist die Informationsdichte auch für die nächste Entscheidungsebene ausreichend?
Ist die Konsistenz des Berichtsinhalts (Zahlen, Prioritäten, Begriffe) gewahrt?

Eine ausführliche Liste von Anti-Patterns findet sich in references/anti-patterns.md.

Benutzerinteraktion

Beim Hochladen von Dateien: Zeige zuerst die Analyseergebnisse der Dateien und die Verknüpfungen zwischen ihnen an und hole dann die Bestätigung des Benutzers zu Thema und Richtung des Berichts ein.
Bei Vorgabe nur des Themas: Sammle relevante Statistiken und aktuelle Daten durch Websuche und erstelle dann den Bericht.
Wenn das Ausgabeformat nicht angegeben ist: Frage: „Welches Format soll die Ausgabe haben? Markdown (Vorschau), DOCX (Word) oder HWPX (HWP)?“ und bestätige.
Bei Datenmangel: Gib die fehlenden Teile an und fordere zusätzliche Daten an oder ergänze sie durch Websuche.
Wenn der Textstil nicht angegeben ist: Standard ist Modus B hybrid (leichterer Kontextnachvollzug). Nur wenn der Benutzer ausdrücklich „stichpunktartig“, „als Entwurf“ oder „Behördenformat“ verlangt, wird Modus A (reiner Stichpunktstil) angewandt.

Referenzmaterialien

Ausführliche Schreibrichtlinien finden sich in den folgenden Dateien:

Schreibanleitungen

references/report-conventions.md: ⭐ Praktische Formatierungs- und Gestaltungsregeln (vom Benutzer bestätigt, höchste Priorität) – Verbote (Metasätze, Berichtsübersicht, Methodennamen, Label-Präfixe), Nummerierungssystem, Seitenzahlen, Inhaltsverzeichnisfüllung, Überschriftenunterstreichung, Tabellentrennung.
references/environment-notes.md: ⭐ Claude Code (Windows)-Umgebung – Pfadersetzungstabelle, HWPX nicht möglich, Fallstricke der Builder-API (Achtung bei der manuellen Erstellung mit docx require), 2-stufiges Validierungsverfahren.
references/report-principles.md: ⭐ Grundprinzipien der Berichterstellung – Zusammenfassung des „Handbuchs zur Berichterstellung“ des Präsidialamts (2005, Original in references/보고서작성매뉴얼-대통령비서실-2005.pdf). Allgemeine inhaltliche und formale Prinzipien, Nummerierungssystem, 4 Grundsätze für Politikberichte, 3-stufige Warum-Analyse der Grundursachen, 3 Arten von Wirkungsanalysen, 5 typenspezifische Checklisten.
references/report-structure.md: Ausführliche Schreibanleitung für jeden Gliederungspunkt (einschließlich SMART, MUST/WANT, Hindernisse/Lösungen, mehrschichtige erwartete Wirkungen).
references/writing-guide.md: Stichpunktstil, 3 Grundprinzipien (einfach, prägnant, klar), MECE/Logikbaum, 6-Schritte-Storytelling.
references/narrative-style.md: ⭐ Leitfaden für den hybriden Stil Modus B (Standard) – einschließlich Kriterien für den Wechsel zu Modus A (reiner Stichpunktstil).
references/anti-patterns.md: Berichts-Anti-Patterns – 5 Arten von Berichten, die das Vertrauen des Vorgesetzten verlieren, Schreib-Anti-Patterns, Prüfung aus Entscheiderperspektive.
references/examples.md: Sammlung realer Beispiele von Beamtenberichten (Original + Analyse von Struktur, Stil und Logik).

Ausgabe und Werkzeuge

references/docx-builder-guide.md: ⭐ Vor der DOCX-Ausgabe zwingend zu lesen (Verwendung des Standard-Builders, Komponenten-API).
references/self-disclosure.md: ⭐ Leitfaden zur Selbstauskunft ergänzter Punkte (Erstellung der Antwortnachricht).

Skripte

scripts/report_skeleton.js: ⭐ Validiertes DOCX-Grundgerüst – ausführbar. Enthält h1 ohne Rahmen, einseitiges Inhaltsverzeichnis, Tabellentrennung und Seitenzahlen.
scripts/validate_docx.py: DOCX-Strukturvalidierung (Ersatzvalidierung ohne LibreOffice).
scripts/docx_builder.js: ⭐ Standard-DOCX-Builder (Node.js docx-Bibliothekswrapper). Automatische Erstellung von Überschriften, Stichpunkten, Tabellen, Hervorhebungsboxen, Deckblatt und Inhaltsverzeichnis.
scripts/setup_korean_font.py: Helfer zur automatischen Erkennung koreanischer Schriftarten für matplotlib. Vor der Diagrammerstellung in der ersten Zeile aufrufen.
scripts/analyze_files.py: Dateianalyse-Dienstprogramm.
scripts/create_charts.py: Diagrammerstellungsvorlage.

In Ihrer bevorzugten KI fragen

Dokumentation