KittyClaw

KittyClaw ist eine lokale Kontrollzentrale für Softwarearbeit, die von KI-Agenten ausgeführt wird. Reichen Sie ein Software-Ticket ein, beobachten Sie, wie es sich über das Live-Board bewegt, lesen Sie den Lauf, der den Code geändert hat, prüfen Sie seine Verifikationsnachweise und treffen Sie die endgültige Release-Entscheidung selbst.

Das Produkt beweist drei Dinge in einem Durchlauf: ein Live-Board, einen nachvollziehbaren Lauf und menschliche Validierung vor externer Veröffentlichung. Neue Boards starten mit Backlog, Todo, InProgress, Blocked, Scheduled, Review und Done (Spalten bleiben anpassbar). Läufe können Claude Code, OpenAI Codex, Grok Build oder ein lokales Ollama-Modell verwenden.

Folgen Sie der geführten Fünf-Minuten-Demo, um den Durchlauf mit einem realistischen Software-Ticket zu wiederholen. Das begleitende Aktivierungstest-Protokoll misst, ob qualifizierte Testnutzer ihren ersten Lauf innerhalb von zehn Minuten erreichen.

Ein Projekt kann in unabhängig benannte Pipelines aufgeteilt werden, deren stabile Identitäten Umbenennungen überleben. Spalten können generische Prozessoren mit persistentem Speicher, wiederverwendbaren Projekt-Skills, geordneter Ticketauswahl, dauerhaften Wiederholungen und switch-artigem Routing zu Spalten in beliebigen Pipelines besitzen. Klicken Sie mit der rechten Maustaste auf eine Spalte und wählen Sie Spalte konfigurieren, um Name, Farbe, Rolle, Position, Ticket-Anleitung, Prozessor und Routing zu bearbeiten, ohne den visuellen Kontext des Boards zu verlieren. Tickets in Waiting- oder OwnerAction-Spalten zeigen immer einen prominenten kontextuellen Block zwischen ihrer Beschreibung und Aktivität, der erklärt, ob der Besitzer kommentieren oder das Ticket in eine bestimmte Validierungs-/Ablehnungsspalte verschieben muss, oder ob KittyClaw es automatisch wieder aufnimmt. Spalten können auch zwischen bestehenden Lanes eingefügt oder direkt am Ende vom Kanban hinzugefügt werden; die Workflows-Seite bleibt die globale Pipeline- und Skills-Übersicht. Der Ausführungszustand ist von Geschäftsspalten getrennt, sodass eine InProgress-Spalte optional ist. Die Legacy-AutomationEngine bleibt für triggerbasierte Regeln, Cron/Intervall-Arbeit und Abwärtskompatibilität verfügbar. Agenten laufen über Claude Code, OpenAI Codex, Grok Build, Mistral Vibe oder ein lokales Ollama-Modell, während ihre Ausgabe in die App gestreamt wird.

Jeder Prozessor ist mit seinem Projekt in .agents/processors/column-<id>/processor.json versioniert. Diese maßgebliche Definition enthält seine Mission, expliziten Prompt, Modell, Skills, Ticketreihenfolge, Wiederholungsrichtlinie und Routing. SQLite behält nur eine synchronisierte Laufzeitprojektion und den Ausführungszustand. Persistente Lektionen liegen neben der Definition unter .agents/processors/column-<id>/memory/MEMORY.md.

Tech-Stack

• .NET 10 / Blazor Server (interaktives SSR)

• SQLite über Entity Framework Core (eine DB pro Projekt)

• OpenAPI mit automatisch generierten Markdown-Dokumenten

• Agentenausführung: mindestens eine unterstützte CLI — Claude Code CLI, OpenAI Codex CLI, Grok Build oder Mistral Vibe. Ollama wird ebenfalls für lokale Modelle über Claude Code CLI unterstützt (Einrichtung lokaler Modelle).

• Optional für Repository-Initialisierung, Git-bewusste Automatisierungen und Agenten-Commits: Git

Erste Schritte

Voraussetzungen

• .NET 10 SDK

• Mindestens eine Agenten-CLI in Ihrem PATH: Claude Code (claude), OpenAI Codex (codex), Grok Build (grok) oder Mistral Vibe (vibe). Die Ausführung mit lokalen Modellen erfordert sowohl Claude Code CLI als auch einen erreichbaren Ollama-Server.

• Optional: Git (git in Ihrem PATH) für Repository-Initialisierung, Git-bewusste Automatisierungen und Agenten-Commits

Beim ersten Start prüft das Onboarding-Popup Git und jede unterstützte Provider-CLI mit denselben aufgelösten ausführbaren Pfaden wie der Dispatch: Claude Code (claude / KITTYCLAW_CLAUDE_BIN), OpenAI Codex (codex / KITTYCLAW_CODEX_BIN), Grok Build (grok, ~/.grok/bin oder KITTYCLAW_GROK_BIN) und Mistral Vibe (vibe / KITTYCLAW_MISTRAL_BIN). Es meldet auch die optionale Ollama-Verfügbarkeit. Jeder einzelne Agent-Provider ist ausreichend, fehlgeschlagene oder zeitüberschreitende Sonden bleiben nicht blockierend, und Git-abhängige Funktionen erfordern weiterhin Git.

Ausführen

Aus dem Repository-Stammverzeichnis:

run.bat        (Windows)
./run.sh       (macOS / Linux)

Beide umschließen dotnet watch --project KittyClaw.Web --non-interactive und dienen die App unter http://localhost:5230 mit aktiviertem Hot Reload.

Ein Projekt erstellen

Wählen Sie auf der Startseite Ein Projekt erstellen, geben Sie einen Namen ein und wählen Sie seinen Arbeitsbereich. Der integrierte Ordnerbrowser funktioniert unter Windows, macOS und Linux, ohne einen nativen Systemdialog hinter dem Browser zu öffnen. Er zeigt das Home-Verzeichnis, gemountete Laufwerke oder Dateisystemwurzeln, Breadcrumbs, Elternnavigation und direkte Pfadeingabe. Sie können auch einen absoluten Pfad eingeben und den Ordner erstellen, wenn er nicht existiert.

Klicken Sie auf Initialisieren, um:

1. Den Projekteintrag im Register + die projektspezifische SQLite-DB zu erstellen.

2. Die Projektvorlage aus ProjectTemplate/ (preamble.md, {agent}/SKILL.md, {agent}/memory/MEMORY.md-Index, memory-consolidation.md, automations.json, CLAUDE.md) in den Arbeitsbereich zu kopieren — Agentendateien unter <workspace>/.agents/, CLAUDE.md im Arbeitsbereichsstamm.

3. git init auszuführen, wenn der Arbeitsbereich noch kein Git-Repository ist (übersprungen, wenn git nicht installiert ist).

4. Ein Mitglied für jeden im Template gefundenen Agent-Slug zu erstellen.

5. Den Projekteinrichtungsassistenten zu öffnen.

Der Einrichtungsassistent analysiert einen vorhandenen Arbeitsbereich und schlägt unterschiedliche Pipelines, Spalten, menschliche Übergaben, Prozessoren, Routing und Zeitpläne vor. Für einen leeren Ordner stellt er zunächst einige Fragen zum Zweck des Projekts, zu Ergebnissen, menschlichen Entscheidungen und wiederkehrenden Arbeiten. Vorschläge sind grafisch: Sie können Pipelines hinzufügen oder entfernen, die Spalten jeder Pipeline überprüfen, einen Schritt mit einem Prompt verfeinern und vor der Genehmigung zurückgehen. Während dieser Vorbereitung wird nichts erstellt; Workflow erstellen wendet den genehmigten Plan an und verifiziert ihn, dann öffnet sich das Board.

Diese Neueinrichtung ist bewusst vom Migrationsassistenten für Legacy-Boards getrennt. Migrationsbegriffe und Legacy-Automatisierungsbereinigung werden nur angezeigt, wenn ein vorhandenes automatisierungsbasiertes Board konvertiert werden muss.

Der Arbeitsbereichsordner selbst wird von KittyClaw nie gelöscht, selbst wenn Sie ein Projekt löschen.

Datenspeicherung

Alle KittyClaw-Daten werden lokal in %APPDATA%/KittyClaw/ gespeichert:

• registry.db — Projektregister

• projects/{slug}.db — projektspezifische Datenbank (Tickets, Kommentare, Labels, Spalten, Mitglieder)

• uploads/ — hochgeladene Bilder

• runs/{runId}.json — Agentenlauf-Snapshots (Ereignisse, Status, Exit-Code)

• settings.json — Sprache + Onboarding-Flag

Der projektspezifische Agentenzustand liegt im Arbeitsbereich: <workspace>/.agents/{agent}/memory/ (bewerteter MEMORY.md-Index + Lektionsdateien pro Thema), <workspace>/.agents/channel/ (Sitzungszustand) usw.

Projektstruktur

Architektur

Die Architekturdokumentation pro Funktion liegt unter doc/. Beginnen Sie mit Pipeline- und Spaltenverarbeitung für das Multi-Pipeline-Modell oder doc/index.md für die vollständige Architekturübersicht.

API

Alle Endpunkte liegen unter /api. Die Dokumentation wird automatisch aus der Live-OpenAPI-Spezifikation generiert:

• Menschenlesbares Markdown: GET http://localhost:5230/api/docs

• Maschinenlesbares JSON: GET http://localhost:5230/openapi/v1.json

MCP-Server

KittyClaw kann einen eingebetteten MCP-Endpunkt unter http://localhost:5230/mcp (Streamable HTTP) bereitstellen, sodass jeder MCP-Client das Board steuern kann — Projekte auflisten, Tickets erstellen und verschieben, kommentieren und das Board-Layout lesen — ohne die REST-API zu berühren. Setzen Sie KITTYCLAW_MCP_ENABLED=1, bevor Sie KittyClaw starten, und verbinden Sie es dann mit Claude Code über:

claude mcp add --transport http kittyclaw http://localhost:5230/mcp

Sieben Tools sind in v1 enthalten: list_projects, list_tickets, get_ticket, create_ticket, comment_ticket, move_ticket, board_overview. Der Endpunkt ist standardmäßig deaktiviert und verwendet dieselbe Localhost-Vertrauensgrenze wie die REST-API. Details in doc/mcp.md.

Für KI-Agenten

Diese App ist dafür ausgelegt, von KI-Agenten über ihre REST-API betrieben zu werden. So beginnen Sie:

1. Lesen Sie die Live-API-Dokumentation unter http://localhost:5230/api/docs — jeden Endpunkt, Anfrage-/Antwortbeispiel und jedes Schema, immer aktuell mit dem laufenden Server.

2. Identifizieren Sie sich — author ist erforderlich für jeden mutierenden Endpunkt; das Weglassen führt zu HTTP 400. Verwenden Sie Ihren einfachen Agentennamen (z. B. "programmer", "groomer"). Der menschliche Benutzer ist "owner".

3. Entdecken Sie das Board — rufen Sie zuerst GET /api/projects auf, dann GET /api/projects/{slug}/columns, um die Workflow-Stufen zu erfahren, und GET /api/projects/{slug}/members für zuweisbare Mitglieder.

4. Verwenden Sie den richtigen Status — Ticketstatus müssen mit vorhandenen Spaltennamen übereinstimmen. Rufen Sie Spalten ab, bevor Sie Tickets verschieben.

5. Verfolgen Sie Ihre Arbeit — fügen Sie Kommentare zu Tickets hinzu, um zu erklären, was Sie getan haben oder was Sie benötigen. Verwenden Sie @mentions, um Mitglieder zu benachrichtigen, #id, um Tickets im selben Projekt zu referenzieren, und #{slug}:{id}, um Tickets in einem anderen Projekt zu referenzieren.

6. Labels & Priorität — verwenden Sie GET /api/projects/{slug}/labels, um verfügbare Labels zu entdecken, und setzen Sie die Priorität auf Idea, NiceToHave, Required oder Critical.

7. Erwähnungen prüfen — rufen Sie GET /api/projects/{slug}/mentions/{your-handle} auf, um Tickets zu finden, die Sie erwähnen.

8. Untertickets — setzen Sie parentId beim Erstellen eines Tickets, um es zu einem Kind zu machen. Verwenden Sie PUT /api/projects/{slug}/tickets/{id}/parent, um es neu zu parenten, oder DELETE, um es zu lösen. Listen Sie Untertickets mit ?parentId={id} auf.

9. Projektübergreifende Übertragungen — verwenden Sie POST /api/projects/{slug}/tickets/{id}/transfer nur, nachdem Sie geprüft haben, dass das Zielprojekt kompatible Spalten, Zuweisungen und Labels hat. Die Operation erhält den Ticketbaum und seine Historie oder lehnt die Übertragung ab, ohne eines der Projekte zu ändern. Siehe Verlustfreie Ticketübertragung.

Konventionen

• Autorenformat: "owner" für den menschlichen Benutzer, einfacher Agentenname (z. B. "programmer") für KI-Agenten

• Prioritätsstufen: Idea, NiceToHave, Required, Critical

• Standardspalte: Backlog

UI-Funktionen

• Onboarding-Popup beim ersten Start, das Git, Claude Code, OpenAI Codex, Grok Build, Mistral Vibe und Ollama prüft

• Plattformübergreifender In-App-Arbeitsbereichs-Browser mit Wurzelelementen, Breadcrumbs, direkter Pfadeingabe und Ordnererstellung

• Geführte Neue-Projekt-Einrichtung, die den Arbeitsbereich analysiert und editierbare Pipelines und Spalten vorschlägt, bevor der Workflow erstellt wird

• Geführte Migration von Legacy-Boards, die abgeschlossene Tickets erhält und ersetzte Automatisierungen erst nach Verifizierung zurückzieht

• Vereinheitlichte Multi-Projekt-Startseite mit Projektkarten und Kanban-Swimlanes

• Multi-Pipeline-Kanban mit visuell unterscheidbaren erlaubten und verbotenen Drop-Zielen basierend auf dem Prozessor-Routing

• Kontextueller Spalten-Editor für Struktur, Rolle, Owner-Anleitung, Prozessor, geordnete Aktionen, geplante Aufgaben und Routing

• Anpassbare Dashboard-Ansicht mit frei ziehbaren Kacheln (Markdown, KPI, Diagramme, Heatmap, Timeline, …), KI-Chat-basierter Kachel-Erstellung und automatischer Aktualisierung über LLM-Prompts

• Ticket-Detailbereich mit Kommentaren und Aktivitäts-Timeline

• Live-Agenten-Ausführungs-Drawer (SSE-Ausgabe des Providers, Steuerung + Stopp-Steuerung)

• Chat-Drawer für neue Anweisungen, um einen Ad-hoc-Prompt an einen Agenten zu senden

• Markdown-Rendering mit @mention, #id und #{slug}:{id} Unterstützung für Projektverweis-Tickets

• Erweiterte Suchsyntax: #42, @owner, >date, priority:critical, label:bug, by:owner

• Untertickets mit Eltern-/Kind-Beziehungen und Fortschrittsverfolgung

• Verlustfreie, atomare Ticketbaum-Übertragungen zwischen Projekten über die REST-API

• Spaltenverwaltung direkt vom Board aus (einfügen, duplizieren, neu anordnen, konfigurieren und als gelesen markieren)

• Label- und Mitgliederverwaltung

• Bild-Upload in Beschreibungen und Kommentaren

• Lokale Modellunterstützung (Ollama): projektspezifische Basis-URL mit Modell-Autoerkennung, Standardmodell pro Mitglied und Aktionen-spezifische Konfiguration in .agents/automations.json

• Provider-bewusster Dispatch über Claude Code, OpenAI Codex, Grok Build, Mistral Vibe oder Ollama, mit Gesprächsübergabe und Fallback bei nicht verfügbaren Modellen

Dashboard

Jedes Projekt hat neben dem Kanban-Board eine anpassbare Dashboard-Ansicht. Kacheln können frei gezogen werden, aktualisieren sich automatisch nach Zeitplan und können über das integrierte KI-Chat-Panel erstellt oder bearbeitet werden – der Agent schreibt den Kachel-Ordner für dich.

Kacheltypen

Ordnerstruktur

Jede Kachel liegt in einem eigenen Ordner unter .dashboard/ im Projekt-Workspace:

.dashboard/
  <tile-slug>/
    tile.yaml        # template, title, refresh schedule, prompt
    script.ps1       # optional refresh script (or script.sh, script.py, …)
    output.json      # last refresh output consumed by the template

Wichtige Felder in tile.yaml

• template – eine der IDs aus der Tabelle oben.

• title – Anzeigename in der Kachel-Kopfzeile.

• refresh – Intervall (z. B. 5m, 1h) für die periodische Aktualisierung.

• refreshAt – Cron-artige Aktualisierung zu bestimmten Uhrzeiten (Alternative zu refresh).

• prompt – Anweisungen, die an den Agenten gesendet werden, wenn output.json (neu) generiert wird.

Kacheln können über das KI-Chat-Panel des Dashboards erstellt werden, indem du beschreibst, was du möchtest – der Agent wählt eine Vorlage, schreibt tile.yaml, erstellt das Aktualisierungsskript und generiert die anfängliche output.json.

Kostenberichterstattung

Die Seite Kosten bietet eine projektspezifische, zwischengespeicherte Ansicht der Agentennutzung, sodass der Bericht auch bei langer Ausführungshistorie sofort geöffnet werden kann. Datumsvoreinstellungen ermöglichen die schnelle Auswahl gängiger Zeiträume; Projekt-, Pipeline- und Modellfilter lassen sich kombinieren. Die Pipeline-Auswahl folgt automatisch den ausgewählten Projekten. Eine Legende unterscheidet gemessene von geschätzten Kosten in den Tagesdiagrammen.

Automatisierungsmodell

• Trigger: interval, ticketInColumn, statusChange, subTicketStatus, ticketCommentAdded, gitCommit, boardIdle, agentIdle

• Bedingungen: ticketInColumn, statusChange, subTicketStatus, ticketCommentAdded, gitCommit, boardIdle

• Aktionen: runAgent, setStatus, setLabels, addComment, createTicket, updateTicket, httpRequest (mit optionalem Webhook)

• Trigger-Konfiguration: Jeder Trigger kann eine optionale delay (in Sekunden) und eine cooldown-Periode haben

• Pipeline-Ausführung: Aktionen laufen sequenziell in der definierten Reihenfolge; ein Fehler stoppt die Pipeline

• Bedingte Logik: Trigger und Aktionen unterstützen optionale when-Bedingungen für die Ausführung auf Basis von Ticketfeldern oder Metadaten

• Platzhalter: {{ticket.id}}, {{ticket.title}}, {{ticket.description}}, {{ticket.status}}, {{ticket.labels}}, {{ticket.author}}

• Wiederholungen: Eine Aktion kann mit retry konfiguriert werden, um sie bei Fehlern erneut zu versuchen

• Zeitpläne: Aktionen können zeitgesteuert über Cron-Ausdrücke ausgeführt werden (z. B. 0 9 * * 1 für jeden Montag um 9 Uhr)

Automatisierungsmodell

• Trigger: interval, ticketInColumn, statusChange, subTicketStatus, gitCommit, boardIdle

• Bedingungen: ticketInColumn, statusChange, subTicketStatus, ticketCommentAdded, gitCommit, boardIdle

• Aktionen: runAgent, setLabels, setStatus, createTicket, sendNotification, webhook

• Kanonsicher Ablauf nach der Ausführung: runAgent → collectAgentOutput → updateTicketSummary → commitChanges

• {assignee} und {author} Platzhalter werden aus dem Ticket-Kontext aufgelöst

• Wiederholungsversuche mit exponentiellem Backoff bei vorübergehenden Fehlern

• Automatisierungen werden im Projekt-Workspace unter .agents/automations.json definiert

Telemetrie

KittyClaw sendet keinerlei Telemetriedaten. Keine Nutzungsstatistiken, keine Fehlerberichte, keine anonymen Analysen. Die Anwendung ist vollständig offline-fähig und kommuniziert nur mit den von dir konfigurierten Agenten und Diensten.

Lizenz

KittyClaw ist unter der AGPL-3.0-or-later lizenziert. Selbsthosting und persönliche Nutzung sind uneingeschränkt; wenn du eine modifizierte Version verbreitest oder als Netzwerkdienst anbietest, musst du den Quellcode unter derselben Lizenz bereitstellen.

Zusätzliche Bedingungen unter der AGPL (Volltext in NOTICE.md): Abgeleitete Werke müssen die KittyClaw-Attribution sichtbar beibehalten (der rechtliche Hinweis in der App und eine Aussage „basiert auf KittyClaw" in der README), dürfen nicht den Eindruck erwecken, sie stammten vom Originalprojekt, und erhalten keine Rechte am Namen oder an den Logos von KittyClaw.

Zwei Dinge, die die AGPL nicht betrifft: Die Ausführung von KittyClaw über eine API (z. B. als verwalteter Dienst) unterliegt keiner Copyleft-Pflicht, und keine Bestimmung dieser Lizenz schränkt die kommerzielle Nutzung ein, solange der Quellcode offen bleibt.