Workban

Agenten & CLI · Für Entwickler

Der Agent führt seinen Task selbst. Du schreibst nichts nach.

Workban spricht mit Agenten über eine CLI im Terminal. workban init legt im Repository eine Regel, einen Skill und die Hooks ab. Ab dann legt Claude Code vor der ersten Änderung seinen Task an, schiebt ihn ins Testing und schließt ihn mit einem Kommentar.

claude · ~/web-app
$ workban task create "Login-Redirect fixen" --start --agent claude-code --json  └ #42 angelegt, In Progress$ workban task move 42 testing --json$ workban task done 42 --comment "Redirect gefixt, PR verlinkt" --json
  • 25 Befehle
  • 6 Plattformen, ohne Node
  • Claude Code und Codex
  • REST-API, kein MCP

Ablauf

Vier Befehle von der ersten Zeile bis zum Abschluss.

Die Regel im Repository sagt dem Agenten, wann er welchen Befehl ausführt. Jeder Befehl gibt mit --json genau ein JSON-Objekt zurück, damit der Agent die Antwort sicher lesen kann.

  1. 01

    Anlegen und starten

    Bevor der Agent eine Datei ändert. Den Branch liest die CLI aus Git. Gibt es zum Branch schon einen offenen Task, arbeitet der Agent an diesem weiter, statt einen zweiten anzulegen.

    workban task create "Login-Redirect fixen" --start --agent claude-code --json

  2. 02

    Testen

    Sobald Tests, Lint oder CI laufen. Bis der Task wieder in Arbeit ist, sperrt der Riegel jede Änderung.

    workban task move 42 testing --json

  3. 03

    Warten

    Wartet der Task auf einen Menschen, eine Freigabe oder eine Antwort, steht die Uhr. Der Kommentar sagt, worauf.

    workban task move 42 on_hold --comment "Freigabe durch Design" --json

  4. 04

    Abschließen

    Nach dem Commit, mit dem Link zum Pull Request im Kommentar. Den Token-Verbrauch hat die CLI laufend gemeldet, hier ein letztes Mal.

    workban task done 42 --comment "Redirect gefixt, PR verlinkt" --json

Oder umgekehrt: Du legst an, der Agent übernimmt.

Leg den Task im Board an und sag deinem Agenten „erledige #28“. Er liest Beschreibung, Kommentare und Anhänge und startet den Task, bevor er loslegt.

workban task show 28 --json --download

workban init

Ein Befehl richtet das Repository ein.

Einmal pro Repository. Die Dateien liegen im Repository und gelten damit für alle, die darin arbeiten, Mensch oder Agent.

.workban.toml
Welches Projekt in Workban dieses Repository ist.
.claude/rules/workban.md
Der verbindliche Ablauf. Claude Code lädt ihn bei jedem Start einer Sitzung.
.claude/skills/workban/SKILL.md
Die Befehle der CLI. Der Agent lädt sie, wenn er sie braucht.
CLAUDE.md, AGENTS.md
Ein Verweis für Claude Code, der volle Ablauf für Codex und andere Agenten.
.claude/settings.json
Die Hooks: der Riegel vor jeder Änderung, beim Start der Überblick über laufende Tasks und Backlog samt Update von CLI und Dateien, nach jeder Runde der Token-Verbrauch und laufend, ob der Agent arbeitet oder auf dich wartet.
.codex/hooks.json
Dieselben Hooks für Codex. Codex fragt beim nächsten Start einmal nach deiner Freigabe.

Bestehende Dateien ergänzt init, statt sie zu überschreiben. Nach einem Update der CLI gleicht der nächste Start einer Sitzung alles an, von Hand geht das mit workban init --update.

Riegel

Ohne Task keine Änderung.

In Claude Code sperrt ein Hook im Repository jede Dateiänderung, solange der Agent keinen eigenen Task gestartet hat. So fehlt auf dem Board auch der kleine Fix zwischendurch nicht.

  • Gilt für Edit, Write und Bash, unter Windows auch für PowerShell
  • Bei Bash prüft der Riegel den Befehl selbst: Umleitungen in Dateien, sed -i, rm, Paketinstallationen und Skripte, die schreiben
  • Gezählt wird je Sitzung: Ein zweiter Agent im selben Repository braucht seinen eigenen Task
  • Was außerhalb des Repositorys liegt, etwa /tmp, bleibt frei
  • Ist Workban nicht erreichbar oder niemand angemeldet, lässt der Riegel durch. Workban hält keine Arbeit auf

Edit README.md

Workban: Kein laufender Task. Erst den Task starten, dann die Änderung.

Workban Guard

Leitplanken für deine Agenten.

Workban weiß, woran deine Agenten arbeiten. Workban Guard passt auf, was sie dabei tun: ein eigenes Plugin für Claude Code und Codex, das gefährliche Befehle stoppt, bevor sie laufen.

  • Vor jedem Befehl: Force-Push auf main, rm -rf ~, supabase db reset oder cat .env stoppt es, auch versteckt in Skripten und Heredocs
  • Nach jedem Edit prüft es die neuen Zeilen auf any, leere catch-Blöcke, SQL aus Strings und Secrets
  • Fertig ist der Agent erst, wenn Typecheck, Lint und Tests grün sind
  • Zugang über deinen Workspace: Owner und Admins fragen die Freischaltung in der App unter Workban Guard an, danach installiert jedes Mitglied Workban Guard mit seinem Workban-Konto
Mehr zu Workban Guard
Claude Code mit Workban Guard
$ git push --force origin main  └ Workban Guard hat diese Aktion gesperrt: Force-Push auf „main“ überschreibt fremde Commits. [git.force-push]$ git reset --hard  └ Workban Guard bittet um Bestätigung: verwirft nicht committete Änderungen. [git.discard-changes]

Agenten

Am weitesten mit Claude Code, offen für jeden Agenten mit Shell.

Workban braucht vom Agenten nur ein Terminal und eine Textanweisung. Wie viel davon automatisch geschieht, hängt davon ab, was der Agent kann.

Claude Code
Regel, Skill und Hooks. Der Riegel greift, und nach jeder Runde meldet ein Hook die Tokens aus der Sitzungsdatei.
Codex
Der volle Ablauf steht in AGENTS.md, die Hooks in .codex/hooks.json. Hast du sie in Codex freigegeben, greift der Riegel auch dort, und ein Hook meldet die Tokens aus dem Rollout-Protokoll.
Andere Agenten
Jeder Agent mit Shell kann die CLI benutzen. Seinen Verbrauch meldet er beim Abschluss mit --tokens selbst.
Menschen
Dieselben Befehle im Terminal, oder das Board im Browser.

CLI

Ein Programm, für Maschinen gebaut.

Die CLI ist ein einzelnes Programm im Pfad, ohne Node und ohne Dienst, der ständig läuft. Sie spricht nur mit Workban.

  • macOS, Linux und Windows, jeweils für x64 und ARM64
  • Installation mit einem Befehl, Anmeldung mit einem persönlichen Token, einmal pro Rechner
  • --json bei jedem Befehl, stabile Exit-Codes, keine Rückfragen ohne Terminal
  • Neue Versionen installiert sie beim Start einer Sitzung selbst, nur signiert. workban doctor prüft die Einrichtung
  • Keine Telemetrie
macOS und Linux
curl -fsSL https://staging.workban.de/cli/install.sh | sh
Windows (PowerShell)
irm https://staging.workban.de/cli/install.ps1 | iex

Befehle

workban task
create, start, move, done, comment, attach, show, list, current, claim, edit, delete
workban project
list, create
workban board
Das Board kompakt im Terminal
workban auth
login, status, logout
workban init
Repository verbinden, mit --update auf den Stand der CLI heben
workban hook
gate, session, usage und state, die Hooks für Claude Code und Codex
workban update, doctor
Aktualisieren und die Einrichtung prüfen

Kein MCP

Warum Workban keinen MCP-Server hat.

Bewusst entschieden: eine REST-API und eine CLI statt eines MCP-Servers.

Ein Weg für alle
Claude Code, Codex, Skripte, Dashboards und Menschen im Terminal nutzen dieselbe API. Nichts geht nur über einen Agentenkanal.
Kein Prozess je Sitzung
Ein MCP-Server läuft pro Sitzung, mit eigener Konfiguration und eigenen Fehlerquellen. Die CLI ist ein Programm im Pfad.
Mit curl prüfbar
Jede Funktion lässt sich ohne Agent testen, Fehler lassen sich nachstellen.
Unabhängig vom Agenten
Ein neuer Agent braucht nur eine Shell und eine Textanweisung.
Weniger Kontext
Ein MCP-Server lädt alle Werkzeuge in den Kontext des Agenten. Der Skill lädt nur, wenn er gebraucht wird.

Weiter

Einrichten dauert ein paar Minuten.

Loslegen

Probier es mit deinem nächsten Task.

Workban ist kostenlos. Der Workspace steht in einer Minute, der erste Task entsteht, sobald dein Agent loslegt.