Pairdown

Mehrspieler-Markdown, mit Agenten im Raum.

Ein Server hält jedes Dokument. Menschen öffnen einen Link und bearbeiten dasselbe Dokument gemeinsam, live, und hinterlassen Kommentare am Rand. Jeder im Raum kann seine eigene Claude-Code-Sitzung mitbringen – sie erscheint als benannter Teilnehmer, bleibt still, bis jemand sie erwähnt, und antwortet dann im Thread, in den sie gerufen wurde.

Es funktioniert im Browser ohne Installation. Räume, Bearbeitung, Kommentare und Teilen funktionieren alle ohne angeschlossenen Agenten; das Claude-Code-Plugin ist die optionale Möglichkeit, eine Sitzung anzuhängen, und es hält das Dokument selbst nie.

Server ausführen

Zum Hosten brauchst du einen Checkout und bun:

bun install
bun run build          # bundles the browser client into public/js
bun run src/server.ts  # http://127.0.0.1:8790

Ein Prozess bedient jeden Raum. / ist der Raumindex – jeder Raum auf dem Server, verlinkt auf sein eigenes /r/<id>, mit einem Formular zum Erstellen. Räume bleiben unter data/rooms/ erhalten, eine Datei pro Raum, und überleben den Prozess.

Related MCP server: agent-room-mcp

Einen Agenten mitbringen

Installiere das Plugin aus diesem Repository – das Repository ist sein eigener Marktplatz, also sind das zwei Befehle statt einem:

claude plugin marketplace add rohanrichards/pairdown
claude plugin install pairdown@pairdown

Die Installation fragt nach vier Dingen, und die ersten beiden sind wichtig:

Ändere später alles davon mit /plugin configure pairdown.

Du brauchst node (22 oder neuer) in deinem PATH. Du musst nicht dieses Repository klonen oder seine Abhängigkeiten installieren – der Agent wird als einzelne gebündelte Datei ausgeliefert und läuft direkt daraus.

bun wird nur zum Hosten eines Raum-Servers benötigt, weil der Server auf Bun.serve aufbaut. Einen Agenten in den Raum eines anderen zu bringen, braucht es nicht.

Für die Arbeit am Plugin selbst lädt claude --plugin-dir . es aus einem Checkout ohne Installation und übernimmt deine Änderungen bei /reload-plugins.

Das Plugin führt einen MCP-Server aus, der sich als Client mit dem Raum-Server verbindet. Seine pairdown-Binärdatei, bei aktiviertem Plugin im PATH, startet den Raum-Server bei Bedarf, falls er noch nicht läuft.

Sobald es angeschlossen ist, ruft eine Sitzung room_list auf, dann room_create oder room_join, und arbeitet dann mit read, outline, search, edit, append, insert, comments, reply und resolve.

Ein Agent ist ruhend, bis er benannt wird. Nichts erreicht eine Sitzung, außer ein Kommentar erwähnt ihr Handle, also ist ein Raum mit vier Agenten so ruhig wie ein Raum ohne, bis jemand nach einem von ihnen fragt.

Dieselben vier Einstellungen sind Umgebungsvariablen, um den Agenten außerhalb des Plugins auszuführen:

Eine Umgebungsvariable gewinnt gegenüber der Plugin-Einstellung mit demselben Namen, so führst du einen zweiten Agenten unter einem anderen Handle aus, ohne deine Konfiguration anzufassen:

PAIRDOWN_AGENT=scout PAIRDOWN_OWNER=Rohan claude

Aktualisieren

Die Installation verschiebt eine bestehende Installation nicht auf eine neuere Version – sie meldet, dass das Plugin bereits installiert ist, und lässt die laufende Version unangetastet. Um ein neues Release zu übernehmen:

claude plugin marketplace update pairdown
claude plugin uninstall pairdown@pairdown
claude plugin install pairdown@pairdown

Prüfe, was tatsächlich läuft, mit claude plugin list; es ist die Versionsnummer dort, die zählt, nicht was im Cache liegt.

Das Erwähnen eines Handles benachrichtigt diese Sitzung sofort; ein unmarkierter Kommentar wartet, bis jemand „an claude senden" drückt. Sofortige Benachrichtigung benötigt zusätzlich die Channels-Research-Vorschau, und bei Team/Enterprise muss ein Org-Admin channelsEnabled setzen – ohne das wird die Benachrichtigung still verworfen und alles andere funktioniert weiter.

Die Abschottung mit gemeinsamem Schlüssel

Das Setzen von PAIRDOWN_SECRET stellt den gesamten Server hinter einen Schlüssel: Browser bekommen ein Formular und dann ein Sitzungs-Cookie, Agenten und Skripte senden Authorization: Bearer <key>. Ohne den Wert ist der Server offen, genau wie zuvor.

PAIRDOWN_SECRET="$(openssl rand -base64 32 | tr -d /+= )" bun run src/server.ts

Das ist Authentifizierung, keine Autorisierung. Ein Schlüssel bedeutet, dass alle, die ihn haben, dasselbe Subjekt sind: niemand kann unterschieden werden, niemand kann einzeln gesperrt werden, und jeder Raum auf dem Server steht hinter derselben Tür. Es existiert, damit eine beaufsichtigte Demo durch einen Tunnel laufen kann, ohne die Kiste dem zu überlassen, der die URL findet. Es ist kein Weg, einen Server dauerhaft laufen zu lassen.

Was es richtig macht, ist der Teil, den diese Art von Abschottung normalerweise falsch macht: der Vergleich ist in konstanter Zeit, das Cookie trägt einen HMAC des Schlüssels statt des Schlüssels, und das Websocket-Upgrade ist zusammen mit den Seiten abgeschottet – die HTML-Seiten abzuschotten, aber nicht /ws, würde die Tür abschließen und das Fenster offen lassen.

Test

bun test
bun run src/smoke.ts

smoke.ts seedet einen Wegwerf-Raum, startet den MCP-Server dagegen und treibt die gesamte Werkzeugoberfläche Ende zu Ende.

Noch nicht hier

Konten, SSO, Berechtigungen pro Raum, Hosting. Lokal zuerst, ein Tunnel zum Demonstrieren.

Siehe docs/superpowers/specs/2026-08-19-spec-room-design.md für das Design. Es und der Plan daneben sind datierte Aufzeichnungen, die unter dem ersten Namen des Projekts geschrieben wurden, und sind so belassen, wie sie waren.