Summary
roborev ships a built-in [[hooks]] type = "beads" that emits a bd create on review events, automatically filing review findings as beads issues. Ask: ship an analogous type = "kata" that emits kata create against the workspace's kata project.
Current state
internal/daemon/hooks.go currently special-cases only "beads":
if hook.Type == "beads" {
return beadsCommand(event)
}
There is no equivalent for kata. Users who've migrated to kata as their primary tracker today have to either:
- write a
command-type hook with a hand-rolled kata create shell, or
- install a sidecar like
bogorad/roborev-to-beads and live with the beads → kata indirection.
Neither is great when kata and roborev are by the same author and could integrate natively.
Proposed shape
In a repo's .roborev.toml:
[[hooks]]
type = "kata"
events = ["review.failed", "review.completed"] # whatever beads supports
# optional:
project = "<name>" # defaults to the workspace's .kata.toml binding
labels = ["roborev", "from-review"]
priority = 2
The kata equivalent of beadsCommand(event) would call something like:
kata create "<finding title>" \
--project <project> \
--body-file <(<finding markdown>) \
--label roborev --label severity:<level> \
--idempotency-key "roborev:<job-id>:<finding-id>" \
--agent
The two load-bearing flags for an unattended emitter:
Small bonus
internal/git/git.go already excludes **/.beads/** from review diffs. The kata equivalents would be .kata.toml and .kata.local.toml — binding/config files, not code-review material.
Context
Same author owns both projects, so built-in support feels like the right home rather than living as a third-party sidecar. Happy to draft a PR if there's interest.
Summary
roborev ships a built-in
[[hooks]] type = "beads"that emits abd createon review events, automatically filing review findings as beads issues. Ask: ship an analogoustype = "kata"that emitskata createagainst the workspace's kata project.Current state
internal/daemon/hooks.gocurrently special-cases only"beads":There is no equivalent for kata. Users who've migrated to kata as their primary tracker today have to either:
command-type hook with a hand-rolledkata createshell, orbogorad/roborev-to-beadsand live with the beads → kata indirection.Neither is great when kata and roborev are by the same author and could integrate natively.
Proposed shape
In a repo's
.roborev.toml:The kata equivalent of
beadsCommand(event)would call something like:The two load-bearing flags for an unattended emitter:
--idempotency-key— matches the existing beads-hook dedup intent and is safe against daemon retries. The daemon returns the existing issue instead of creating a duplicate.--agent(the new--format agentfrom kata PR Add roborev skills for Claude Code and Codex, addroborev skills installcommand #55) — single-tokenOK <verb>lines, cheap to log and parse.Small bonus
internal/git/git.goalready excludes**/.beads/**from review diffs. The kata equivalents would be.kata.tomland.kata.local.toml— binding/config files, not code-review material.Context
Same author owns both projects, so built-in support feels like the right home rather than living as a third-party sidecar. Happy to draft a PR if there's interest.