Claude Squad vs. Conductor vs. tmux: DIY-Agent-Setups

Du hast angefangen, zwei Coding-Agents gleichzeitig laufen zu lassen, weil einer zu langsam war. Jetzt sind es fünf, und der schwierige Teil ist nicht das Starten. Es ist die Frage, welches Terminal welchen Agent beherbergt, was jeder einzelne geändert hat, welcher Branch sicher gemergt werden kann und ob der, der vor vierzig Minuten verstummt ist, fertig geworden ist oder sich aufgehängt hat. Die Parallelität war der einfache Gewinn. Den Überblick zu behalten, ist die Steuer, die du jeden Tag danach zahlst.

Genau diese Steuer versuchen die DIY-Tools für parallele Agents zu senken. Conductor, Claude Squad und selbst geschriebene tmux-plus-git-worktree-Skripte lösen alle dasselbe erste Problem: Geb jedem Agent seinen eigenen isolierten Arbeitsbereich, damit mehrere Runs gleichzeitig laufen können, ohne sich gegenseitig in die Dateien zu pfuschen. Das machen sie gut, und für einen Solo-Entwickler auf einer einzigen Maschine können sie alles sein, was du brauchst. Dies ist eine ehrliche Übersicht darüber, was jedes Tool leistet, wo jedes an seine Grenzen stößt und wo aus Fensterverwaltung still und leise ein Teamproblem wird.

An genau dieser Grenze kommt Sharkly ins Spiel, und dieser Workflow ist es, den der vorliegende Artikel Schritt für Schritt durchgeht. Sharkly ist kein Ersatz für Claude Code, Codex oder irgendeinen DIY-Runner. Es ist die gemeinsame Task-, Computer-, Kontext- und Review-Ebene rund um die Tools, die du bereits einsetzt, damit Agent-Arbeit vom Request bis zum Release sichtbar bleibt, statt in privaten Terminals zu verschwinden. Wenn dein Setup noch auf einen Bildschirm passt, behalte es. Wenn das schon vor Wochen aufgehört hat, ist die zweite Hälfte dieses Artikels für dich.

TL;DR

Conductor, Claude Squad und rohes tmux plus git worktrees sind drei Wege, mehrere KI-Coding-Agents parallel auf deiner eigenen Maschine laufen zu lassen. Conductor ist eine kostenlose Mac-App für Solo-Runs auf dem lokalen Rechner. Claude Squad ist eine plattformübergreifende Terminal-App, die einen Switcher über tmux-Sessions und git worktrees legt. Rohes tmux plus Worktree-Skripte geben dir volle Kontrolle und null Abstraktion. Alle drei beherrschen die parallele Ausführung. Keines davon wurde gebaut, um einem Team gemeinsame Sichtbarkeit, Review oder Übergaben zu ermöglichen, und genau an diesem Punkt steigst du auf eine Orchestrierungsebene wie Sharkly um.

Der eigentliche Engpass ist nicht die Parallelität

Isolation ist ein gelöstes Problem. Ein git worktree erlaubt es einem Repository, mehrere Branches gleichzeitig in separate Verzeichnisse auszuchecken, sodass jeder Agent seine eigene Codekopie bearbeitet und auf seinen eigenen Branch committet. Kein gemeinsamer Working Tree, keine halb angewendeten Diffs, die kollidieren. Jedes Tool in diesem Vergleich steht auf genau diesem Primitiv. Wenn du die Mechanik im Detail willst, deckt unser Leitfaden zu git worktrees mit KI-Coding-Agents die Befehle und die Stolperfallen ab.

Wenn Isolation also gratis ist, warum fühlt sich das Betreiben vieler Agents trotzdem chaotisch an? Weil die Arbeit, die ein Agent produziert, irgendwo landen muss, wo ein Mensch sie finden, lesen, beurteilen und darauf reagieren kann. Auf einer einzelnen Maschine ist dieses „irgendwo“ dein eigenes Kurzzeitgedächtnis plus ein Scrollback-Puffer. Bei zwei Agents hält das. Bei fünf beginnt es zu bröckeln. Und es bricht in dem Moment zusammen, in dem eine zweite Person wissen muss, was deine Agents getan haben.

Hier ist die Unterscheidung, auf die es ankommt. Agents parallel laufen zu lassen, ist ein Laufzeitproblem: Prozess starten, ihm ein isoliertes Verzeichnis übergeben, arbeiten lassen. Das Reviewen und Koordinieren dessen, was sie produzieren, ist ein Workflow-Problem: Wo lebt das Ergebnis, wer akzeptiert es, was passiert mit denen, die hängen bleiben. Die DIY-Tools sind hervorragend beim ersten Problem. Die drei folgenden Abschnitte bewerten jedes für sich, und danach schauen wir, was mit dem zweiten Problem passiert, wenn dein Setup wächst.

Conductor: die kostenlose Mac-App für parallele Solo-Runs

Conductor ist eine native Mac-Desktop-App, mit der du mehrere Claude-Code-Agents nebeneinander laufen lassen kannst. Du zeigst ihr ein Repository, beschreibst eine Änderung, und sie startet jeden Run in seinem eigenen Arbeitsbereich, der durch einen git worktree gestützt wird. Statt mit Terminal-Tabs zu jonglieren, bekommst du eine Fensteransicht: eine Spalte pro Agent, jede mit eigener Konversation, eigenem Diff und eigenem Status. Du klickst dich durch sie wie durch Chats.

Was es gut macht, ist die Terminal-Buchhaltung für eine einzelne Person zu beseitigen. Du tippst kein tmux irgendwas. Du musst dir nicht merken, welcher Pane welcher ist. Die App verfolgt die Worktrees, zeigt dir Diffs in einem echten Diff-Viewer und lässt dich zwischen Agents springen, ohne den Faden zu verlieren. Für einen Solo-Entwickler auf einem Mac, der drei oder vier Claude-Code-Sessions auf einer Codebasis laufen lassen und dabei geistig gesund bleiben will, ist das eine saubere Antwort mit geringer Reibung. Der Download ist kostenlos, und es gibt nichts auf einem Server zu konfigurieren, weil es keinen Server gibt.

Die Grenzen sind die Kehrseite dieser Stärken. Conductor läuft nur unter macOS, ein Linux-Teamkollege kann dein Setup also nicht nutzen. Es ist um Claude Code als Laufzeit herum gebaut, nicht um einen Mix aus Agents. Und es ist eine Single-User-Desktop-App: Die Arbeitsbereiche, die Diffs und die Entscheidungen leben auf deinem Mac. Ein anderer Entwickler kann deinen Conductor nicht öffnen und sehen, was deine Agents tun, und es gibt keine gemeinsame Aufzeichnung darüber, wer welche Änderung akzeptiert hat. Das ist kein Mangel. Es ist ein bewusst gewählter Umfang. Conductor ist ein Cockpit für einen einzigen Piloten.

Nutze Conductor, wenn du ein Solo-Entwickler auf einem Mac bist, Claude Code ausführst und den schnellsten Weg von „vielen Terminals“ zu „einem ruhigen Fenster“ willst. Greif zu etwas anderem, wenn eine zweite Person einen dieser Runs sehen, reviewen oder übernehmen muss.

Claude Squad: tmux und Worktrees mit einer TUI obendrauf

Claude Squad ist eine quelloffene Terminal-Anwendung, die mehrere Agents in isolierten Arbeitsbereichen verwaltet. Unter der Haube tut sie das, was ein sorgfältiger Entwickler von Hand skripten würde: Sie legt pro Agent einen git worktree an und lässt jeden Agent in seiner eigenen tmux-Session laufen, dann legt sie eine Text-UI darüber, damit du deine Agents auflisten, in einen beliebigen wechseln und sehen kannst, welche arbeiten, warten oder fertig sind. Sie ist plattformübergreifend, läuft unter macOS und Linux und ist nicht an eine einzige Laufzeit gebunden. Sie kann Claude Code, Codex, Aider und andere CLI-Agents steuern, was sie bei Entwicklern, die Tools mischen, beliebt macht. Der Quellcode liegt im Claude-Squad-Repository auf GitHub.

Der Reiz liegt darin, dass sie dir die Ergonomie eines echten Tools gibt, ohne die Primitive zu verstecken, denen du vertraust. Du bekommst weiterhin Worktrees und tmux, nichts ist Magie und alles ist inspizierbar, aber du hörst auf, den Kleber von Hand zu schreiben. Einen neuen Agent hochzufahren ist ein Tastendruck, kein Drei-Befehle-Ritual. Einen Agent pausieren gibt seine Ressourcen frei und bewahrt seinen Branch. Wenn du ohnehin im Terminal lebst und eine Flotte von Agents willst, durch die du durchtabben kannst, trifft Claude Squad einen Sweet Spot, den rohe Skripte und Desktop-Apps beide verfehlen. Unser Walkthrough dazu, wie man mehrere Claude-Code-Agents parallel laufen lässt, zeigt dasselbe tmux-und-Worktree-Muster, das es automatisiert.

Seine Grenzen sind die Grenzen des Terminals, in dem es lebt. Der Zustand ist lokal auf deiner Maschine und in deiner Shell. Wenn du die Session schließt, schließt sich das gemeinsame Bild mit ihr. Es gibt keine Timeline, die ein Manager öffnen kann, keinen Ort, an dem ein Reviewer, der nicht du bist, eine Änderung annehmen oder ablehnen kann, keine Warteschlange, aus der ein Teamkollege die nächste Aufgabe ziehen kann. Claude Squad ist ein hervorragendes Kommandozentrum für einen einzigen Bediener. Es hat nie versucht, das System of Record eines Teams zu sein, und es dazu zu machen, heißt das falsche Tool zu fragen.

Nutze Claude Squad, wenn du ein Terminal-First-Entwickler bist, einen Mix aus Agents auf einer Maschine laufen lässt und einen schnellen Switcher willst, ohne Worktrees und tmux aufzugeben. Greif zu etwas anderem, wenn die Runs anderen Personen zuweisbar sein müssen oder von jemandem reviewt werden sollen, der nicht an deiner Tastatur sitzt.

Rohes tmux plus git worktrees: die Skripte, die dir gehören

Das ehrlichste DIY-Setup ist auch das älteste: ein paar Shell-Skripte, die Worktrees anlegen und tmux-Fenster öffnen, eines pro Agent. Es sieht so aus.

# one worktree and one branch per parallel unit of work
git worktree add ../app-auth    -b feature/auth
git worktree add ../app-billing -b feature/billing

# a named tmux window per agent, launched in its worktree
tmux new-window -n auth    -c ../app-auth    'claude'
tmux new-window -n billing -c ../app-billing 'claude'

Zwei Befehle pro Feature und du hast isolierte Agents, die parallel laufen, jeder auf seinem eigenen Branch, jeder in einem beschrifteten Fenster, zu dem du mit einem Tastendruck wechseln kannst. Wickel es in eine Schleife und du kannst ein Dutzend starten. Nichts steht zwischen dir und den Tools. Du kannst jede Zeile lesen, alles ändern, und es kostet nichts außer der Zeit, es zu schreiben.

Für eine bestimmte Art von Entwickler ist das für immer die richtige Antwort, und das verdient Respekt, statt jemandem davon abzureden. Du verstehst genau, was läuft, weil du es geschrieben hast. Es gibt keinen Anbieter, kein Update, das deinen Ablauf zerstört, keine Abstraktion, die im falschen Moment leckt. Wenn deine Bedürfnisse stabil und persönlich sind, schlagen Skripte, die dir gehören, Tools, die du mietest.

Die Kosten zeigen sich, wenn dein Setup wächst, und sie zeigen sich als Wartung, nicht als Features. Das Aufräumen liegt bei dir: veraltete Worktrees sammeln sich an, bis git worktree prune und ein tmux kill-session-Sweep Teil deiner Routine werden. Namenskollisionen liegen bei dir. Ein abgestürzter Agent hinterlässt ein totes Fenster und einen halbfertigen Branch, und das zu bemerken liegt bei dir. Und nichts davon verlässt deine Maschine, sodass in dem Moment, in dem ein Teamkollege fragt „was haben deine Agents diese Woche ausgeliefert“, die einzige Antwort im Scrollback liegt. Die Skripte skalieren deinen Durchsatz. Sie skalieren nicht deine Fähigkeit, das Ergebnis zu teilen.

Nutze rohes tmux und Worktree-Skripte, wenn du volle Kontrolle willst, es genießt, dein Tooling zu besitzen, und das Publikum für die Arbeit du selbst bist. Greif zu etwas anderem, wenn du merkst, dass du Status-Tracking, Aufräumen und Übergabelogik nachbaust, die anfängt, wie ein Produkt auszusehen, das du gar nicht schreiben wolltest.

Im direkten Vergleich: Was jedes DIY-Setup gut macht

Die letzten beiden Zeilen sind kein Seitenhieb. Sie sind das Muster. Jedes dieser Tools ist für einen einzigen Bediener auf einer einzigen Maschine gebaut, und innerhalb dieses Rahmens reichen sie von gut bis hervorragend. Die leere Spalte ist bei allen dreien dieselbe, und es ist die Spalte, die an dem Tag zählt, an dem die Arbeit nicht mehr allein deine ist. Für eine breitere Landkarte der Kategorie sieh dir unseren Überblick zur KI-Agent-Orchestrierung an.

Die Übergangslinie: Wenn Fensterverwaltung aufhört, das Problem zu sein

Hier ist das Erkennungszeichen. Du hörst auf zu fragen „wie lasse ich mehr Agents gleichzeitig laufen“ und fängst an, Fragen zu stellen, die die DIY-Tools nicht beantworten können:

• Welche Änderungen meiner Agents hat irgendjemand reviewt?
• Wenn ich krank ausfalle, kann ein Teamkollege sehen, was gerade läuft, und es übernehmen?
• Wo ist die Aufzeichnung, warum wir diesen Diff akzeptiert und jenen abgelehnt haben?
• Welche Runs sind blockiert, wodurch und seit wann?

Das sind Workflow-Fragen, keine Laufzeitfragen. Kein besserer Switcher und kein hübscherer Diff-Viewer beantwortet sie, weil das fehlende Teil nicht auf deinem Bildschirm liegt. Es ist ein gemeinsamer Ort, an dem die Arbeit leben kann. Das ist die Übergangslinie: der Tag, an dem dein Engpass von der Fensterverwaltung zur Verwaltung von Sichtbarkeit, Review und Übergaben wandert.

Sharkly ist für die andere Seite dieser Linie gebaut. Es hält Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review vom Request bis zum Release sichtbar, in einem gemeinsamen Workflow statt verstreut über private Terminals. Die Arbeitsteilung ist bewusst gewählt: Claude Code, Codex und ähnliche Tools übernehmen die Ausführung; Sharkly verwaltet teamweite Zuweisung, verbundene Computer, Task-Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review über diese Tools hinweg. Du behältst die Laufzeiten und Worktrees, denen du bereits vertraust. Du fügst die Ebene hinzu, die es mehr als einer Person erlaubt, die Arbeit zu sehen und zu steuern.

Die Beruhigung ist genauso wichtig wie der Mechanismus. Sharkly einzuführen verlangt nicht, dass du deinen Prozess neu aufbaust oder deine Tools fallen lässt. Du bringst dein eigenes Abo mit: Die Modellnutzung läuft weiter über die Abos oder API-Schlüssel, die in den Tools konfiguriert sind, die dein Team ohnehin einsetzt. Du verbindest einen Computer, richtest Sharkly auf dieselben Repositories und beginnst, Arbeit zu routen, ohne irgendetwas abzureißen. Wenn du das gegen ein lokales Board abwägst, deckt unser Beitrag zur Vibe-Kanban-Alternative denselben Weg ab, das zu behalten, was du schon hast.

Wie derselbe parallele Workflow in Sharkly aussieht

Die DIY-Tools geben jedem Agent einen Worktree und ein Fenster. Sharkly gibt jeder Arbeitseinheit einen Task und lässt Agents ihn auf dieselbe Weise in isolierten Worktrees ausführen, mit einem Unterschied: Das Ergebnis kehrt zum Task zurück, statt in deinem Scrollback zu bleiben.

Ein Task ist die Hauptarbeitseinheit in Sharkly. Er trägt das Ziel, den Umfang, den Diff, die Diskussion und das Review in einer gemeinsamen Aufzeichnung. Wenn du einen Task einem Agent zuweist, beansprucht der Agent ihn, arbeitet in seinem eigenen isolierten Worktree, führt Typecheck, Tests und den Build aus und hängt dann die Änderungszusammenfassung, die Verifikationsergebnisse und die bekannten Grenzen an diesen Task an. Die nächste Person, die hinschaut, braucht dein Terminal nicht. Sie öffnet den Task.

Die kleinste nützliche Version ist bewusst langweilig. Verbinde einen Computer, erstelle einen Agent und weise ihm einen risikoarmen Task zu, genau so, wie unser First-Task-Walkthrough es einrichtet. Von dort aus skaliert die parallele Geschichte so, wie deine Skripte es wollten: Mehrere Agents beanspruchen bereite Tasks und arbeiten gleichzeitig, jeder isoliert, während Frontend, Backend, Bugfixing und Testabdeckung parallel vorankommen. Der Unterschied zu einer Wand voller tmux-Fenster ist, dass jeder Run einer Person zuweisbar, von jemandem, der nicht du bist, reviewbar und im Nachhinein nachvollziehbar ist.

Der Vertrag zwischen Mensch und Agent ist der Punkt, an dem die Review-Ebene ihren Wert beweist. Agents recherchieren, führen aus, testen und berichten. Menschen setzen die Richtung, verleihen Befugnis und akzeptieren das Ergebnis. Die Automatisierung endet dort, wo Team-Urteilsvermögen gefordert ist, und liefert eine Auslieferung mit vollständigem Kontext und überprüfbaren Belegen zurück. Ein DIY-Setup kann die Agents laufen lassen. Es kann diesen Vertrag nicht halten, weil es keinen gemeinsamen Ort hat, an dem eine andere Person als du annehmen oder ablehnen kann. Wenn du die Mechanik dieses Gates willst, geht unser Hinweis zu Cursor-Background-Agents einen ähnlichen Review-Flow durch.

Ein durchgerechnetes Beispiel in der Form, die Teams verwenden. Ein Task wie SH-312 lautet „Rate Limiting zur öffentlichen API hinzufügen“. Ein Agent schärft den Umfang, arbeitet in seinem Worktree, führt die Tests aus und gibt eine Zusammenfassung plus den Diff an den Task zurück. Dein Reviewer öffnet SH-312, liest die Belege und nimmt an oder bittet um Änderungen. Als du solo warst, lebte diese ganze Schleife in deinem Kopf und einem Terminal. Jetzt lebt sie an einem Ort, den das Team sehen kann, und genau darum geht es beim Übergang.

Wer bleiben sollte, wer darüber hinausgewachsen ist

Ein Vergleich, der nur nach oben verkauft, ist nicht ehrlich, also hier die nüchterne Version. Viele Leute sollten nicht wechseln, und die oben genannten Tools sind das richtige Zuhause für sie.

• Bleib bei Conductor, wenn du ein Solo-Mac-Entwickler bist, der parallele Claude-Code-Runs in einem ruhigen Fenster will und niemand sonst sie sehen muss. Es erledigt diese Aufgabe sauber und verlangt nichts von einem Server.
• Bleib bei Claude Squad, wenn du im Terminal lebst, einen Mix aus Laufzeiten betreibst und einen schnellen Switcher über Worktrees und tmux für deine eigene Arbeit willst. Es ist ein starkes Kommandozentrum für einen einzigen Bediener.
• Bleib bei rohem tmux und Worktree-Skripten, wenn du totale Kontrolle schätzt, dein Workflow stabil ist und du das einzige Publikum für die Ausgabe bist. Eigenes Tooling schlägt gemietetes Tooling, wenn die Bedürfnisse persönlich sind.
• Steig auf Sharkly um, wenn die Arbeit aufgehört hat, allein deine zu sein: wenn ein Teamkollege einen Run reviewen muss, wenn jemand übernehmen muss, während du weg bist, wenn ein Manager sehen muss, was blockiert ist, oder wenn du merkst, dass du Status- und Übergabelogik von Hand nachbaust. Unser Orchestrierungs-Überblick zeigt, wo die Ebenen aufeinandertreffen.

Das Entscheidungspaar für die ganze Kategorie ist kurz. Nutze ein DIY-Tool, wenn die Einschränkung deine eigene Maschine und deine eigene Zeit ist. Nutze eine Orchestrierungsebene, wenn die Einschränkung das gemeinsame Verständnis deines Teams davon ist, was die Agents getan haben. Die meisten Entwickler beginnen links und wechseln in der Woche hinüber, in der ein zweiter Name in der Arbeit auftaucht.

Szenarien aus der Praxis

Der Solo-Entwickler, der bleibt, wo er ist. Ein Freelancer liefert Kundenfeatures mit drei oder vier Claude-Code-Agents auf einem Mac aus. Conductor oder Claude Squad ist die ganze Antwort, und eine Team-Ebene hinzuzufügen wäre Ballast ohne Nutzen. Zu bleiben ist die richtige Entscheidung.

Das Zweierteam, das gerade die Linie überschritten hat. Ein Gründer und ein erster Entwickler betrieben jeder ihre eigenen tmux-Skripte. Keiner konnte die Agent-Arbeit des anderen ohne Screen-Sharing reviewen. Die Runs auf gemeinsame Tasks in Sharkly zu verlagern, bedeutete, dass jeder den Diff des anderen öffnen, annehmen und mergen konnte, ohne die Laufzeiten zu ändern, die beide bereits nutzten.

Der Lead, der ein Squad standardisiert. Ein Tech-Lead mit fünf Entwicklern stellte fest, dass jeder ein etwas anderes Worktree-Skript hatte und es kein gemeinsames Review gab. Gemeinsame Agents und ein einheitlicher Task-Flow verwandelten fünf private Setups in einen Workflow, den das Team wiederverwenden konnte, während jeder Entwickler seinen eigenen Computer und sein eigenes Modell-Abo behielt.

FAQ

Was ist der Unterschied zwischen Claude Squad und Conductor? Claude Squad ist eine plattformübergreifende Terminal-App, die Agents über tmux und git worktrees verwaltet und mehrere Laufzeiten unterstützt. Conductor ist eine macOS-Desktop-App mit Fokus auf das Ausführen von Claude Code in einer Fensteroberfläche. Beide isolieren jeden Run in seinem eigenen Worktree; der Unterschied liegt bei Terminal versus native App und plattformübergreifend versus nur Mac.

Brauche ich Claude Squad oder Conductor, wenn ich bereits git worktrees nutze? Nicht unbedingt. Beide sind Komfortfunktionen über demselben Worktree-Primitiv. Wenn du dich damit wohlfühlst, ein paar tmux- und git worktree-Befehle zu schreiben, geben dir rohe Skripte dieselbe Isolation mit mehr Kontrolle. Die Tools kaufen dir Ergonomie und Aufräumen, nicht eine neue Fähigkeit.

Können diese DIY-Tools Team-Review bewältigen? Nein, und sie behaupten es auch nicht. Conductor, Claude Squad und tmux-Skripte halten den Zustand alle auf einer Maschine für einen Bediener. Gemeinsames Review, Abnahme durch eine andere Person und eine dauerhafte Aufzeichnung von Entscheidungen sind Workflow-Features, die in einer Orchestrierungsebene leben, nicht in einem lokalen Runner. Sieh dir unseren Beitrag zur Vibe-Kanban-Alternative für diese Unterscheidung an.

Ist Sharkly ein Ersatz für Claude Code oder Claude Squad? Nein. Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Es fügt die gemeinsame Task-, Computer-, Kontext-, Kontroll- und Review-Ebene rund um die Tools hinzu, die dein Team bereits nutzt. Du behältst deine Laufzeiten und deine Worktrees und gewinnst obendrauf Team-Sichtbarkeit.

Bedeutet der Wechsel zu Sharkly, git worktrees aufzugeben? Nein. Sharkly lässt Agents ebenfalls in isolierten Worktrees laufen, die Isolation, auf die du dich verlässt, bleibt also erhalten. Was sich ändert, ist, wohin das Ergebnis geht: Es kehrt zu einem gemeinsamen Task zurück statt in einen privaten Terminal-Puffer.

Wie behalte ich meine Modellnutzung und meine Kosten beim Wechsel? Du bringst dein eigenes Abo mit. Die Modellnutzung läuft weiter über die Abos oder API-Schlüssel, die in den Tools konfiguriert sind, die dein Team verbindet, und das Modell-Kontingent hängt von diesen Tools, Tarifen und API-Konten ab. Sharkly fügt die Koordinationsebene hinzu, nicht eine neue Abrechnungsbeziehung.

Bereit, die Linie zu überschreiten? Lade Sharkly herunter, verbinde einen Computer und weise einem einzelnen Agent eine echte Anforderung zu. Behalte die Laufzeiten und Worktrees, denen du bereits vertraust, und lass die Arbeit an einen Ort zurückkehren, den dein ganzes Team sehen kann. Die Docs behandeln jedes Konzept ausführlicher unter docs.sharkly.ai.