/governance · Long-form
This page explains the full system behind schollmayer.info. It also serves as the template for every other active project.
When you start with Claude Code, you hit two problems fast. First: the machine produces more output than a human can read. Second: without process, that output becomes unmaintainable after three sprints. Both problems are solved by governance — but only if it's not understood as bureaucracy.
The setup here is simple. Three layers of rules, seven phases per sprint, 16 thematic personas, a nightly audit. Sounds like overhead — but it's the opposite. It's a tool that lets one person ship faster than a team of five.
/04 · The system behind it
Claude Code without process is a demo. With process, it's a tool that lets one person ship more than a team of five. Click a pillar — you'll see three paragraphs, a real example, and the code snippet behind it.
Behavior rules run in every session. Process rules during sprints. Domain rules only when the relevant expert is activated. Nothing loads the context unnecessarily.
~30 lines always loaded · 100+ active rulesLayer 1 — behavior rules — 15 non-negotiable stance rules. Customer role, no assumptions, anticipate hooks, learn IMMEDIATELY, check system time. Loaded via SessionStart hook in every session — including ad-hoc, LaunchAgents, quick fixes.
Layer 2 — process rules — ~25 sprint-specific rules. Sprint ceremonies, research enforcement, roadmap sync, backlog hygiene. Loaded by `/sprint-start`, not automatically.
Layer 3 — domain rules — attached to expert personas. Design rules load only when UX/UI is active. Infra rules only when the infrastructure expert is on the team. That keeps context lean and relevant.
Example
Example from Sprint 194: a tool-reject incident led to Rule 101 — commit/push/deploy ALWAYS autonomous, NEVER ask. The learning cycle: incident → feedback entry → rule routing (Layer 1, because relevant in every session) → hook adjustment. No email, no TODO — direct write into verhaltensregeln.md.
memory/verhaltensregeln.md # Layer 1, auto-loaded memory/arbeitsregeln.md # Layer 2, via /sprint-start memory/experte-*.md # Layer 3, on-demand
A sprint goal → B ideation → C concept → D build → E review + customer sign-off → F retro → G handover. No phase is skipped. Each has its own markers and gates.
7 phases · sprint status on /nowPhase A negotiates scope as a customer contract: scope table, deliverables, sign-off criteria. No go without Scholly's confirmation. Phase B+C are plan + concept — mandatory with a design gate for visual work.
Phase D is execution with the IMMEDIATE rule: insights are written into the relevant expert persona the moment they appear, not collected at sprint end. That prevents learning loss.
Phase E has a STOP duty: customer sign-off. Scholly sees and evaluates the result before retro or backlog update. On criticism, fix immediately, don't push it to the next sprint.
Phase F+G close the sprint: retro reflects, personas update, backlog re-prioritizes, open decisions get documented. GitHub backup is the last technical step — without push, the session isn't complete.
Example
Which phase is currently active is on /now — that's the only live spot. Below, the timeline shows an example sprint, so the 7 phases are visually understandable.
/sprint-start → Phase A /sprint-review → Phase E + customer sign-off /sprint-retro → Phase F + G
DevOps, QA, frontend dev, backend dev, content strategist, visual designer, infographic designer, UX researcher, accounting, tax advisor … Each with its own research cycle every 15 sprints.
Mandatory activation per sprintEach persona is a Markdown file with frontmatter (last_research, next_research_due, skill level) and body (patterns, anti-patterns, cross-project learnings). The persona is activated in Phase A — then Claude reads the file and behaves accordingly.
Every 15 sprints, each persona runs a research cycle: WebSearch + primary sources + integration into memory. A LaunchAgent (com.cowork.experten-research) pulls due personas nightly — never blocks sprint start.
Cross-expert briefings in Phase A are mandatory with 2+ personas: frontend-dev shares with backend what's relevant to the other. That prevents silo thinking and accelerates consensus.
Example
Example: the visual designer maintains design-tokens.md (single source of truth for all projects). When frontend-dev needs a color, they read there — they don't invent a new color. The rule grew from a Sprint-167 incident where two projects had different accent-limes.
memory/experte-visual-designer.md memory/experte-frontend-dev.md memory/experte-devops.md ...
Every night at 6:30 a.m., an audit runs: disk, memory health, backlog drift, recovery readiness. Findings turn into backlog items. No maintenance notes that get left behind.
LaunchAgent · 13 active · 6 phasesDream Engine is a 6-phase LaunchAgent that runs nightly — disk audit, memory health check, backlog drift scan, recovery-note check, git backup check, findings report. Every finding becomes a backlog item automatically.
Rule 89 (Finding → backlog item MANDATORY) closes the loop: every error, every gap, every new technology that comes up at night is not only noted but also planned. Nothing lost.
The morning starts with a Telegram report: X findings, Y critical, Z new since last night. Scholly decides over breakfast what lands in the next sprint.
Example
Sprint 194 incident: Dream Engine found 5 uncommitted code files in production repos (after 24h). The git-status gate in /sprint-start emerged from that: auto-commit + push on dirty repos — no Scholly prompt needed.
com.cowork.dream-engine.plist # 06:30 nightly ~/.claude/hooks/git-status-gate.sh # auto-commit
Start
Negotiate scope + deliverables + sign-off criteria
Ideation
Clarify requirements, sketch solutions
Planning
Files, order, risks, design gate
Build
Execution with the IMMEDIATE rule — insights into personas now
Review
Debug, refactor, test, deploy, customer sign-off (STOP duty)
Retro
Update personas, document retro
Handover
Re-prioritize backlog, GitHub backup, recovery note
/04 · G4 · Case studies
Register B · Proof
Three mistakes. Three rules. That's how the system grows — not from theory, but from what went wrong.
Sprint 194 · 2026-04-08
Incident
Dream Engine found five code files in active production repos uncommitted for 24 hours. No backup, no review, no rollback path.
Cause: no gate checked git status at sprint start. If a session ended without commit, the work stayed local and invisible.
Outcome
Git-status gate with auto-commit + push. No Scholly prompt, no callback — dirty repo → committed.
Sprint 173 · 2026-03-29
Decoupling
Sprint start waited synchronously on research for every overdue persona. With 16 due experts, that was 20+ minutes of blocking before real work began.
Cause: the research rule was wired into Phase A. All experts had to be up to date before the first line of code.
Outcome
LaunchAgent nightly at 4:15, one expert per run. Sprint start is now just a status check — research runs in the background.
Sprint 189 · 2026-04-06
Rule born
In customer sign-off it surfaced: an item was "done" in the backlog while the actual step was still waiting on Scholly. An autonomy illusion.
Cause: digital Scholly actions (forms, accounts, tax return) were marked as a dependency instead of being executed. The rule was unsharp.
Outcome
Rule 99: digitally solvable = solve it yourself. Only real physical or personal actions may be marked as a Scholly dependency.
"No sprint goes to retro without customer acceptance. No memory entry without a learning cycle. No plugin that hasn't been code-read first."
02 · Why like this
Insight 01
Claude doesn't get faster when you give him more rules. He gets smarter when he only reads the rules relevant to the current context. Behavior always, process per sprint, domain on demand — the output measurably improved.
Insight 02
Phase A through G sounds like overhead. It's what prevents redo-sprints through customer sign-off. The contract is negotiated before the work, not after. That saves 1-2 sprints per month.
Insight 03
16 personas aren't 16 roles. They are 16 focused knowledge containers — each with its own research cycle, patterns, anti-patterns. Activated when needed in a sprint. The rest stays silent.
03 · Anti-patterns
Anti-pattern 01
Tempting, but rotten. After 5,000 lines, Claude reads nothing properly anymore — the important rules get buried. Layers + on-demand loading is the answer.
Anti-pattern 02
Without a scope contract, you build around the bush. Phase A forces the uncomfortable question "when exactly is the sprint done?" — before the code is written.
Anti-pattern 03
Every finding not written down is lost knowledge. Rule 89 makes it mandatory: every bug, every idea, every gap becomes a backlog item right away.
Anti-pattern 04
Anything digitally solvable, the agent solves itself (Rule 99). Scholly is asked only for scope decisions or physical actions. That saves 5-10 needless callbacks per sprint.
04 · What you take away
Write two short files: verhaltensregeln.md (always-on) and arbeitsregeln.md (per sprint). 30 minutes of work, immediate output jump.
Before every coding session: scope table, deliverables, sign-off criteria. A single Markdown file is enough. No sprint without a contract.
Every bug, every idea, every learning lands in a backlog file right away. Not "later", but now. Three sprints later, you'll thank yourself.