@sma1lboy/kobe 0.8.76 → 0.8.77
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 +319 -319
- package/dist/skills/kobe/SKILL.md +24 -12
- package/package.json +1 -1
|
@@ -3,7 +3,7 @@ name: kobe
|
|
|
3
3
|
description: Use when controlling kobe tasks, parallel coding attempts, hosted agent sessions, task lifecycle, or the daemon-owned issue tracker from a shell.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
<!-- kobe-skill-version:
|
|
6
|
+
<!-- kobe-skill-version: 17 — bump in lockstep with KOBE_SKILL_VERSION (src/lib/skill-install.ts). -->
|
|
7
7
|
|
|
8
8
|
# kobe shell control
|
|
9
9
|
|
|
@@ -30,15 +30,21 @@ lifecycle tracking, and an explicit outcome contract.
|
|
|
30
30
|
- Delegating a scoped piece of work → `add --prompt`, not a raw `claude -p`
|
|
31
31
|
child the user cannot see or manage.
|
|
32
32
|
- Following up on a task you started → `send`; comparing → `collect`;
|
|
33
|
-
finished your own task and were spawned by another → `send`
|
|
34
|
-
|
|
33
|
+
finished your own task and were spawned by another → a bare `send`
|
|
34
|
+
(no `--task-id`) replies to the DISPATCHER — the exact task + tab that
|
|
35
|
+
created you, recorded at creation (`.task.dispatcher` on `get-task`).
|
|
36
|
+
If that tab died it falls back to the dispatcher task's live canonical
|
|
37
|
+
engine tab; nothing alive fails loud (`DISPATCHER_UNREACHABLE`) — it
|
|
38
|
+
never spawns a new engine, so a failed reply is visible, not fake-ok.
|
|
35
39
|
- Messaging another task's agent → `send`, and ONLY `send` — never relay
|
|
36
40
|
through the user, a side file, or a generic peer channel. Sent from
|
|
37
41
|
inside a kobe task, the prompt arrives prefixed `[KOBE PEER] from
|
|
38
42
|
"<title>" (task <id> — load the kobe agent skill FIRST …)`, so the
|
|
39
43
|
receiver knows who is talking, that this skill is required reading, and
|
|
40
|
-
how to answer —
|
|
41
|
-
|
|
44
|
+
how to answer — the baked-in reply command is tab-precise
|
|
45
|
+
(`--task-id <sender> --tab <sender's tab>`), so peer conversations need
|
|
46
|
+
no coordinator and no human relay. That prefix is the contract: do not
|
|
47
|
+
strip it with `--plain` for
|
|
42
48
|
coordination messages (`--plain` is only for a verbatim paste the
|
|
43
49
|
receiver should treat as content, not conversation). Received a
|
|
44
50
|
`[KOBE PEER]` message yourself? Load this skill first — required, not
|
|
@@ -86,6 +92,9 @@ kobe api fan-out --repo "$PWD" --agents claude:2,codex:1 --prompt "<prompt>"
|
|
|
86
92
|
# (sender + reply command); --plain sends verbatim.
|
|
87
93
|
kobe api send --task-id <id> --prompt "<complete next turn>"
|
|
88
94
|
|
|
95
|
+
# Reply home: no --task-id inside a dispatched task = the dispatcher's tab.
|
|
96
|
+
kobe api send --prompt "succeeded: <one line> (branch <final branch>)"
|
|
97
|
+
|
|
89
98
|
# A task can hold several chat tabs. Enumerate them first (inspect's .tabs is
|
|
90
99
|
# the sidebar's tab snapshot: id, kind, vendor, lastTitle), then address one:
|
|
91
100
|
kobe api inspect --task-id <id>
|
|
@@ -98,8 +107,10 @@ kobe api list --pretty
|
|
|
98
107
|
```
|
|
99
108
|
|
|
100
109
|
`.running` means the task's canonical Hosted PTY engine session is alive.
|
|
101
|
-
Omitting `--tab`
|
|
102
|
-
|
|
110
|
+
Omitting BOTH `--task-id` and `--tab` inside a task that has a dispatcher
|
|
111
|
+
targets that dispatcher's tab (see the reply rule above); otherwise the
|
|
112
|
+
target is the active task. Omitting only `--tab` targets a live engine tab
|
|
113
|
+
(`tab-1` first, then any surviving engine tab). Only when the task has NO live session at all does `send`
|
|
103
114
|
auto-start the canonical engine in the task's worktree (`started: true` in
|
|
104
115
|
the result marks that fresh session). If live tabs exist but none resolves
|
|
105
116
|
as an engine, it refuses with `NO_ENGINE_TAB` — address one with `--tab
|
|
@@ -190,11 +201,12 @@ engine turn.
|
|
|
190
201
|
Outcomes are explicit, never inferred — and they travel as a MESSAGE to the
|
|
191
202
|
spawning agent's chat tab, not as stored state nobody reads.
|
|
192
203
|
|
|
193
|
-
**Worker side** — a task created from inside another kobe task
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
"
|
|
197
|
-
branch name — the spawner needs it to `land`.
|
|
204
|
+
**Worker side** — a task created from inside another kobe task records its
|
|
205
|
+
dispatcher (the creating task + tab); when the work is finished, a bare
|
|
206
|
+
`kobe api send --prompt "<succeeded|failed>: <one line> (branch <final
|
|
207
|
+
branch>)"` routes the outcome back to that exact tab. Include the final
|
|
208
|
+
branch name — the spawner needs it to `land`. The first-prompt coda still
|
|
209
|
+
names the spawner for an explicit `--task-id` send.
|
|
198
210
|
|
|
199
211
|
**Coordinator side** — do NOT block or poll. Keep working (or end your
|
|
200
212
|
turn); each worker's outcome arrives in your chat as a `[KOBE PEER]` message
|
package/package.json
CHANGED