KittyClaw

kittyclaw.dev · Get early access

KittyClaw is a local control plane for software work performed by AI agents. Submit a software ticket, watch it move across the live board, read the run that changed the code, inspect its verification evidence, and make the final release decision yourself.

The product proves three things in one journey: a live board, a readable run, and human validation before external release. New boards start with Backlog, Todo, InProgress, Blocked, Scheduled, Review, and Done (columns remain customizable). Runs can use Claude Code, OpenAI Codex, Grok Build, or a local Ollama model.

Follow the guided five-minute demo to repeat the journey with a realistic software ticket. The companion activation test protocol measures whether qualified trial users reach their first run within ten minutes.

A project can be split into independently named pipelines whose stable identities survive renames. Columns can own generic processors with persistent memory, reusable project skills, ordered ticket selection, durable retries, and switch-like routing to columns in any pipeline. Right-click a column and choose Configure column to edit its name, color, role, position, ticket guidance, processor, and routing without losing the visual context of the board. Tickets in Waiting or OwnerAction columns always show a prominent contextual block between their description and activity, explaining whether the owner must comment or move the ticket to a specific validation/refusal column, or whether KittyClaw will resume it automatically. Columns can also be inserted between existing lanes or added at the end directly from the Kanban; the Workflows page remains the global pipeline-and-skills overview. Execution state is separate from business columns, so an InProgress column is optional. The legacy AutomationEngine remains available for trigger-based rules, cron/interval work, and backward compatibility. Agents run through Claude Code, OpenAI Codex, Grok Build, Mistral Vibe, or a local Ollama model while their output streams into the app.

Each processor is versioned with its project in .agents/processors/column-<id>/processor.json. This authoritative definition contains its mission, explicit prompt, model, skills, ticket ordering, retry policy, and routing. SQLite keeps only a synchronized runtime projection and execution state. Persistent lessons live beside the definition under .agents/processors/column-<id>/memory/MEMORY.md.

Tech Stack

• .NET 10 / Blazor Server (interactive SSR)
• SQLite via Entity Framework Core (one DB per project)
• OpenAPI with auto-generated Markdown docs
• Agent execution: at least one supported CLI — Claude Code CLI, OpenAI Codex CLI, Grok Build, or Mistral Vibe. Ollama and DeepSeek V4 are supported through Claude Code. See the consolidated agent-provider installation guide.
• Optional for repository initialization, Git-aware automations, and agent commits: Git

Getting Started

Prerequisites

• .NET 10 SDK
• At least one agent CLI on your PATH: Claude Code (claude), OpenAI Codex (codex), Grok Build (grok), or Mistral Vibe (vibe). Local-model and DeepSeek execution use Claude Code as their transport; DeepSeek additionally requires DEEPSEEK_API_KEY in the project's secure vault.
• Optional: Git (git on your PATH) for repository initialization, Git-aware automations, and agent commits
• Optional: Rust Token Killer (RTK) (rtk on your PATH) for explicit per-project shell-output optimization. KittyClaw never installs or configures it automatically and forces its telemetry off for opted-in runs.

On first launch, the onboarding popup checks Git and every supported provider CLI using the same resolved executable paths as dispatch: Claude Code (claude / KITTYCLAW_CLAUDE_BIN), OpenAI Codex (codex / KITTYCLAW_CODEX_BIN), Grok Build (grok, ~/.grok/bin, or KITTYCLAW_GROK_BIN), and Mistral Vibe (vibe / KITTYCLAW_MISTRAL_BIN). It also reports optional Ollama availability. Any one agent provider is sufficient, failed or timed-out probes remain non-blocking, and Git-dependent features still require Git.

Run

From the repo root:

run.bat        (Windows)

./run.sh       (macOS / Linux)

Both wrap dotnet watch --project KittyClaw.Web --non-interactive and serve the app at http://localhost:5230 with hot reload enabled.

Creating a project

From the home page, select Create a project, enter a name, and choose its workspace. The built-in folder browser works on Windows, macOS, and Linux without opening a native system dialog behind the browser. It exposes the home directory, mounted drives or filesystem roots, breadcrumbs, parent navigation, and direct path entry. You can also type an absolute path and create the folder when it does not exist.

Click Initialize to:

1. Create the project registry entry + per-project SQLite DB.
2. Copy the project template from ProjectTemplate/ (preamble.md, {agent}/SKILL.md, {agent}/memory/MEMORY.md index, memory-consolidation.md, automations.json, CLAUDE.md) into the workspace — agent files under <workspace>/.agents/, CLAUDE.md at the workspace root.
3. Run git init if the workspace is not already a git repo (skipped if git isn't installed).
4. Create a member for each agent slug found in the template.
5. Open the project setup wizard.

The setup wizard analyzes an existing workspace and proposes distinct pipelines, columns, human hand-offs, processors, routing, and schedules. For an empty folder it first asks a few questions about the project's purpose, deliverables, human decisions, and recurring work. Proposals are graphical: you can add or remove pipelines, review each pipeline's columns, refine a step with a prompt, and move backward before approval. Nothing is created during this preparation; Create the workflow applies and verifies the approved plan, then opens the board.

This new-project setup is intentionally separate from the legacy-board migration wizard. Migration terminology and legacy-automation cleanup are shown only when an existing automation-based board needs conversion.

The workspace folder itself is never deleted by KittyClaw, even when you delete a project.

Data Storage

All KittyClaw data is stored locally in %APPDATA%/KittyClaw/:

• registry.db — project registry
• projects/{slug}.db — per-project database (tickets, comments, labels, columns, members)
• uploads/ — uploaded images
• runs/{runId}.json — agent run snapshots (events, status, exit code)
• settings.json — language + onboarding flag

Per-project agent state lives in the workspace: <workspace>/.agents/{agent}/memory/ (scored MEMORY.md index + per-topic lesson files), <workspace>/.agents/channel/ (session state), etc.

Project Structure

Architecture

Per-feature architecture documentation lives under doc/. Start with pipeline and column processing for the multi-pipeline model, or doc/index.md for the complete architecture map.

API

All endpoints are under /api. The documentation is auto-generated from the live OpenAPI spec:

• Human-readable Markdown: GET http://localhost:5230/api/docs
• Machine-readable JSON: GET http://localhost:5230/openapi/v1.json

MCP server

KittyClaw can expose an embedded MCP endpoint at http://localhost:5230/mcp (Streamable HTTP), so any MCP client can drive the board — list projects, create and move tickets, comment, and read the board layout — without touching the REST API. Open Settings from the home page and enable the MCP server, then hook it up to Claude Code with:

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

Seven tools ship in v1: list_projects, list_tickets, get_ticket, create_ticket, comment_ticket, move_ticket, board_overview. The endpoint is disabled by default, can be toggled without restarting KittyClaw, and uses the same localhost trust boundary as the REST API. Details in doc/mcp.md.

Read the full README on GitHub →