kata
- title
- kata
- type
- toolbox
- summary
- Local-first issue tracker for agent work โ one SQLite daemon behind a JSON CLI and a TUI
- tags
- go, ai-agents, issue-tracker, cli, tui, sqlite, local-first, watchlist, kenn-software
- language
- Go
- license
- MIT
- created
- 2026-05-22
- updated
- 2026-05-22
Local-first issue tracker for AI-assisted software work. Two front-ends over one local SQLite daemon: a stable, JSON-emitting CLI for agents and an interactive TUI for the human supervising them. Issues get ULID-derived short codes (kata#abc4), an append-only event history, and the usual relationships (parent/child, blocks/blocked-by, related). Part of the kenn-software-suite of single-binary local-first agent tools.
What it is for
A structured place for tasks, decisions, links, comments, and state changes โ separate from GitHub Issues or a markdown plan that the agent rewrites every turn. The agent records work against a durable ledger; the human triages and supervises through the TUI. The deliberate scope statement: kata is "a durable task ledger," not "a project-management suite, a git workflow engine, or an agent worker pool."
How it works technically
State lives in a local SQLite database at KATA_HOME (defaults to ~/.kata), behind a single long-running daemon. Both the CLI and the TUI talk to that daemon, so there's one writer and a consistent view. The event stream is append-only and durable, which is what makes audit trails and --tail polling work โ an agent or a watcher can follow live changes instead of re-listing.
The load-bearing design choice is keeping issue state outside the repository, which is the opposite of beads (Dolt database committed alongside code) and git-bug (issues stored as git objects). Trade-offs:
- Cleaner repo footprint โ only a committed
.kata.tomlbinds a workspace, with optional.kata.local.tomlfor per-developer overrides. - Works identically in non-git directories.
- Task history is separated from code history rather than versioned with it โ so you don't get beads-style branch merging of issues, but you also don't get merge conflicts on the issue store.
There's an optional remote daemon mode for private networks, but it has no authentication, so it's strictly a trusted-LAN convenience, not a shared server.
Basic usage
go install github.com/kenn-io/kata/cmd/kata@latest
kata init # bind workspace, writes .kata.toml
kata create "fix login race" # returns a short_id, e.g. abc4
kata list # open issues
kata show abc4
kata close abc4 --done --message "Fixed; tests pass." --commit <sha>
kata tui # interactive triage
Other surfaces: labels, ownership, soft-delete/restore/purge, search, projects, per-actor digest summaries over a time window, and JSONL export/import for backups and schema migration.
Limitations
- No authentication in local or remote mode โ trusted environments only.
- Import always creates a fresh database; no per-project merge, no incremental re-import of snapshots.
- A shared multi-user server mode is planned, not built.
- Command contracts may still change โ see watchlist note below.
Watchlist
Early public preview โ usable (CLI/daemon/TUI all work) but command contracts are explicitly unstable and there are no tagged releases yet. Tracked on watchlist for a maturity re-check.
Related
- beads โ the closest comparison; opposite storage philosophy (Dolt-in-repo vs. SQLite-outside-repo). Both give agents a structured task graph instead of a markdown TODO.
- forge โ sits at the same "CLI for agents" layer but bridges to remote forges (GitHub/GitLab/Gitea); kata is the local task ledger.
- kenn-software-suite โ the rest of Kenn Software's local-first agent tooling.
Repo
github.com/kenn-io/kata โ Go (1.26+), MIT, 210 stars, no tagged release yet (early public preview). macOS/Linux/Windows.