@sma1lboy/kobe 0.8.120 → 0.8.122
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/index.js +125 -125
- package/dist/cli/kobe.js +125 -125
- package/dist/cli/rove.js +125 -125
- package/dist/skills/rove/SKILL.md +60 -1
- package/package.json +1 -1
|
@@ -3,7 +3,7 @@ name: rove
|
|
|
3
3
|
description: 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.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
<!-- rove-skill-version:
|
|
6
|
+
<!-- rove-skill-version: 28 — bump in lockstep with KOBE_SKILL_VERSION (src/lib/skill-install.ts). -->
|
|
7
7
|
|
|
8
8
|
# Rove shell control
|
|
9
9
|
|
|
@@ -139,6 +139,65 @@ branch, and which sibling tabs exist" — `.tabs[]` carries each tab's `id`, `ki
|
|
|
139
139
|
`send --tab`. A tab flagged `unregistered: true` is a live session the tab
|
|
140
140
|
snapshot lost; it is addressable like any other.
|
|
141
141
|
|
|
142
|
+
## Found a defect in ANOTHER project? File a request, don't work around
|
|
143
|
+
|
|
144
|
+
The repos on this machine are deliberately interdependent — one project
|
|
145
|
+
using (and stumbling over) another is the normal case, not the edge case.
|
|
146
|
+
Each saved project can keep a **main task**: a long-lived resident agent on
|
|
147
|
+
that repo's own checkout. It is more than "task kind = existing directory" —
|
|
148
|
+
it is that project's standing inbox, addressable from any other repo's
|
|
149
|
+
session, and it dispatches what it receives.
|
|
150
|
+
|
|
151
|
+
So when work in repo A surfaces a defect in product B, the default is to
|
|
152
|
+
**file a request with B's main task — not to quietly patch around it in A**.
|
|
153
|
+
The test: would this bite someone else? A local workaround fixes only you;
|
|
154
|
+
a fix in B fixes everyone. Work around locally to unblock yourself if you
|
|
155
|
+
must, but file the report either way.
|
|
156
|
+
|
|
157
|
+
```bash
|
|
158
|
+
rove api list # find B's main task id
|
|
159
|
+
rove api get-task --task-id <their-main> # .tabs[] → the engine tab's id
|
|
160
|
+
rove api send --task-id <their-main> --tab tab-N --prompt "<report>"
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
Address the engine tab explicitly (`--tab tab-N` from `get-task`'s `.tabs[]`,
|
|
164
|
+
`kind == "engine"`): a long-lived main task's engine tab is often not
|
|
165
|
+
`tab-1`, and an un-addressed `send` may refuse with `NO_ENGINE_TAB` rather
|
|
166
|
+
than guess.
|
|
167
|
+
|
|
168
|
+
A report worth sending carries: **symptoms** (what happened, concretely, how
|
|
169
|
+
many times), **root cause** if you found it, **why it is worth fixing**
|
|
170
|
+
(who else it bites), and **suggestions without prescribing the
|
|
171
|
+
implementation** — the receiving project decides how to fix its own product.
|
|
172
|
+
|
|
173
|
+
**Send the report — never `add` a task into someone else's repo.** You hold
|
|
174
|
+
the problem-side context (symptoms, root cause, impact); only that project's
|
|
175
|
+
main agent holds the solution-side context (code structure, existing issues,
|
|
176
|
+
what's mid-flight, where this slots in the schedule). A task you compose
|
|
177
|
+
would bake YOUR guess at the fix into the brief, and that guess is usually
|
|
178
|
+
wrong — one field report here looked like "add a line to the docs" and
|
|
179
|
+
actually split into a docs fix plus a runtime-detection issue anchored in
|
|
180
|
+
files the reporter didn't know existed. **You raise the problem; their main
|
|
181
|
+
agent decomposes it into tasks.** That translation is the main task's whole
|
|
182
|
+
job, and it is why every project should keep one.
|
|
183
|
+
|
|
184
|
+
## Fresh worktrees start empty — install before you judge
|
|
185
|
+
|
|
186
|
+
A managed task's worktree is a **brand-new checkout**: no `node_modules`, no
|
|
187
|
+
build artifacts, nothing a lockfile promises. Two consequences:
|
|
188
|
+
|
|
189
|
+
- **A test failure in a fresh worktree may be fake.** Missing dependencies
|
|
190
|
+
masquerade as product bugs ("Could not resolve: react-dom/client" reads
|
|
191
|
+
like a regression, not a missing install). Before reporting any failure as
|
|
192
|
+
real, confirm the repo's install step ran — and when a failure looks
|
|
193
|
+
unrelated to your change, compare against the same command on the base
|
|
194
|
+
branch before believing it.
|
|
195
|
+
- **Repos with an install step should ship `.rove/init.sh`** — it runs once
|
|
196
|
+
per worktree, before the engine, in the worktree (per-user override:
|
|
197
|
+
`rove repo set --init-script`; inspect with `rove repo show`, which lists
|
|
198
|
+
`.rove/init.sh: absent` when unset). Working in a repo that lacks one and
|
|
199
|
+
you just paid the install tax? Suggest adding it.
|
|
200
|
+
|
|
142
201
|
## Discover before calling
|
|
143
202
|
|
|
144
203
|
```bash
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "@sma1lboy/kobe",
|
|
4
|
-
"version": "0.8.
|
|
4
|
+
"version": "0.8.122",
|
|
5
5
|
"description": "Rove — the agent multiplexer for your terminal. Run coding agents on parallel tasks with isolated worktrees and persistent sessions.",
|
|
6
6
|
"type": "module",
|
|
7
7
|
"packageManager": "bun@1.3.13",
|