Open-Source-Kanban-Desktop-App, die auf allen Karten parallele Agenten ausführt

 (kanbots.dev)
1 Punkte von GN⁺ 8 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • KanBots ist eine Desktop-App, die Claude Code und Codex parallel auf jeder Kanban-Karte ausführt und Fortschritt, Entscheidungen sowie Kosten in Echtzeit auf dem Board anzeigt
  • Jede Ausführung ist in einem separaten git worktree auf dem Branch kanbots/issue-N isoliert, und man kann ein Board erstellen, indem man einen Ordner hinzufügt und Agenten einzelnen Karten zuweist
  • Autopilot durchläuft Personas wie Product, Engineer, Reviewer und Tester mit einem maximalen Parallelitätsgrad von 4, teilt Aufgaben auf und aktualisiert den Backlog
  • Agenten halten an Punkten an, an denen eine Entscheidung nötig ist, schlagen Optionen vor, und Nutzer können mit Nummernauswahl, überarbeiteter erneuter Einreichung oder mit /spec, /review, /split fortfahren
  • Die Desktop-App setzt auf eine kostenlose MIT-Lizenz und einen Local-first-Ansatz; die Cloud bietet für 19 $ pro Sitz und Monat Team-Synchronisierung, Benachrichtigungen und Dashboards

Grundkonzept von KanBots

  • KanBots ist eine Desktop-App, die Claude-Code- und Codex-Agenten parallel pro Karte auf einem Kanban-Board ausführt
  • Jeder Agent läuft in einem separaten git worktree auf dem Branch kanbots/issue-N, und das Board aktualisiert Ausführungsfortschritt, Entscheidungsanfragen und Kosten in Echtzeit
  • Fügt man einen Ordner hinzu, wird ein Board erstellt, und man kann mehreren Karten Claude Code- oder Codex-Agenten zuweisen
  • Im automatischen Modus teilen Personas Aufgaben auf, führen sie parallel aus und prüfen die Ergebnisse
  • Die Desktop-App ist kostenlos, unter MIT lizenziert, spendenbasiert und arbeitet nach dem Local-first-Prinzip

Produktaufbau und Preise

  • Desktop OSS

    • Desktop ist Local-first, ohne Konto, ohne Telemetrie, dauerhaft kostenlos und unter der MIT-Lizenz verfügbar
    • Unterstützt macOS, Linux und Windows und enthält alle Funktionen
    • Zu den Hauptfunktionen gehören parallele Agentenausführung, automatische Ausführung, Entscheidungs-Prompts, eingebaute und benutzerdefinierte Personas, Echtzeit-Kostenanalyse, eine Recipe-Bibliothek, kanbots-mcp-server, Sentry-Import, GitHub-Issues-Modus, Branch-Vorschau, Erstellung von PR-Entwürfen, Unterstützung für Claude Code und Codex sowie ein Pre-Push-Hook

  • Cloud für Teams

    • Cloud ist ein gehostetes Mehrbenutzerprodukt, wobei die Agenten lokal auf der Hardware der Nutzer laufen
    • Der Preis beträgt 19 $ pro Sitz und Monat bzw. 190 $ bei jährlicher Abrechnung
    • Zusätzlich zu den OSS-Funktionen bietet es Echtzeit-Präsenz auf dem Board, Benachrichtigungen bei Team-Zuweisungen, Synchronisierung zwischen Geräten, Slack-Benachrichtigungen, organisationsweite Kostenaggregation, gemeinsames Bearbeiten von Karten in Echtzeit, ein organisationsweites Dashboard für Agentenaktivitäten und eine Managed GitHub App
    • Zu den Enterprise-Funktionen gehören Audit-Logs, SSO / SCIM, REST API und PAT sowie ausgehende Webhooks
    • Exklusive Cloud-Funktionen sind auf Features beschränkt, die andere Personen oder andere Geräte voraussetzen; Funktionen für eine einzelne Person auf einer einzelnen Maschine sind in OSS enthalten

Unterstützte Tools und Integrationen

  • Unterstützt die CLIs von Claude Code und Codex
  • Unterstützt GitHub Issues und PR-Arbeit
  • Unterstützt den Import von Sentry-Fehlern
  • Cursor und Claude Desktop lassen sich als MCP-Clients integrieren
  • Für lokalen Speicher wird SQLite verwendet
  • Die Desktop-Shell basiert auf Electron

Kernfunktionen

  • Parallele Kartenausführung

    • Agenten können gleichzeitig auf mehreren Karten laufen, wobei jede Ausführung in ihrem eigenen git worktree und auf dem Branch kanbots/issue-N stattfindet
    • Das Board aktualisiert Ausführungsfortschritt, Entscheidungsanfragen der Agenten und aufgelaufene Kosten in Echtzeit

  • Automatische Ausführung und Personas

    • Man kann Personas wie Product, Engineer, Reviewer und Tester verknüpfen und die Parallelität auf bis zu 4 einstellen
    • Ein Orchestrator durchläuft die Personas im Round-Robin-Verfahren, zerlegt übergeordnete Issues in Teilaufgaben und aktualisiert den Backlog mit Aufgaben, die von Agenten entdeckt wurden
    • Personas können andere Personas erzeugen

  • Entscheidungsorientierte Ausführung

    • Agenten halten an, wenn eine erforderliche Entscheidung ansteht, und zeigen Optionen an
    • Nutzer können mit Nummernauswahl, Bearbeitung und erneutem Einreichen oder mit Slash-Befehlen wie /spec, /review, /split fortfahren
    • Statt den Arbeitsbaum stillschweigend zu verändern, bleibt ein überprüfbarer Entscheidungsfluss erhalten

  • Integration von Claude Code und Codex

    • Claude Code oder Codex können auf demselben Board, im selben worktree und mit derselben Entscheidungs-UI verwendet werden
    • KanBots verarbeitet beide Stream-Formate hinter einem einzigen AgentCliAdapter
    • Vorhandenes claude /login oder OPENAI_API_KEY kann weiterverwendet werden

  • Local-first-Speicherung

    • Alle Daten befinden sich in .kanbots/ neben dem Repository
    • SQLite-Datenbank, Konfiguration und worktrees werden lokal gespeichert
    • Es gibt kein Cloud-Konto, keine Telemetrie und keinen HTTP-Server, und Code verlässt die Maschine nicht

  • Kostenanalyse und Budgetlimits

    • Bietet Kostenaggregation pro Ausführung, Karte und Projekt
    • Während der Agentenarbeit summiert sich ein Kostenmesser auf
    • Es lassen sich Limits pro Ausführung und pro Sitzung setzen; bei Erreichen des Budgets wird die Ausführung gestoppt

  • GitHub-Workflow

    • Mit einem persönlichen PAT können echte GitHub-Issues bearbeitet werden
    • worktrees lassen sich zu Commits hochstufen oder per Klick als Draft-PR öffnen
    • Ein Pre-Push-Hook verhindert, dass Agenten selbst veröffentlichen

  • MCP-Server

    • kanbots-mcp-server stellt das Board über das Model Context Protocol bereit
    • Cursor, Claude Desktop oder andere MCP-fähige Tools können mit dem Board arbeiten
    • Das Board wird zu einem Tool, das andere Agenten nutzen können

Interner Workflow der App

  • Autopilot

    • Man wählt eine oder mehrere Personas, setzt die Parallelität und startet dann die automatische Ausführung
    • Bis zu 4 parallele Slots durchlaufen die Persona-Liste im Round-Robin-Verfahren
    • Jeder Slot holt atomar die nächste Persona, und Agenten teilen laufende übergeordnete Issues in Teilaufgaben auf
    • Beendet wird bei Abschluss oder wenn das Sitzungsbudget erreicht ist
    • Im Beispielbildschirm sind Claude Opus 4.7, medium effort, Parallelität 2 sowie die Personas Product Manager und Senior Engineer ausgewählt

  • Decisions

    • Der Ausführungs-Thread streamt alle tool_use und tool_result in Echtzeit
    • Wenn Agenten an einen Punkt kommen, an dem ein Urteil nötig ist, pausieren sie und präsentieren nummerierte Optionen
    • Das Antwort-Eingabefeld akzeptiert Befehle wie /spec, /review, /split
    • Im Beispiel zur Implementierung eines Passwort-Reset-Tokens werden Optionen wie JWT zur Einmalverwendung, undurchsichtige in der DB gespeicherte Tokens, Magic Link oder zuerst eine Erklärung der Trade-offs angezeigt
    • Der Ausführungsbildschirm zeigt Modell, verstrichene Zeit, Token-Anzahl, Kosten, Status, Priorität, Ordner, worktree, Branch, Basis-Branch und Autor an

  • Personas

    • Eine Persona ist ein benanntes System-Prompt-Fragment
    • Standard-Personas sind in der App enthalten, und Nutzer können neue Personas schreiben, speichern und wiederverwenden
    • Benutzerdefinierte Personas werden lokal auf der jeweiligen Maschine gespeichert
    • Als Standardbeispiele werden Product Manager, Senior Engineer, UX Designer, Growth Lead und Reliability Engineer bereitgestellt

  • Providers

    • Claude Code und Codex können hinter einem einzigen AgentCliAdapter verwendet werden
    • Vorhandenes claude /login oder codex login wird wiederverwendet, ohne zusätzliche Konten oder zusätzliche Schlüsselverwaltung
    • Der Provider kann bei jeder Ausführung gewechselt werden
    • Für die Codex CLI muss codex im PATH liegen; Issue-Drafting und Sentry-Analyse laufen weiterhin in Claude
    • Für den Codex-Login kann im Browser auth.openai.com geöffnet oder die Umgebungsvariable OPENAI_API_KEY genutzt werden

  • Tasks

    • Neue Aufgaben bieten Vorlagen für Bugfixes, Features, Refactoring, Reviews und Spikes
    • Als Startart wählt man zwischen spec-first, sofortiger Ausführung nach Erstellung oder Einreihung in die Warteschlange für später
    • Der Titel wird als Branch- und PR-Titel verwendet
    • spec-first führt /spec aus, verfeinert Akzeptanzkriterien und belässt die Aufgabe im Zustand „Warten auf Freigabe“
    • Neue Aufgaben erzeugen einen frischen worktree und einen Branch unter .kanbots/worktrees/issue-N auf Basis von main

  • Chat

    • Es gibt einen allgemeinen Agenten, dem man Fragen zum Workspace stellen kann
    • Der Agent kennt Repository, Tests und Git-Status und beantwortet Fragen dazu
    • Gezeigt wird ein Beispiel, das API-Routen ohne rate limiting findet, rateLimit({ windowMs: 60_000, max: 10 }) zu /api/login und /api/signup hinzufügt und anschließend Tests schreibt und erfolgreich ausführt

Wie Autopilot arbeitet

  • Autopilot ist ein Modus, der Issues und ein Budget entgegennimmt und den Backlog selbstständig aktualisiert
  • Der Orchestrator durchläuft die Persona-Liste im Round-Robin-Verfahren und führt bis zu 4 Slots parallel aus
  • Er zerlegt übergeordnete Issues in Teilaufgaben und wiederholt den Zyklus, bis die Arbeit konvergiert oder das Kostenlimit erreicht ist
  • Das Beispiel zeigt Parallelität 4, das Modell opus 4.7, ein Sitzungsbudget von 25,00 $ mit bisher 4,27 $ Verbrauch sowie den Status des 14. Zyklus

  • Auswahl der Persona-Liste

    • Man kann Standard-Personas verwenden oder eigene System-Prompts definieren, speichern und wiederverwenden
    • Benutzerdefinierte Personas verlassen die Maschine nicht

  • Einstellung der Parallelität

    • Die Parallelität kann von 1 bis 4 eingestellt werden
    • Jeder Slot holt die nächste Persona atomar über einen Round-Robin-Zähler
    • Vier Agenten können gleichzeitig aus vier Perspektiven und in vier worktrees laufen

  • Aufgabenaufteilung

    • Wenn ein Agent Arbeit entdeckt, erstellt er neue Karten auf dem Board
    • Spätere Zyklen holen diese neuen Karten auf, während der Backlog unter dem Orchestrator wächst und schrumpft

  • Stopp bei Budget oder Abschluss

    • Ein sitzungsbezogenes Kostenbudget begrenzt die Gesamtausgaben
    • Die Stopp-Schaltfläche beendet die übergeordnete Ausführung und alle untergeordneten Ausführungen
    • Laufende Ausführungen beenden ihre aktuelle Iteration sauber

QA-Modus

  • QA-Modus führt typecheck, tests, lint, build und e2e innerhalb des worktree aus
  • Falls nötig, kann ein Entwicklungsserver gestartet und überwacht werden
  • Für jede fehlgeschlagene Prüfung wird in einem abgeleiteten Child-Issue eine Korrekturausführung zugewiesen
  • Dies wiederholt sich, bis die Prüfungen erfolgreich sind

Bereitstellung und Abschluss

  • Die OSS-Desktop-App wird kostenlos, unter MIT-Lizenz und ohne Konto bereitgestellt
  • Hervorgehoben wird ein Ablauf, der alle Agentenausführungen auf einem Kanban sichtbar, entscheidbar und isoliert macht
  • Wenn Teams ein Board gemeinsam nutzen müssen, können sie auf Cloud wechseln
  • Die Download-Formate sind macOS .dmg, Windows .exe, Linux .AppImage / .tar.xz

Verwandte Beiträge

1 Kommentare

 
GN⁺ 8 시간 전
Hacker-News-Kommentare

  • Ich frage mich weiterhin, wie Menschen die Ergebnisse aufnehmen, an denen Agenten über Nacht gearbeitet haben
    Selbst in privaten Side-Project-Repositories habe ich das Gefühl, dass das Ergebnis von 30 Minuten Planung und 30 Minuten Implementierung schon zu groß ist, um es zu prüfen. Nach etwa 5 Minuten lasse ich die AI manchmal von vorn anfangen, obwohl der Code noch hereinströmt.

    • Der aktuelle Narrativ konzentriert sich darauf, dass AI den gesamten oder den größten Teil des Codes schreibt, aber in Wirklichkeit nähert sich der Anteil des von Menschen geprüften Codes wahrscheinlich viel schneller der Null, als den Leuten bewusst ist oder als sie zugeben wollen.
    • Ein großer Teil solcher Agentenaktivität besteht darin, bereits Erstelltes zu durchforsten und harte Einschränkungen zu setzen, damit das Ergebnis, das später zur Review auf dem Tisch landet, einigermaßen vorhersagbar bleibt.
      Meiner Erfahrung nach hilft auch eine strenge Dateistruktur. Eine gerade erzeugte Datei mit 3.000 Zeilen zu prüfen ist furchtbar, und so etwas würde ich weder von Menschen noch von Maschinen annehmen. Wenn es stattdessen passend auf mehrere Dateien verteilt ist, sinkt die kognitive Last.
      Manchmal prüfe ich auch gemeinsam mit dem Agenten im Gespräch. Ich frage dann zum Beispiel, welche Datei ich mir zuerst ansehen sollte, weil sie am wichtigsten ist.
      Ich stage Änderungen gern erst einmal auf einen „LGTM“-Stapel. Wenn später noch etwas angepasst werden muss, sage ich dem Agenten: „Prüf die nicht gestagten Änderungen. Hier hätte ich gern einen anderen Ansatz.“
    • Niemand prüft den Code. Auch das Management will nicht, dass wir Code prüfen, weil es ein Bottleneck ist.
      Wenn etwas schiefläuft, also ein Bug auftaucht, wird es eben dann behoben. Das ist eine sehr traurige Zeit für Software Engineering. Falls es in unserer Branche einmal so etwas wie Engineering gab, ist davon inzwischen größtenteils nichts mehr übrig, und wir hantieren mit skills-Dateien wie „Bitte keine Bugs einbauen“ oder „Du bist kein Mieter, du bist Eigentümer“ und raten den Rest zusammen.
      Das Niveau des Aufwands ist niedrig, und die Deterministik ist extrem gering. Große Apps wie GitHub fallen wegen AI-Mülls immer wieder aus, und bei weniger bekannten Systemen sieht man das noch häufiger. Das gilt genauso für unsere Firma und andere SaaS-Produkte, die wir nutzen.
      Produktmanager haben sich nie wirklich für Code interessiert, und Engineering-Manager interessieren sich längst nicht mehr so stark dafür wie noch zu ihrer Zeit als Engineers. Direktoren kümmern sich überhaupt nicht um Code, und CTOs wissen inzwischen nicht einmal mehr, wie Code aussieht.
      Wir stehen am Ende dieser Kette und waren immer stolz auf gut geschriebenen, wartbaren Code, weil wir tief verinnerlicht hatten, dass gute Systeme auf gutem Code aufbauen. Jetzt bringen wir uns selbst in Gefahr, und ausgerechnet wir Engineers sind es, denen der Code inzwischen egal wird, während AI das Problem noch verstärkt.
    • Normalerweise ziele ich darauf, dass nach einer Nacht Arbeit von Claude am Ende nur etwa 500 Zeilen Code übrig bleiben.
      Die meiste Zeit geht dafür drauf, verschiedene Ansätze auszuprobieren und zusammenzufassen, um mir am Ende einen vergleichsweise kleinen Diff zu geben, den ich prüfen und überarbeiten kann.
    • Ich habe dieselbe Frage. Von Leuten, die das in der Praxis gut einsetzen, höre ich meistens, dass sie den Code gar nicht anschauen, zumindest nicht im Detail.
      Bei mir ist es allerdings so, dass ich an den Ergebnissen des Agenten fast immer noch etwas nacharbeiten muss. Ich frage mich, ob ich diese Kontrolle loslassen sollte.

  • Das erinnert mich an Vibe Kanban(https://vibekanban.com/), das ich bei den meisten Projekten zur Verwaltung von Coding-Agenten benutze.
    Leider sind die Entwickler von Vibe Kanban zu dem Schluss gekommen, dass kein sinnvoller Weg zur Monetarisierung sichtbar ist, und haben aufgehört, in das Projekt zu investieren. Es ist Open Source, man kann es also lokal ausführen oder forken, aber die Weiterentwicklung steht still, und es gibt noch einige lästige Bugs, die behoben werden müssten. Ich habe persönlich keine Zeit, es zu warten.
    Schade, denn ich wäre durchaus bereit gewesen, für Vibe Kanban zu zahlen. Ich brauchte nur die Funktionen des kostenpflichtigen Plans nicht. Rückblickend hätte ich vielleicht einfach trotzdem zahlen sollen.
    Ich werde Kanbots auf jeden Fall ausprobieren. Es könnte ruhig offensiv Funktionen von Vibe Kanban übernehmen. Besonders der Remote-Support und der Button „Open in VS Code“ sind für mich zentral. Bei mir öffnet dieser Button einen lokalen VSCode-Client, der auf einen entfernten VSCode-Server zeigt.

    • Vibe Kanban ist in Bezug auf nützliche Funktionen wirklich eine Schatzkammer.
      Ich arbeite seit ein bis zwei Wochen daran, ein neues Tool auf Funktionsparität mit VK zu bringen und darüber hinaus noch Verbesserungen einzubauen. Im Vibe-Kanban-Discord habe ich auch schon ein paar Screenshots gepostet. Wenn alles releasebereit ist, hoffe ich, dass es auch gut zu deinem Anwendungsfall passt.
      Mein Tool zielt darauf, sowohl beim Kanban-Board als auch beim Agent-Workspace bessere Funktionen als VK zu bieten, und ergänzt das Ganze um zusätzliche Systeme wie Desktop-Fensterverwaltung, Plugins, VSCode-Integration im Browser und eine serverseitig gerenderte UI ähnlich htmx.
      Auch der Remote-Ansatz ist anders. Statt auf dem Laptop einen Webserver zu starten, um auf einen entfernten Coding-Agenten zuzugreifen, wird wie bei OpenClaw alles gehostet, und man greift im Browser auf eine Remote-Desktop-UI zu.

  • Dass es lokal zuerst, ohne Server funktioniert — alles liegt neben dem Repository in .kanbots/: SQLite-Datenbank, Einstellungen, Worktrees. Kein Cloud-Konto, keine Telemetrie, kein HTTP-Server. Dass dies die Open-Source-Desktop-Edition ist — das ist für mich eine Grundvoraussetzung, wenn ich die Einführung solcher Tools überhaupt in Betracht ziehe.

    • Ich weiß nicht, was mit „solchen Tools“ gemeint ist.
      Wenn AI agentisch arbeitet, sollte jeder Produktmanager nach einem einstündigen Gespräch in der Lage sein, Jira mit irgendeiner Agent-Loop zu integrieren.
      Jira, Trello, Linear und Basecamp haben alle APIs, und vermutlich gibt es auch CLI-Tools, die ein Agent nutzen kann. Man sollte dafür weder einen Entwickler noch ein SaaS brauchen, um einem System beizubringen, dass es beim Starten einer Aufgabe das Ticket auscheckt, die Anweisungen enthält und es nach Abschluss auf DONE verschiebt.
    • Auf der Seite steht, dass man sich selbst für lokale Nutzung mit einem Cloud-Konto anmelden muss, damit diese Funktion überhaupt läuft, deshalb habe ich es nicht ausprobiert.
      Ehrlich gesagt sieht es ziemlich cool aus. Aber es gibt schon einige Tools, die cool aussehen.

  • Ursprünglich wurde das Wort „Kanban“ von Toyota verwendet, um ein Kartensystem zu beschreiben, das mehrere wichtige Ziele erfüllte, etwa nicht zu viele Dinge gleichzeitig zu bearbeiten und Arbeit sichtbar zu machen.
    Insgesamt wurde Kanban dazu genutzt, den Arbeitsfluss so zu steuern, dass keine Fehler durchrutschen.
    Dieses Tool kommt mir dagegen eher vor wie „so viel parallel erzeugte Arbeit wie möglich hineinstopfen“. Es steuert keinen Fluss qualitativ hochwertiger Ergebnisse und begrenzt die Arbeit auch nicht. Es wirft einfach alles den Agenten vor und verbrennt Token wie verrückt.
    Dass man so etwas „Kanban“ nennt, finde ich wirklich unerquicklich. Es wirkt fast wie Blasphemie.

  • Wenn ich Agenten unbeaufsichtigt laufen lasse, habe ich mehr Frust als Erfolg erlebt.
    Ich glaube zwar, dass die Technik irgendwann so weit sein wird, aber im Moment braucht jeder Agent seine eigene IDE, und auch das Zusammenführen der Arbeit ist mühsam.

  • Ich teile hier ein aktuelles Open-Source-Projekt: ein Kanban-Board mit parallelen Agenten.
    Ich möchte es mit mehr Funktionen verbessern, und ich würde mich über Beiträge zum Repository freuen — egal ob Code oder Ideen.

    • Gute Arbeit. Ich habe schon einmal versucht, ein eigenes Agentensystem Kanban über ein bestehendes Jira-Projekt laufen zu lassen, sortiert nach Workflows, daher freue ich mich, dieses Projekt heute auf HN zu sehen.
      Es dürfte Spaß machen, die Entwicklung weiterzuverfolgen.
    • Du solltest dir den minions-Artikel im Stripe-Entwicklerblog ansehen. Die Richtung scheint ähnlich zu sein.

  • Ist das nicht im Grunde das, was Windsurf ohnehin macht? Letztlich sind all diese UIs doch nur Fassade auf einem Agenten obendrauf.
    [0] https://windsurf.com/blog/windsurf-2-0

    • Es gibt einige Apps, die dabei helfen, Aufgaben von einem Kanban-Board an Agenten zu übergeben.
      Ich brauchte eher einen menschlicher eingebundenen Ablauf. Einfach an einen Agenten zu übergeben, ohne die Changesets gut sehen oder die Richtung noch ändern zu können, passt für mich nicht.
      https://www.agentkanban.io verbindet über eine Extension ein Task-Board mit GitHub Copilot Chat in VS Code, sodass man sowohl Aufgabenverwaltung als auch die Erfassung von Kontext bekommt, der von Chats zu konkreten Tasks führt. Dadurch kann man die Vorteile von VS Code als übergeordneter Ausführungsumgebung und zugleich die Funktionen für Aufgaben- und Projektmanagement nutzen.
    • Ich sehe hier kein Problem. Gibt es eines?
      Linear arbeitet selbst direkt in diese Richtung.
    • Ist Windsurf Open Source?

  • Was ich bei diesen Tools nicht verstehe, ist, wie sie das Hochfahren der Infrastruktur für unterschiedliche Worktrees handhaben.
    Wenn man zum Beispiel eine Web-App hat, müsste jeder Worktree seine eigene Infrastruktur starten und unter einer eigenen lokalen URL erreichbar sein. Nur so kann man die Änderungen jedes Worktrees lokal ansehen oder einem Agenten etwa mit agent-browser die visuelle Prüfung automatisieren lassen.
    Ich nutze derzeit Docker für die Infrastruktur, und jeder Service läuft in seinem eigenen Container. Es gibt ein Skript ./app worktree create worktreename, das einen Worktree namens „worktreename“ anlegt und dann die komplette Docker-Infrastruktur mit einem Präfix wie „WORKTREENAME“ hochfährt. Dadurch sind alle URLs unter worktreename.myapp.test erreichbar, während der Haupt-Worktree einfach myapp.test nutzt.
    Im Moment funktioniert das gut, aber es wäre schön, wenn eine dieser Apps mit diesem Konzept kompatibel wäre, damit ich dorthin wechseln könnte.

    • Wir hatten bei der Arbeit dasselbe Problem und ich habe CC gebeten, ein sehr einfaches bun-CLI-Tool zu bauen, das Worktrees anlegt, löscht und auflistet.
      Dieses CLI trägt die passende URL und Datenbank für den jeweiligen Worktree in die .env-Datei ein und startet mit dem Open-Source-Paket portless von Vercel einen Dev-Server auf einem eindeutigen Port. So bekommt jeder Worktree seine eigene URL.
    • Du solltest dir emdash.sh anschauen. Jede Aufgabe bekommt dort ihren eigenen Worktree, und vordefinierte Umgebungsvariablen werden injiziert.
      Dazu gehört auch EMDASH_PORT, ein eindeutiger Port innerhalb eines Bereichs von 10 Ports. Das ist sehr nützlich, wenn man in einem einzelnen Monorepo mehrere Services ausführt.
    • Ich nutze Shell-Skripte zum Anlegen und Entfernen von Worktrees.
      Das Shell-Skript sucht unter allen vorhandenen Worktrees einen freien eindeutigen Port und weist ihn beim Erstellen des Worktrees der lokalen .env zu. Wenn der Worktree gemergt und entfernt wird, wird auch der Port wieder freigegeben.
      Secrets, die nicht worktree-spezifisch sind, speichere ich nicht in der lokalen .env, sondern injiziere sie per Shell.
      Ehrlich gesagt war es sehr einfach, solche lokalen Skripte zur Automatisierung der Entwicklungsarbeit zu schreiben, und sie lassen sich gut mit allen anderen CLI-Tools kombinieren. Deshalb habe ich bisher noch keine GUI-App ausprobiert. Ich weiß nicht, ob sie mit einer maßgeschneiderten lokalen Konfiguration konkurrieren kann, die genau so funktioniert, wie ich es will.
    • Warum nicht einfach direnv verwenden? Den Port für das Hosting lokaler Seiten müsste man zwar anpassen, aber man könnte auf Basis eines Hashs des Worktree-Namens N=mod(...) berechnen und dann port=default_port+N setzen.
      Lass es einfach Claude konfigurieren. Das sollte mit einem einzigen Prompt gehen.

  • „‚kanbots‘ ist beschädigt und kann nicht geöffnet werden. Es sollte in den Papierkorb bewegt werden.“
    Ein Fehler, der kaum besser dazu passen könnte, wenn man ihn zum ersten Mal bei Vibe-Coding-Software sieht.

  • Ist das nicht einfach vibe-kanban?
    https://github.com/BloopAI/vibe-kanban

    • Konkurrenz darf es geben.
    • Es ist buchstäblich bei Bloop gehostet. Das ist das Original von Bloop.