Die ausführliche Fassung
Diese Seite erklärt das vollständige System hinter schollmayer.info. Sie ist zugleich die Vorlage für alle anderen aktiven Projekte.
Wer mit Claude Code anfängt, hat schnell zwei Probleme. Erstens: Die Maschine produziert mehr Output als ein Mensch lesen kann. Zweitens: Ohne Prozess wird der Output nach wenigen Wochen unwartbar. Beide Probleme löst Governance — aber nur, wenn man sie nicht als Bürokratie missversteht.
Der Aufbau hier ist einfach. Jedes Vorhaben läuft in drei Akten — Plan, Bau, Abnahme — mit genau zwei Kunden-Entscheidungen. Dazu 6 Regel-Dateien und eine Review-Pflicht: 2 unabhängige Prüf-Instanzen — Architektur, sobald ein Plan schwer umkehrbar ist; QA vor jedem Push. Klingt nach Overhead — ist aber genau das Gegenteil. Es ist ein Werkzeug, mit dem ein Einzelner mehr schafft als ein Team von fünf. Und es ist das Ergebnis einer radikalen Verschlankung: ein einziges Release entfernte 71.964 Zeilen.
Das System dahinter
Claude Code ohne Prozess ist eine Demo. Mit Prozess ist es ein Werkzeug, mit dem ein Einzelner mehr schafft als ein Team von fünf. Jedes Vorhaben läuft in drei Akten — und der Kunde entscheidet genau zweimal.
8 Pflicht-Schritte: Abhängigkeiten, Architektur, Tests, Tech-Debt — geprüft vom IT-Architekt-Review, bevor du es siehst.
Läuft autonom. Tests grün, QA-Review vor jedem Push, Deploy verifiziert am echten Endprodukt — nicht am Health-Check.
Du verifizierst das Ergebnis visuell. Danach wird festgehalten, was gelernt wurde — damit derselbe Fehler kein zweites Mal bezahlt wird.
Du entscheidest zweimal. Alles dazwischen läuft autonom.
Der Kunde entscheidet genau zweimal: Plan-OK und Abnahme. Keine Architektur-Fragen, keine Zwischen-Klicks — Ergebnisse statt Diskussionen.
Ein Vorhaben je SitzungVerhalten, Token-Doktrin, Modell-Disziplin, 17 Architektur-Filter, Workflow, Kunden-Anforderungen. Davor waren es 121 verstreute Regeln — bis ein Release 71.964 Zeilen gelöscht hat.
Lean-Release · 2026-05Bei schwer umkehrbaren Plänen liest ein Architektur-Review gegen; vor jedem Push prüft ein QA-Review. Beide arbeiten mit eigenem Gedächtnis, unabhängig von dem, was beim Bauen im Kopf war — genau deshalb finden sie, was der Bauende übersieht.
Gegenlesen ist eingebaut, nicht optionalKein schwer umkehrbarer Plan ohne Architektur-Pass. Kein Push ohne QA-Review. Kein Wissens-Eintrag ohne Verifikations-Stempel mit Ablaufdatum. Jeder Befund endet belegt — behoben oder begründet verworfen.
Pair-Programming · jeder Befund belegt„Nichts geht live ohne Abnahme durch den Kunden. Kein Code wird gepusht ohne geprüftes Go. Kein Wissen gilt, bevor es verifiziert ist.“
Case-Studies
Nicht aus Theorie — aus dem, was schiefgegangen ist.
2026-05-22
Radikaler Schnitt
Vier Monate Aufbau: über 100 Regeln, acht Prozess-Phasen, Hunderte Gedächtnis-Dateien. Alles funktionierte — und genau das war das Problem. Der erste ernste Stresstest zeigte: Komplexität, die Disziplin verlangt, frisst sich selbst.
In einer Nacht wurde gelöscht, was Pflege verlangte, ohne Wert zu liefern: 162 Wissens-Dateien wurden zu 53 Wiki-Seiten, 100+ Regeln zu fünf Regel-Dateien.
Outcome
Je kleiner die Oberfläche, desto verlässlicher das System. Was weg ist, kann nicht brechen.
2026-05-22
Incident
Eine einzige unverifizierte Behauptung in einer Konfigurationsdatei — dutzendfach gelesen, nie getestet — kostete 11.000 Token an Forensik, als sie brach.
Ursache: kein Zeitstempel. Eine Behauptung ohne Ablaufdatum wird irgendwann als Fakt behandelt.
Outcome
Jeder Wissens-Eintrag trägt seitdem last_verified + Methode. Abgelaufene Stempel meldet eine wöchentliche Routine.
2026-05
Regel-Geburt
Sieben Aufgaben wanderten fast 200 Planungsrunden lang unangetastet mit. Nicht blockiert, nicht in Arbeit — nur mitgeschleppt. Die Automatik sah die Markierung, nicht die Absicht.
Mitschleppen ist kein Fortschritt. Es ist eine vertagte Entscheidung, die Zinsen anhäuft.
Outcome
Seitdem wandert nichts mehr automatisch mit: Jedes Vorhaben endet mit Abnahme — oder mit einer dokumentierten Entscheidung dagegen.
Warum so
Erkenntnis 01
Claude wird nicht schneller, wenn man ihm mehr Regeln gibt. Er wird schlauer, wenn er nur die Regeln liest, die im aktuellen Kontext relevant sind. Grundregeln immer, Prozess je Arbeitsstrang, Fachwissen nur bei Bedarf — das hat die Ergebnisse messbar verbessert.
Erkenntnis 02
Plan, Bau, Abnahme klingt nach Overhead. Ist aber das, was Wiederholungs-Schleifen verhindert: Der Plan wird vor der Arbeit verhandelt und reviewt, nicht danach. Der Kunde liest ein Konzept in seiner Sprache — und entscheidet genau zweimal.
Erkenntnis 03
Lange liefen hier siebzehn spezialisierte Rollen mit eigenem Wissensstand. Im Juli 2026 sind bis auf 2 alle gelöscht worden: die beiden, die gegenlesen — Architektur, wo ein Fehler teuer würde, QA vor jedem Push. Die Bau-Rollen brachten Verwaltung statt Qualität. Was blieb, ist das, was tatsächlich Fehler findet: eine zweite Instanz, die nicht weiß, was sich der Bauende gedacht hat.
Anti-Patterns
Anti-Pattern 01
Verlockend, aber es rächt sich. Nach 5.000 Zeilen liest Claude nichts mehr sauber — die wichtigen Regeln gehen unter. Schichten und bedarfsweises Nachladen sind die Lösung.
Anti-Pattern 02
Wer den Rahmen nicht vorab festlegt, baut am Ziel vorbei. Der Plan-Akt erzwingt die unbequeme Frage „wann genau ist das Vorhaben fertig?“ — bevor Code geschrieben wird.
Anti-Pattern 03
Jeder Befund, der nur im Kopf bleibt, ist verlorenes Wissen. Deshalb bekommt jeder genau einen von drei Ausgängen: sofort beheben, als Aufgabe notieren, oder mit einer Begründung verwerfen. Was nicht in eine dieser drei Spalten passt, war kein Befund.
Anti-Pattern 04
Was digital lösbar ist, löst der Agent selbst. Gefragt wird nur bei Entscheidungen über den Umfang oder bei Dingen, die in der echten Welt passieren müssen. Das spart pro Vorhaben fünf bis zehn Rückfragen, die niemandem geholfen hätten.
Was du mitnimmst
Schreib zwei kurze Dateien: behavior.md (was IMMER gilt) und workflow.md (wie ein Vorhaben abläuft). Wenige Dateien mit hartem Zeilen-Limit schlagen hundert verstreute Regeln.
Vor jeder Coding-Session: Scope, Deliverables, Abnahme-Kriterien — und ein Review des Plans, bevor gebaut wird. Ein einziges Markdown-File reicht. Kein Vorhaben ohne Vertrag.
Jeder Fehler, jede Idee, jeder Lernmoment landet sofort in einer Backlog-Datei. Nicht „später“, sondern jetzt. Nach drei Vorhaben wirst du dafür dankbar sein.