← ClaudeAtlas

rovelisted

Use when controlling Rove tasks, parallel coding attempts, hosted agent sessions, task lifecycle, or the daemon-owned issue tracker from a shell. Also the ONLY channel for messaging another agent session on this machine — `rove api send`, never a peer/MCP side channel.
Sma1lboy/rove · ★ 141 · AI & Automation · score 81
Install: claude install-skill Sma1lboy/rove
<!-- rove-skill-version: 32 — bump in lockstep with KOBE_SKILL_VERSION (src/lib/skill-install.ts). --> # Rove shell control Use `rove api` to manage local coding tasks. Managed Tasks created by API automation own a git Worktree and branch plus Hosted PTY engine tabs; project main and directory Tasks reuse existing directories. API automation works without an open TUI; prompted `send` and `add` ensure a target engine tab. ## Inside a Rove session, Rove verbs come first Check where you are before choosing how to delegate or parallelize: ```bash test -n "${ROVE_TASK_ID:-}" ``` When that passes, you are an engine session Rove manages — `$ROVE_TASK_ID` is your task, `$ROVE_TAB_ID` your tab. Coordination should then go through Rove, not around it, because work routed through `rove api` gets what ad-hoc subprocesses never do: its own Worktree and branch (no file collisions with you), a sidebar row with live state the user can watch, lifecycle tracking, and an explicit outcome contract. - Parallel attempts of one prompt → `add --count N`, not N hand-rolled subagents. - Delegating a scoped piece of work → `add --prompt`, not a raw `claude -p` child the user cannot see or manage. - Following up on a task you started → `send`; comparing → `collect`; finished your own task and were spawned by another → a bare `send` (no `--task-id`) replies to the DISPATCHER — the exact task + tab that created you, recorded at creation (`.task.dispatcher` on `get-task`). If that tab died