Nebenprojekt · Mai 2026

Ein 5-Personas-Claude-Code-Dev-Squad.

DevSwarm ist ein FastMCP-Server, der fünf persistente Claude-Code-Persona-Sessions (Architect, Researcher, Frontend, Backend, Reviewer-Deployer) orchestriert, um aus einem Prompt einen Pull Request zu machen. Fire-and-forget: starten Sie es mit einem einzigen MCP-Aufruf, klappen Sie den Laptop zu, wachen Sie zu einem PR auf. Kein Docker, kein Daemon, kein Port; nur Dateien auf der Platte und stdio MCP. Ende-zu-Ende auf einem Fedora-Server in einem einzigen Nachmittag gebaut.

Zurück zu den Projekten → Was es gebaut hat

5 Personas 6 MCP-Tools 4m 42s Capstone-Build Opus 4.7 über alle Personas ~3 h Build-Zeit, ein Nachmittag

Die Prämisse

Eine Idee um 23 Uhr. Ein Pull Request am Morgen.

Eine einzelne Claude-Code-Session ist bereits ein fähiger Ingenieur. Aber sie arbeitet eine Sache nach der anderen (lesen, planen, codieren, prüfen) im selben Kontextfenster, mit denselben Prioritäten, auf derselben Uhr wie der Mensch, der davor tippt. DevSwarm ist ein kleines Experiment, diese Arbeit auf persistente spezialisierte Agenten zu verteilen, die über Dateien auf der Platte übergeben, in eigenen Sessions laufen und niemanden brauchen, der zusieht.

Der Endzustand, den ich wollte: Sie haben spät nachts eine Idee, Sie sagen sie einmal, und Sie wachen zu einem Pull Request auf, den Sie lesen, annehmen oder zurückschicken können. Kein Babysitting. Kein "der Schwarm hat sich nach drei Schritten verhakt." Der Orchestrator löst sich vom Aufrufer; Status lebt in einer JSON-Datei auf der Platte; Sie können das Terminal schließen und am nächsten Morgen wiederkommen.

Architektur

Reine Dateien auf der Platte, plus stdio MCP.

Der MCP-Server ist eine einzige Python-Datei. Jede Persona ist eine echte claude-Session, an eine UUID gebunden und per Subprozess fortgesetzt. Der Runner ist ein detached-Prozess (start_new_session=True), der fünf Stufen abläuft und den Zustand nach jeder in .swarm_state.json serialisiert. Frontend und Backend laufen in parallelen Threads. Kein Daemon, kein Port, kein Container.

Sie (Terminal, Brille, überall mit Claude Code)
      ↓ MCP-Aufruf: devswarm.start_project(idea, repo_url)
┌────────────────────────────────────┐
│  devswarm_mcp.py  (FastMCP, stdio) │   ← bei Bedarf gestartet
└─────────────┬──────────────────────┘
              ↓ subprocess.Popen(start_new_session=True)
┌────────────────────────────────────┐
│  runner.py   (detached, PPID=1)    │   ← überlebt MCP-Tod
└─────────────┬──────────────────────┘
              ↓ für jede Stufe: claude --resume <uuid> -p ...
      ┌──────┴──────┬──────────┬──────────┬──────────────┐
      ↓             ↓          ↓          ↓              ↓
  Architect    Researcher   Frontend   Backend      Reviewer-
  → PLAN.md    → RESEARCH   → Code     → Code       Deployer
                  .md         in fe/     in be/     → REVIEW.md
                                                    → gh pr create
              ↓
       Zustand lebt in workspace/<id>/.swarm_state.json
       jederzeit prüfen über get_project_status(id)

Die fünf Personas

Fünf Sessions, fünf Tool-Sets.

Jede Persona ist eine separate Claude-Code-Session, die in einem eigenen Arbeitsverzeichnis mit eigenem CLAUDE.md-System-Prompt und eigener settings.json-Tool-Allow-Liste lebt. Tool-Isolation wird hart in der Settings-Schicht erzwungen, nicht nur im Prompt versprochen.

Architect

Schreibt PLAN.md · read-only

Liest die Idee des Nutzers, wählt den Stack, definiert Dateilayout, API-Verträge, DB-Schema, Aufgabenaufteilung, Akzeptanzkriterien. Kein Code. Keine Bash.

Researcher

Schreibt RESEARCH.md · read + web

Sucht nach Libraries, Mustern, ähnlichen OSS-Projekten, bekannten Stolpersteinen, Sicherheitsfallen für das, was der Architect spezifiziert hat. Schwer auf Zitate.

Frontend

Baut frontend/ · bash + edit

Implementiert die UI-Seite von PLAN.md. Hat Bash- und Schreibzugriff, aber ist hart von git push und jedem GitHub-Write-MCP geblockt.

Backend

Baut backend/ · bash + edit

Implementiert API, Server, DB-Migrationen. Gibt bei statischen Projekten NOT_REQUIRED zurück, sodass die Pipeline ihn sauber überspringt. Gleicher git-push-Block wie Frontend.

Reviewer-Deployer

Schreibt REVIEW.md + öffnet PR · volles gh

Lässt Lint und Tests laufen, verifiziert jedes Akzeptanzkriterium Befehl für Befehl, klont dann (und nur dann) das Ziel-Repo, erstellt einen devswarm/<id>-Branch, committet, pusht und öffnet einen PR per gh pr create. Die einzige Persona mit GitHub-Schreibzugriff.

Der Capstone-Test

4 Minuten 42 Sekunden, ein Prompt zu einem PR.

Der erste End-to-End-Live-Test, keine händischen Edits: ein einseitiges CV mit Dark-Mode-Schalter, Fade-in-on-Scroll und Respekt vor prefers-reduced-motion. Jede Stufe gelang im ersten Anlauf.

ArchitectPLAN.md: Stack, Dateilayout, API-Verträge, Akzeptanzkriterien28 s

ResearcherRESEARCH.md: Libraries, Muster, Stolpersteine, Sicherheit1 m 31 s

Frontendindex.html: Theme-Init ohne Flash, CSS-Variablen, IntersectionObserver59 s

BackendNOT_REQUIRED · statische Seite, keine API9 s

ReviewerREVIEW.md: 14 Akzeptanzprüfungen · clone · commit · push · PR öffnen1 m 44 s

Unten: die exakte index.html, die der Schwarm geschrieben hat, live gerendert. Probieren Sie den Theme-Schalter oben rechts im Rahmen, scrollen Sie, um zu sehen, wie die Fade-in-Animation auf jeder Sektion feuert.

/projects/cv-onepager-artifact.html, wörtlich aus der Workspace-Ausgabe des Schwarms. PR ansehen ↗

Stack & Status

Ehrlich über das, was drin ist.

Sprache: Python 3.14, handgeschriebener FastMCP-Server in ~260 Zeilen (devswarm_mcp.py), dazu Runner (runner.py) und gemeinsame State-Helfer (swarm_state.py).
Agenten-Modell: claude-opus-4-7 über alle fünf Personas. Sessions persistiert als JSONL unter ~/.claude/projects/<encoded>/<uuid>.jsonl, fortgesetzt per claude --resume <uuid> -p ....
Tool-Isolation: Pro-Persona .claude/settings.json mit expliziten Allow/Deny-Mustern. Frontend/Backend hart geblockt von git push, gh pr, allen mcp__github__*-Writes. Notion-Writes für jede Persona verweigert.
Nebenläufigkeit: Python-threading für die parallele Frontend-+-Backend-Stufe. State-Schreibvorgänge nutzen eindeutige tmp-Dateinamen plus prozessweiten Lock, sodass das Read-Modify-Write innerhalb von update_stage keine Updates verliert.
Deploy: Reviewer-Deployer nutzt die gh-CLI mit der vorhandenen Auth des Nutzers. Die PR-URL wird in .pr_url im Workspace abgelegt; der Runner hebt sie auf und gibt sie in get_project_status aus.
Quelle: Noch nicht in einem öffentlichen Repo; lokal gehalten, während sich die API stabilisiert. Landet voraussichtlich unter github.com/tomscholtes93-collab/devswarm, sobald ein paar weitere Capstones sauber durchlaufen.