Workspace-Template — Einstieg

Dieses Repository ist eine leere Kopiervorlage für eine projektübergreifende Arbeitsstruktur. Es enthält keine Inhalte, sondern die Mechanik: Ordnerlogik, Qualitätsstandards, Vorlagen und die Automatisierung, die beides durchsetzt.

Lies diese Datei einmal ganz. Danach reicht Abschnitt 7 zum Nachschlagen.

---

1. Welches Problem das löst

Einzelne Projektordner nebeneinander haben drei wiederkehrende Schwächen:

1. Jedes Projekt erfindet seine eigene Struktur. Nach sechs Monaten weiß niemand mehr — auch man selbst nicht —, wo in Projekt B das liegt, was in Projekt A unter analysis/ stand.
2. Wissen bleibt im Projekt. Eine Methodik, die einmal sauber erarbeitet wurde, wird beim nächsten Vorhaben von vorn erarbeitet.
3. Qualität hängt an der Tagesform. Ob eine Zahl gegen die Vorperiode geprüft wurde, ob eine Annahme noch gültig ist, ob ein Deck dem Standard folgt — das entscheidet sonst der Zeitdruck kurz vor dem Termin.

Diese Struktur beantwortet alle drei an einer Stelle, statt in jedem Projekt neu.

2. Das Grundprinzip in einem Satz

Wissen fließt hinein (02_Literature/) → wird zu Projektergebnissen verarbeitet (03_Projects/) → bewährte Muster werden daraus destilliert (01_Frameworks/) → alles darüber hinaus ist Automatisierung, die Wiederholarbeit abnimmt (.claude/).

3. Die Ordner — was gehört wohin

Ordner	Was liegt hier	Wie oft ändert es sich
CLAUDE.md	Rolle, Zielsetzung, Arbeitsweise, Qualitätsstandards — lädt IMMER	selten
00_Strategy_and_Knowledge/	Rollenverständnis, Stakeholder-Muster, Vertraulichkeitsregeln	selten
01_Frameworks/	Frameworks, die sich in echten Projekten bewährt haben	wächst langsam, nur bei Bewährung
02_Literature/	Information Hub: Fachbücher (PDF) + Methodenindex — die Quelle, aus der Frameworks entstehen	wächst bei neuer Literatur
03_Projects/	Ein Unterordner pro Vorhaben — Daten, Analysen, KPIs, Dashboards, Reports	laufend
04_Templates/	Leere Kopiervorlage für neue Projekte + Präsentations- und DoD-Standard	selten
05_Portfolio_Dashboard/	Führt KPIs aus allen Projekten zusammen	bei neuen KPI-Feeds
.claude/	Technik: Slash Commands, Subagents, Hooks	kaum direkt angefasst

Der wichtigste Unterschied: 02_Literature/ = woraus geschöpft wird. 01_Frameworks/ = was daraus gebaut und bestätigt wurde. Nie verwechseln — sonst wird 01_Frameworks/ mit der Zeit zu einer zweiten, schlechteren Kopie der Literatur.

4. Erste Schritte (einmalig, ca. 30 Minuten)

1. Ordner kopieren an den gewünschten Ort und umbenennen (z.B. Workspace). Danach git init und ein erster Commit — die Historie ist später das Gedächtnis, wann welche Annahme galt.
2. CLAUDE.md ausfüllen. Nur die Abschnitte 1 und 2 sowie die Arbeitssprache sind Platzhalter; der Rest ist der übernommene Standard. Ohne Abschnitt 1 und 2 rät Claude bei jeder Sitzung, für wen es arbeitet — das ist der eine Schritt, der sich nicht überspringen lässt.
3. pip install -r requirements.txt — für die PDF-Erkennung (pypdf), die Migrations-Inventur und den Deck-Bau (python-pptx).
4. Bestehende Projekte übernehmen — siehe Abschnitt 5. Das ist der Schritt, der aus einer leeren Struktur einen benutzten Workspace macht.
5. Neues Projekt anlegen mit /new-project <name>. Nicht den Ordner von Hand bauen: der Befehl setzt Nummerierung und Grundstruktur konsistent auf.
6. Erstes Buch ablegen in 02_Literature/ als PDF. Beim nächsten Sitzungsstart meldet der Hook das PDF, /add-literature trägt es mit Inhaltsverzeichnis in den Index ein.

Nicht enthalten und einmalig nachzuholen: die PowerPoint-Firmenvorlage. Sie liegt bewusst nicht im Repository (CI-Material gehört nicht auf GitHub). Ablegen unter 04_Templates/firmenvorlage_DE.pptx bzw. _EN.pptx; die Einrichtung inklusive Vorlagen-Check und Layout-Abgleich beschreibt 04_Templates/README_PowerPoint.md.

5. Von der bisherigen Ablage hierher — /migration

Der Normalfall ist nicht der grüne Start, sondern eine gewachsene Ablage mit laufenden Projekten. Dafür gibt es einen geführten Weg:

1. Bestehende Projektordner nach _Migration_Inbox/ kopieren (nicht verschieben — das Original bleibt unangetastet, bis alles geprüft ist).
2. /migration aufrufen. Der Befehl inventarisiert den Eingang: er hasht alle Dateien, erkennt exakte Dubletten, Versionsketten (Bericht_v2_final.xlsx neben Bericht final_final 2026-05-12.xlsx) und technischen Ballast, und schlägt Projektkandidaten vor.
3. Ein Projekt je Durchlauf wird auf die Standardstruktur gezogen: Scaffold anlegen, vier Fragen zu Auftrag und Datenquellen, Zuordnungstabelle vorlegen, nach Bestätigung verschieben.
4. Was nicht ins Projekt gehört, wandert nach _Archiv/ — getrennt nach Dublette, veraltetem Stand, ohne Mehrwert und unklar. Gelöscht wird nichts, jede Bewegung steht mit Grund in _Archiv/Migrationsprotokoll.md.
5. Wiederholen, bis _Migration_Inbox/ leer ist. Leerer Eingang = Migration beendet.

Der Eingang und die Archiv-Unterordner sind von der Versionierung ausgeschlossen; versioniert wird nur das Protokoll — der Nachweis, was wohin gewandert ist, nicht der Inhalt.

6. Was automatisch passiert

Auslöser	Was geschieht	Datei
Sitzungsstart	Neue PDFs in 02_Literature/ werden erkannt, die ersten 20 Seiten als Kontext geliefert — Vorschlag für den Index, nie automatischer Eintrag	.claude/hooks/detect_new_literature.py
Schreiben nach reports/steering_committee/	Wird blockiert, wenn das data_quality_log.md des Projekts älter als 7 Tage ist	.claude/hooks/check_qa_freshness.py

Der zweite Hook ist der eigentliche Zweck der ganzen Konstruktion: Er verhindert, dass ein Foliensatz für die Geschäftsleitung entsteht, ohne dass die Zahlen darin geprüft wurden. Wenn er stört, ist das die beabsichtigte Wirkung — die Lösung ist /qa-check, nicht das Abschalten.

7. Schnellreferenz — Befehle

Befehl	Wofür
/migration	Bestehende Ablage schrittweise in die Struktur überführen
/new-project <name>	Neues Projekt aus dem Scaffold anlegen
/qa-check <projekt>	Die drei Qualitätsstandards prüfen (Plausibilität, Präzedenz, Annahmen-Verfall)
/steering-prep <projekt>	Go / Conditional Go / No-Go vor dem Steering Committee
/weekly-review <projekt>	Wochenfortschritt zusammenfassen, Projektstatus aktualisieren
/add-literature <titel> <autor> <datei.pdf>	Neue Quelle in den Information Hub eintragen

Zwei Subagents arbeiten im Hintergrund und halten Detailrauschen aus dem Hauptgespräch: literature-scout (welche Methode passt hier?) und qa-validator (Datenqualität eines Projekts).

8. Was dieses Template bewusst NICHT enthält

• Keine Fachliteratur. Die PDFs sind lizenzgebunden; der Index zeigt nur das Format. Eigene Bücher ablegen, /add-literature erledigt den Rest.
• Keine Beispielprojekte. 03_Projects/ ist leer — echte Projektdaten wären hier nur Ballast und ein Vertraulichkeitsrisiko.
• Keine ausgefüllte Stakeholder-Map. Das Gerüst steht, die Zeilen schreibt jeder für sein eigenes Umfeld.
• Keine PowerPoint-Firmenvorlage. CI-Material gehört nicht in ein GitHub-Repository; .gitignore schließt 04_Templates/*.pptx aus. deck_toolkit.py sucht die Vorlage zur Laufzeit und sagt beim Fehlen, was zu tun ist.
• Keine Git-Historie. Bewusst ein frisches Repository.