Warum spezialisierte Sessions?
cipher-mux trennt Phasen der Softwareentwicklung in eigene KI-Sessions — mit eigenem Kontext, eigenen Anweisungen, eigenen Grenzen. Hier steht, warum das manchmal funktioniert und wann nicht.
Die Idee
Wenn du eine einzige Claude-Session bittest, ein Feature zu planen, zu coden, zu testen und zu reviewen, passiert Folgendes: der Kontext fuellt sich, fruehere Anweisungen werden komprimiert, die Qualitaet sinkt. Jeder, der Claude Code fuer groessere Aufgaben benutzt hat, kennt das.
Die Hypothese hinter cipher-mux: Was waere, wenn jede Phase der Entwicklung ihre eigene Session bekaeme? Eigener Kontext, eigene Anweisungen, eigener Fokus. Mit sauberen Uebergaben zwischen den Phasen.
Das ist kein bewiesenes Verfahren. cipher-mux ist der Versuch einer einzelnen Person, diese Hypothese zu testen. Fuer manche Aufgaben funktioniert es ueberraschend gut. Fuer andere faellt es flach.
Token-Kosten sind real: Jede Session verbraucht API-Tokens. Parallele Sessions multiplizieren das. Das Context Window ist endlich. Wenn es voll ist, vergisst Claude — und es gibt kein Undo.
Der Lebenszyklus
Sechs Phasen, jede mit eigenem Preset. Die Pipeline laeuft sequentiell — jede Phase uebergibt ein definiertes Artefakt an die naechste. Workshop und Companion laufen quer dazu.
Workshop ist die Schaltzentrale nach dem Testing: er empfaengt Findings und verteilt sie an die passende Entity — Debugger fuer Bugs, Cyber Factory fuer groessere Umbauten, Ideation fuer Feature-Ideen. Der Companion begleitet den gesamten Zyklus als Berater und Erklaerer.
Ideation Partner
Recherchiert autonom mit Sub-Agents, synthetisiert Ergebnisse, prueft auf Robustheit (Pre-Mortem). Stellt Gegenfragen, bevor er strukturiert.
Refinement
Pflichtfeld-Check, systematisches Luecken-Audit, Validierung gegen bestehende Architektur. Schreibt Detail-Spec mit REQ-IDs und Akzeptanzkriterien.
Cyber Factory
Architekturphase (Subsystem-Zerlegung, ADRs, Scaffolding), dann Wellenplan mit bis zu 5 parallelen Worker-Sessions in eigenen Git-Worktrees. Monitoring in 5-7 Minuten-Zyklen.
Testing Assistant
Systematische Tests, adversariales Probing, Sicherheits-Audit (OWASP-Top-10). Fixt nichts — dokumentiert nur.
Debugger
Root-Cause-Analyse, Fix-Plan, eigene Worker-Session fuer den Fix, Verifikation (Test muss vorher rot gewesen sein, nach Fix gruen). Maximal 2 Retries, danach Eskalation an den User.
Audit
Code Review, Sicherheits-Audit, ADR-Konsistenz-Check, Cognitive-Debt-Bewertung. Implementiert nichts, fixt nichts.
Die Entities im Detail
Zehn vordefinierte Entities, jede mit eigenem Zweck. Keine davon ist ein Alleskoenner — das ist Absicht.
Companion
Dein Einstiegspunkt. Erklaert Konzepte, hilft bei Entscheidungen, merkt sich deine Praeferenzen ueber Sessions hinweg. Schreibt keinen Code. Drei Modi: Tutor (erklaeren), Berater (abwaegen), Helfer (ausfuehren).
Voice Relay
Der Companion fuer Sprachinteraktion. Keine Proxy-Session — eine vollstaendige Session, optimiert fuer gesprochene Konversation. Kurze Antworten, klare Saetze, TTS-freundlich.
Ideation Partner
Nimmt eine vage Idee und macht etwas Konkretes daraus. Recherchiert autonom, strukturiert, hinterfragt (Pre-Mortem). Das Ergebnis ist ein Anforderungspaket, kein Code.
Refinement
Macht Anforderungen praezise. Luecken-Audit, REQ-IDs, Akzeptanzkriterien. Kein Code — nur Spec. Die langweiligste und wertvollste Phase.
Cyber Factory
Der Builder. Architekturphase, Wellenplan, parallele Worker, Monitoring. Fuer grosse strukturierte Arbeit. Komplex, ressourcenintensiv, nicht fuer Kleinkram.
Workshop
Der Orchestrator fuer alles was nicht in die Pipeline passt. Bekommt Findings vom Testing Assistant, Bug-Reports, Feature-Requests — und verteilt sie sinnig: Triviales erledigt er selbst, Bugs gehen an den Debugger, groessere Themen an die Cyber Factory, Feature-Ideen an Ideation. Die Schaltzentrale nach dem Testing.
Testing Assistant
Systematisches Testen, adversariales Probing, Sicherheits-Audit. Fixt nichts — dokumentiert Findings und uebergibt sie an den Workshop zur Triage. Die Trennung zwischen Finden und Verteilen ist bewusst.
Debugger
Bekommt einzelne Bugs vom Workshop zugewiesen, analysiert Root Causes, fixt, verifiziert. Eskaliert wenn nach 2 Versuchen keine Loesung steht — zurueck an den Workshop, der entscheidet ob Cyber Factory oder User-Eskalation.
Audit
Reviewed Code, Sicherheit, ADR-Konsistenz. Gibt eine Release-Empfehlung: Release, Release nach Fix, oder Blockiert. Implementiert nichts.
Welche Entity wann?
Presets verstehen
Ein Preset ist eine vorkonfigurierte Rolle mit eigenen CLAUDE.md-Anweisungen. Die Schichtung dieser Anweisungen ist das Kernkonzept — sie bestimmt, wie sich eine Session verhaelt.
Die fuenf Schichten
Jede Session erhaelt ihre Anweisungen aus fuenf Schichten, die aufeinander aufbauen:
Werden in JEDE Session injiziert. Sicherheitsregeln, Tool-Grundregeln, TTS-Guardrails. Nicht editierbar pro Session.
Die preset.md der jeweiligen Entity — rollenspezifische Anweisungen, Phasen, Handoff-Regeln. Definiert WAS die Session tut.
Tonalitaet und Kommunikationsstil. Jedes Preset hat einen zugewiesenen Character — Relay fuer den Companion, Cipher fuer die Factory, etc. Definiert WIE die Session kommuniziert.
Wird in alle Sessions dieses Workspaces injiziert. Projektspezifischer Kontext, Konventionen, Verzeichnisse.
Nur fuer diese spezifische Zelle. Einmalige Anweisungen, Overrides, Sonderregeln.
Ordnerstruktur
Jede Entity hat ihr eigenes Verzeichnis unter ~/.config/cipher-mux/entities/:
- ›preset.md — die Haupt-Anweisungen der Rolle
- ›guides/ — ergaenzende Leitfaeden und Referenzen
- ›ref/ — Referenzmaterial, Beispiele, Templates
Builtin vs. Custom
Eingebaute Presets sind feststehend — du kannst sie nutzen, aber nicht veraendern. Eigene Presets legst du im Workspace-Editor an: Name, Prompt-Text, fertig. Wer tiefer einsteigen will, kann sich mit Hilfe von Claude Code einen vollstaendigen Preset-Ordner aufbauen — mit Guides, Referenzmaterial und spezialisierten Slash-Commands. Denn nicht nur der Prompt macht ein Preset besonders.
Personas (Characters)
Personas definieren WIE cipher-mux kommuniziert — Tonalitaet und Stil, nicht Funktion. Sechs sind eingebaut. Eigene legst du im Workspace-Editor an.
Global Override
Im Workspace-Editor kannst du eine Persona global aktivieren — dann gilt sie fuer alle Sessions, unabhaengig vom Preset. Nuetzlich wenn du gerade eine bestimmte Tonalitaet bevorzugst.
Eigene Personas
Name, Farbe und Prompt-Text — mehr braucht eine Persona nicht. Die eingebauten Personas sind editierbar, eigene kannst du beliebig viele anlegen.
Memory, Tags & Workspace-Scoping
cipher-mux hat zwei Systeme fuer Wissen, das ueber eine einzelne Session hinausgeht: Notes (sichtbar, teilbar) und Companion Memory (intern, automatisch).
Companion Memory
Was sich die KI ueber Sessions hinweg merkt. Drei Scopes:
Notes
Sichtbare, teilbare Wissensstuecke. Markdown-Dateien mit Tags. Du siehst sie in der Sidebar, kannst sie in Obsidian lesen, und Sessions koennen sie als Handoff-Medium nutzen.
Tags
Tags folgen dem Format klasse:wert — zum Beispiel workspace:CIPHER-MUX, kind:bugreport, status:open. Auto-Tagging per lokalem KI-Modell bei Cmd+S.
Workspace-Scoping
Wenn du einen Workspace aktivierst, passiert automatisch: Notes werden auf workspace:Name gefiltert. Prompts werden gescoopt. Kontext-Verzeichnisse werden gesetzt. Workspace wechseln = anderer Kontext, andere Notes, andere Tags.
Note vs. Memory — wann was?
Ehrlichkeit
Das hier ist kein Verkaufsprospekt. cipher-mux ist ein Werkzeug, das fuer manche Aufgaben gut funktioniert und fuer andere nicht.
Jede Session verbraucht API-Tokens. Parallele Sessions multiplizieren die Kosten. Ein Cyber-Factory-Run mit 5 Workern verbrennt Tokens schnell. Das ist nicht kostenlos.
Das Context Window ist endlich. Wenn es voll ist, komprimiert Claude aeltere Nachrichten. Information geht verloren. Es gibt keine magische Loesung — starte eine neue Session.
Manchmal findet der Testing Assistant die richtigen Dateien nicht. Manchmal bricht der Fix des Debuggers etwas anderes. Das System ist nur so gut wie die Prompts und das LLM.
cipher-mux wird von einer Person in der Freizeit gebaut. "I respond when I have time." Das ist kein Startup mit Support-Team.
Fuer eine schnelle Ein-Datei-Aenderung ist eine nackte Claude-Code-Session besser. Der Overhead von Entities, Presets und Lifecycle lohnt sich nur fuer strukturierte Arbeit mit mehreren Dateien.
Die ehrlichste Empfehlung: probier es aus. Wenn es dir hilft, nutze es. Wenn nicht, kein Verlust.
Weiter? Zum Nachschlagen.
Die vollstaendige Referenz zu jeder Funktion, jedem Button und jedem Menue findest du in der Nutzung der App.