# robot > Source: > Published: 2026-10-15 01:56:17+00:00 | | --- | | | name: robot | | | description: Operate a local multi-agent development workflow built on Kata (issue/work ledger), kwt (git worktrees + tmux workspaces), Roborev (optional, operator-approved AI code review), and AgentsView (agent session history). Use when choosing or claiming work, creating a worktree for an issue, recording progress or evidence, reviewing commits, closing or abandoning work, running experiments, handing off between agents, supervising parallel worker agents, recovering after a crash, or when the user mentions kata, kwt, roborev, agentsview, /robot, "ready work", "claim", "worktree", "review loop", or "close with evidence". | | | --- | | | # Robot: local agent development control plane | | | Four tools by Wes McKinney / kenn.io, plus Git. There is no other database. Every piece of state comes from the system that owns it: | | | \| Question \| Authority \| Look at \| | | | \|---\|---\|---\| | | | \| What work exists, who owns it, what's blocked, what was decided, how it ended \| **Kata** \| `kata ready`, `kata show` \| | | | \| Where the work happens (worktree, branch, dirty or clean) \| **Git + kwt** \| `kwt list --json`, `kwt status --json` \| | | | \| What the code is, what's integrated \| **Git** \| `git log`, `git merge-base --is-ancestor` \| | | | \| Did the operator ask for a Roborev pass, are its findings open \| **Roborev** \| `roborev list --open --all-branches` \| | | | \| What agents actually did or tried, and why \| **AgentsView** \| `agentsview session search` \| | | | AgentsView observes. It never defines task status. Do not copy the same state into a second system, and never create JSON or markdown status files. | | | ## Lifecycle | | | ``` text | | | kata issue ─► kata claim ─► kwt add -b kata/- ─► subagents implement ─► commit | | | ─► coordinator reviews the diff ─► fixes ─► coordinator runs the tests ─► kata comment (evidence) | | | ─► ASK THE OPERATOR: roborev pass, operator diff review, or merge now | | | ─► (roborev loop, if asked) ─► integrate (git merge, per repo policy) ─► kata close --done --commit --test ─► kwt remove | | | ``` | | | Everything up to the question happens inside the worktree. Nothing reaches `main` without the operator's answer. | | | ## Invariants | | | 1. Every substantial piece of work has a Kata issue, including experiments that may be abandoned. | | | 2. The Kata short ID is the shared key. Kata IDs look like `abc4`, or `#abc4` when qualified; there is no custom prefix. Use branch `kata/abc4-short-slug`, which kwt names `kata-abc4-short-slug` on disk. | | | 3. Each independent piece of concurrent work gets its own kwt worktree. | | | 4. Claim before starting: `kata claim `. A claim that fails means someone else owns the issue. Stop. | | | 5. Kata holds durable findings, decisions, blockers and handoff notes. Keep them short. Never paste transcripts there. | | | 6. Detailed session history lives in AgentsView. Recover it from there instead of re-deriving it. | | | 7. The coordinating agent reviews every diff itself and runs the tests itself, in the worktree. Roborev is a separate agent and is never automatic: no post-commit hook, and no `roborev review` until the human operator has said yes. When the branch is ready to merge, ask the operator one question, as described in [workflow.md](references/workflow.md#the-merge-gate): run Roborev, review the diff themselves, or merge now. Wait for the answer. No answer means stop; it never means merge. | | | 8. When a Roborev pass was asked for, judge each finding against the requirements and the code's actual behavior. Fix it, or record why not with `roborev comment`. Never close findings mechanically in either direction. | | | 9. `kata close --done` needs evidence (`--commit`, `--test`, `--reviewed`, ...). "I'm done" is not evidence. | | | 10. A failed experiment is a legitimate outcome. Record what was tried and why it was rejected, then `close --wontfix`. Keep the branch if it is worth keeping. | | | 11. Never merge, remove worktrees, delete branches, reset, discard, `--force`, `kata delete/purge`, `roborev review`, `roborev fix/refine/compact` just because a tool suggests it. Check the state first (`kwt changes`, `git status`, ancestry). When unsure, ask the user. | | | 12. Workers implement. Supervisors or humans decide scope. A worker does not quietly change the task or declare open findings irrelevant; it says so in a Kata comment and escalates (`kata meta set work.attention needs-human`). | | | ## Which reference to load | | | Load only what the current step needs: | | | - **Doing a normal task, an experiment, a handoff or a review loop** → [references/workflow.md](references/workflow.md). Start here. | | | - **Kata commands** (create, ready, claim, deps, comment, close, reopen) → [references/kata.md](references/kata.md) | | | - **Worktrees** (create, find, status, cleanup) → [references/kwt.md](references/kwt.md) | | | - **Roborev** (only once the operator asked: launch, inspect, respond) → [references/roborev.md](references/roborev.md) | | | - **History** (what did a previous agent do or try) → [references/agentsview.md](references/agentsview.md) | | | - **Supervising several workers, or rebuilding state after a crash** → [references/orchestration.md](references/orchestration.md) | | | - **A tool is missing or unconfigured, or setting up a new machine or repo** → [references/installation.md](references/installation.md) | | | Commands were checked against upstream docs as of 2026-09: kata v0.18, kwt v0.6.1, roborev v0.69, agentsview v0.44. If a command fails, run ` --help` before improvising. | | | ## Instructions | | | 1. Establish context. Run `kata whoami`, `git rev-parse --show-toplevel` and `kwt list --json`. If any tool is missing, load installation.md. | | | 2. Identify your role: | | | - **Worker** with an assigned issue → follow workflow.md for that case. | | | - **Supervisor** → follow orchestration.md. | | | - **Recovering** → follow the recovery section in orchestration.md. | | | 3. Load a tool reference only when you need that tool's exact commands. | | | 4. Before any destructive step, run the safety checks from the tool's reference. Report what you verified. | | | 5. **Reflect and improve this skill.** After the task: | | | - **Reflect:** Did an instruction or command here mislead or fail? For example, flags that changed upstream, or a user correction or preference. Was a step missing or out of order? | | | - **Decide:** A generalizable lesson → edit the relevant file in this skill. A one-off or user-specific lesson → do not edit (consider memory instead). Nothing notable → say so and skip. | | | - **Edit:** Make small, surgical edits, such as fixing a flag or adding a bullet, in the file that owns that topic. Never delete this reflection step. | | | - **Report:** Tell the user in one or two sentences what changed, or that nothing did. |