Orca CLI: Agenten-Pipeline von Aufgaben zu Workspaces

Wie aus einer Aufgabe Arbeit für einen eigenen Agenten wird

Mich interessiert hier nicht die Orca-Oberfläche selbst, sondern die Verbindung aus Orca CLI und Automations: Eine Karte, die nach Select for development verschoben wird, kann zum Eingang für einen separaten Agentenlauf werden. Die offizielle Übersicht und die Orca-CLI-Referenz beschreiben Operationen mit Worktrees, Terminals, Dateien, Diffs, einem eingebetteten Browser und Fortschrittsberichten. Eine separate Dokumentation zu Scheduled Automations bestätigt, dass Aufgaben für ein Repository oder einen bestehenden Workspace gestartet werden können.

Ich habe Orca heruntergeladen und ein paar Stunden damit experimentiert. Der Wunsch, sofort meinen gesamten Workflow dorthin zu verlagern, entstand nicht. Das Markdown-Kanban-Szenario zeigt jedoch gut, warum eine CLI-Schicht über der Entwicklungsumgebung sinnvoll sein kann. Orca wird nicht zu einem weiteren Bildschirm mit Agenten, sondern zu einer Ausführungsschicht zwischen Aufgabe und Repository.

Die vorgeschlagene Pipeline sieht so aus:

• eine Aufgabe erscheint in einem Obsidian-Kanban und ändert ihren Status;
• für sie wird ein isolierter Workspace mit eigenem Branch erstellt;
• ein Mini-Agent erledigt die Arbeit und erstellt ein Changelog;
• Status und Ergebnis werden in die Markdown-Datei zurückgeschrieben;
• Merge und Deployment bleiben getrennte Schritte.

Ein wichtiger Vorbehalt: Die offiziellen Orca-Materialien bestätigen die Arbeit mit isolierten Worktrees, Automatisierungen und Markdown-Artefakten, aber keine fertige Obsidian-Integration. Mit Stand vom 24. August 2026 wird eine solche Verbindung in der gesammelten Dokumentation nicht beschrieben. Die Überwachung von Kanban-Änderungen und die Aktualisierung des Vaults müssen daher als externe Schicht organisiert werden und sollten nicht als integrierte Funktion gelten.

Warum ein dateibasiertes Kanban wichtiger ist als die Oberfläche

Dieser Ansatz kann die Arbeit mit mehreren Projekten tatsächlich verändern, macht sie aber nicht auf magische Weise autonom. Eine gewöhnliche Markdown-Datei wird zur Aufgabenwarteschlange, während isolierte Workspaces das Risiko verringern, Kontexte, Branches und unfertige Änderungen zwischen parallel arbeitenden Agenten zu vermischen.

Als Erstes würde ich die Idempotenz prüfen: Erstellt ein wiederholtes Ereignis einen zweiten Workspace für dieselbe Karte? Danach folgen Wiederherstellung nach einem Agentenabsturz, Branch-Konflikte, Statussynchronisierung und ein klares Fertig-Kriterium. Andernfalls produziert eine elegante Pipeline schnell nicht Code, sondern eine Sammlung vergessener Worktrees.

Das ist keine Revolution der persönlichen Produktivität, sondern pragmatische Orchestrierung bekannter Bausteine: Git, Markdown, Zeitpläne und Agenten. Die spannendste Frage bleibt offen: Wie lange kann ein solcher dateibasierter Control Plane einfach bleiben, wenn die Zahl der Aufgaben und Repositories wirklich groß wird?

Wir haben bereits untersucht, wie parallele Claude-Code-Agenten PRs prüfen und Race Conditions in Workflows finden. Dieser Ansatz ergänzt isolierte Workspaces, in denen jeder Agent eine eigene Umgebung für seine Aufgabe benötigt.