/governance · Long-Form
Diese Seite erklaert das vollstaendige System hinter schollmayer.info. Sie ist auch die Vorlage fuer alle anderen aktiven Projekte.
Wer mit Claude Code anfaengt, hat schnell zwei Probleme. Erstens: Die Maschine produziert mehr Output als ein Mensch lesen kann. Zweitens: Ohne Prozess wird der Output nach drei Sprints unwartbar. Beide Probleme loest Governance — aber nur, wenn sie nicht als Buerokratie verstanden wird.
Der Aufbau hier ist einfach. Drei Schichten von Regeln, sieben Phasen pro Sprint, 16 thematische Personas, eine naechtliche Audit-Routine. Klingt nach Overhead — ist aber genau das Gegenteil. Es ist ein Werkzeug, das ein Einzelner schneller laufen laesst als ein Team von fuenf.
/04 · Das System dahinter
Claude Code ohne Prozess ist eine Demo. Mit Prozess ist es ein Werkzeug, mit dem ein Einzelner mehr leistet als ein 5er-Team. Klick eine Säule an — du siehst jeweils drei Absätze, ein echtes Beispiel und den Code-Schnipsel dahinter.
Verhaltensregeln laufen in jeder Session. Prozessregeln im Sprint. Domain-Regeln nur, wenn die jeweilige Expertin aktiviert ist. Nichts wiegt den Kontext unnötig voll.
~30 Zeilen immer geladen · 100+ aktive RegelnSchicht 1 — Verhaltensregeln — sind 15 nicht verhandelbare Haltungsregeln. Kundenrolle, keine Annahmen, Hooks antizipieren, SOFORT-Lernen, Systemzeit prüfen. Die laufen via SessionStart-Hook in jeder Session mit — auch Ad-hoc, auch LaunchAgents, auch Quick-Fixes.
Schicht 2 — Prozessregeln — sind ~25 Sprint-spezifische Regeln. Sprint-Zeremonien, Research-Enforcement, Roadmap-Sync, Backlog-Hygiene. Diese werden durch `/sprint-start` geladen, nicht automatisch.
Schicht 3 — Domain-Regeln — sind an Experten-Personas gekoppelt. Design-Regeln laden nur, wenn UX/UI aktiviert ist. Infra-Regeln nur, wenn Infrastruktur-Experte im Team ist. Das hält den Kontext schlank und relevant.
Beispiel
Beispiel aus Sprint 194: Ein Tool-Reject-Incident führte zu Regel 101 — Commit/Push/Deploy IMMER autonom, NIE fragen. Der Lernzyklus war: Incident → Feedback-Eintrag → Regel-Routing (Schicht 1, weil in jeder Session relevant) → Hook-Anpassung. Keine Mail, keine TODO — direkter Eintrag in verhaltensregeln.md.
memory/verhaltensregeln.md # Schicht 1, auto-loaded memory/arbeitsregeln.md # Schicht 2, via /sprint-start memory/experte-*.md # Schicht 3, on-demand
A Sprint-Ziel → B Ideation → C Konzept → D Bauen → E Review + Kunden-Abnahme → F Retro → G Übergabe. Keine Phase wird übersprungen. Jede hat eigene Marker und Gates.
7 Phasen · Sprint-Stand auf /nowPhase A verhandelt den Scope als Kunden-Vertrag: Scope-Tabelle, Deliverables, Abnahme-Kriterien. Ohne Scholly-Bestätigung kein Go. Phase B+C sind Plan+Konzept — bei visueller Arbeit obligatorisch mit Design-Gate.
Phase D ist Execution mit SOFORT-Regel: Erkenntnisse werden im Moment ihres Entstehens in die zuständige Experten-Persona geschrieben, nicht am Sprint-Ende gesammelt. Das verhindert Lernverlust.
Phase E hat eine STOPP-Pflicht: Kunden-Abnahme. Scholly sieht und bewertet das Ergebnis bevor Retro oder Backlog-Update. Bei Kritik wird sofort gefixt, nicht ins nächste Sprint geschoben.
Phase F+G schließen den Sprint ab: Retro reflektiert, Personas werden aktualisiert, Backlog re-prioritisiert, offene Entscheidungen dokumentiert. GitHub-Backup ist der letzte technische Schritt — ohne Push ist die Session nicht abgeschlossen.
Beispiel
Welche Phase aktuell läuft, steht auf /now — dort ist die einzige Live-Stelle. Hier unten zeigt die Timeline einen Beispiel-Sprint im Ablauf, damit man die 7 Phasen visuell versteht.
/sprint-start → Phase A /sprint-review → Phase E + Kunden-Abnahme /sprint-retro → Phase F + G
DevOps, QA, Frontend-Dev, Backend-Dev, Content-Stratege, Visual Designer, Infografik-Designer, UX-Researcher, Buchhaltung, Steuerberater … Jede mit eigener Weiterbildung alle 15 Sprints.
Pflicht-Aktivierung pro SprintJede Persona ist ein Markdown-File mit Frontmatter (last_research, next_research_due, Skill-Level) und Body (Patterns, Anti-Patterns, Cross-Projekt-Learnings). Die Persona wird in Phase A aktiviert — dann liest Claude das File und verhält sich entsprechend.
Alle 15 Sprints läuft ein Research-Zyklus pro Persona: WebSearch + Primär-Quellen + Integration ins Memory. Ein LaunchAgent (com.cowork.experten-research) zieht nightly fällige Personas — blockiert nie den Sprint-Start.
Cross-Experten-Briefings in Phase A sind Pflicht bei 2+ Personas: Frontend-Dev teilt mit Backend, was für den anderen relevant ist. Das verhindert Silo-Denken und beschleunigt Konsens.
Beispiel
Beispiel: Der Visual Designer pflegt design-tokens.md (Single Source of Truth für alle Projekte). Wenn Frontend-Dev eine Farbe braucht, liest er dort — er darf keine neue Farbe erfinden. Diese Regel entstand aus einem Sprint-167-Incident wo zwei Projekte unterschiedliche Akzent-Limes hatten.
memory/experte-visual-designer.md memory/experte-frontend-dev.md memory/experte-devops.md ...
Jede Nacht um 06:30 läuft ein Audit: Disk, Memory-Health, Backlog-Drift, Recovery-Readiness. Findings werden zu Backlog-Items. Keine Maintenance-Zettel, die liegen bleiben.
LaunchAgent · 13 aktiv · 6 PhasenDream Engine ist ein 6-Phasen LaunchAgent der nachts läuft — Disk-Audit, Memory-Health-Check, Backlog-Drift-Scan, Recovery-Note-Prüfung, Git-Backup-Check, Findings-Report. Jedes Finding landet automatisch als Backlog-Item.
Regel 89 (Finding → Backlog-Item PFLICHT) macht das zum geschlossenen Zyklus: Jeder Fehler, jede Lücke, jede neue Technologie die nachts auffällt, wird nicht nur notiert sondern als geplantes Item. Kein Verlust.
Der Morgen startet mit einem Telegram-Report: X Findings, Y kritisch, Z seit letzter Nacht neu. Scholly entscheidet beim Frühstück was in den nächsten Sprint rutscht.
Beispiel
Sprint 194 Incident: Dream Engine hat 5 uncommitted Code-Files in Production-Repos gefunden (nach 24h). Daraus entstand das Git-Status-Gate in /sprint-start: Auto-Commit+Push bei dirty Code-Repos — kein Scholly-Prompt nötig.
com.cowork.dream-engine.plist # 06:30 nightly ~/.claude/hooks/git-status-gate.sh # auto-commit
Start
Scope + Deliverables + Abnahme-Kriterien verhandeln
Ideen
Anforderungen klären, Lösungsansätze skizzieren
Plan
Dateien, Reihenfolge, Risiken, Design-Gate
Bauen
Execution mit SOFORT-Regel — Erkenntnisse sofort in Personas
Review
Debug, Refactor, Test, Deploy, Kunden-Abnahme (STOPP-Pflicht)
Retro
Personas aktualisieren, Retro dokumentieren
Übergabe
Backlog re-priorisieren, GitHub-Backup, Recovery-Note
/04 · G4 · Case-Studies
Register B · Proof
Drei Fehler. Drei Regeln. So entsteht das System — nicht aus Theorie, sondern aus dem was schiefgegangen ist.
Sprint 194 · 2026-04-08
Incident
Dream Engine fand nachts fünf Code-Files in aktiven Production-Repos, die seit 24 Stunden uncommitted waren. Kein Backup, kein Review, kein Rollback-Pfad.
Ursache: Kein Gate prüfte den Git-Status beim Sprint-Start. Wenn eine Session ohne Commit endete, blieb die Arbeit lokal und unsichtbar.
Outcome
Git-Status-Gate mit Auto-Commit + Push. Kein Scholly-Prompt, keine Rückfrage — dirty Repo → committet.
Sprint 173 · 2026-03-29
Entkopplung
Sprint-Start wartete synchron auf Research jeder überfälligen Persona. Bei 16 fälligen Experten bedeutete das 20+ Minuten Blockade bevor die eigentliche Arbeit begann.
Ursache: Weiterbildungs-Regel war mit Phase A verdrahtet. Alle Experten mussten aktuell sein, bevor die erste Zeile Code geschrieben wurde.
Outcome
LaunchAgent nightly 04:15, pro Lauf ein Experte. Sprint-Start nur noch Status-Check — Weiterbildung läuft im Hintergrund.
Sprint 189 · 2026-04-06
Regel-Geburt
In der Kunden-Abnahme zeigte sich: Ein Item stand als „done“ im Backlog, obwohl der eigentliche Umsetzungsschritt auf Scholly warten musste. Autonomie-Illusion.
Ursache: Digitale Scholly-Aktionen (Formulare, Accounts, Steuererklärung) wurden als Abhängigkeit markiert statt erledigt zu werden. Die Regel war unscharf.
Outcome
Regel 99: Digital lösbar = selbst lösen. Nur echte physische oder persönliche Aktionen dürfen als Scholly-Abhängigkeit markiert werden.
„Kein Sprint geht in Retro ohne Kunden-Abnahme. Kein Memory-Eintrag ohne Lernzyklus. Kein Plugin, das nicht vorher code-gelesen wurde."
02 · 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. Verhalten immer, Prozess im Sprint, Domain bei Bedarf — das hat den Output messbar verbessert.
Erkenntnis 02
Phase A bis G klingt nach Overhead. Ist aber das, was Wiederholungs-Sprints durch Kunden-Abnahme verhindert. Der Vertrag wird vor der Arbeit verhandelt, nicht danach. Das spart 1-2 Sprints pro Monat.
Erkenntnis 03
16 Personas sind nicht 16 Rollen. Es sind 16 fokussierte Wissens-Container — jede mit eigenem Research-Zyklus, eigenen Patterns, eigenen Anti-Patterns. Aktiviert wird, wer im Sprint gebraucht wird. Der Rest schweigt.
03 · Anti-Patterns
Anti-Pattern 01
Verlockend, aber faulig. Nach 5.000 Zeilen liest Claude nichts mehr richtig — die wichtigen Regeln gehen unter. Schichten + on-demand-Loading sind die Loesung.
Anti-Pattern 02
Wer keinen Scope-Vertrag macht, baut um den heissen Brei. Phase A erzwingt die unbequeme Frage „wann genau ist der Sprint fertig?" — bevor Code geschrieben wird.
Anti-Pattern 03
Jedes nicht aufgeschriebene Finding ist verlorenes Wissen. Regel 89 macht das zur Pflicht: jeder Bug, jede Idee, jede Luecke wird sofort Backlog-Item.
Anti-Pattern 04
Was digital loesbar ist, loest der Agent selbst (Regel 99). Scholly wird nur fuer Scope-Entscheidungen oder physische Aktionen gefragt. Das spart pro Sprint 5-10 unnoetige Rueckfragen.
04 · Was du mitnimmst
Schreib zwei kurze Files: verhaltensregeln.md (was IMMER gilt) und arbeitsregeln.md (nur im Sprint). Schon 30 Minuten Arbeit, sofortiger Output-Sprung.
Vor jeder Coding-Session: Scope-Tabelle, Deliverables, Abnahme-Kriterien. Ein einziges Markdown-File reicht. Kein Sprint ohne Vertrag.
Jeder Bug, jede Idee, jeder Lernmoment landet sofort in einem Backlog-File. Nicht „spaeter", sondern jetzt. Drei Sprints spaeter wirst du dir selbst danken.