robot

| | --- | | | 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/<id>-<slug> ─► 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 <project>#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 <id>. 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: 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 <id> 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. Start here. | | | - Kata commands (create, ready, claim, deps, comment, close, reopen) → references/kata.md | | | - Worktrees (create, find, status, cleanup) → references/kwt.md | | | - Roborev (only once the operator asked: launch, inspect, respond) → references/roborev.md | | | - History (what did a previous agent do or try) → references/agentsview.md | | | - Supervising several workers, or rebuilding state after a crash → references/orchestration.md | | | - A tool is missing or unconfigured, or setting up a new machine or repo → 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 <tool> --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. |