claude-code-kanban 5.4.0 → 6.0.0

package/plugin/plugins/claude-code-kanban/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-kanban",
-  "version": "2.21.4",
+  "version": "2.22.0",
   "description": "claude-code-kanban dashboard integration: agent activity tracking, context and cost tracking, skills to drive the board from a session and to follow it",
   "experimental": {
     "monitors": "./monitors.json"

package/plugin/plugins/claude-code-kanban/monitors.json

@@ -4,11 +4,5 @@
     "description": "Notifies this session when its tasks are moved on the kanban board or the user sends it review comments.",
     "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/postman.js\"",
     "when": "on-skill-invoke:claude-code-kanban:follow"
-  },
-  {
-    "name": "kanban-dispatch-inbox",
-    "description": "Notifies this session when a session it dispatched through cck reports or exits.",
-    "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/postman.js\" --topic dispatch --keep-backlog",
-    "when": "on-skill-invoke:claude-code-kanban:dispatch"
   }
 ]

package/plugin/plugins/claude-code-kanban/scripts/postman.js

@@ -29,10 +29,6 @@ const RETRY_MS = 15000;
 // Windows sometimes fails a loopback connect with ETIMEDOUT, or resets it once open, while the
 // board is up, so those errors get a few short waits before the normal one.
 const CONNECT_RETRY_MS = [250, 500, 1000, 2000];
-// `--topic dispatch` is the dispatch inbox: reports from sessions this one started.
-const TOPIC = process.argv.includes('--topic') ? process.argv[process.argv.indexOf('--topic') + 1] : null;
-// A dispatch report is a result, not an instruction, so a late attach still wants it.
-const KEEP_BACKLOG = process.argv.includes('--keep-backlog');
 
 if (!SESSION_ID) process.exit(0);
 
@@ -53,12 +49,11 @@ function serverUrl() {
 // Once per process, not once per poll: the grant means "follow the board from here on", so
 // the first attach throws away whatever queued up before it. A later reconnect must not
 // discard again -- by then the queue holds events the user is owed.
-let firstAttach = !KEEP_BACKLOG;
+let firstAttach = true;
 
 async function poll(base) {
   const first = firstAttach ? '&first=1' : '';
-  const topic = TOPIC ? `&topic=${encodeURIComponent(TOPIC)}` : '';
-  const url = `${base}/api/sessions/${encodeURIComponent(SESSION_ID)}/events?wait=${WAIT_SEC}${first}${topic}`;
+  const url = `${base}/api/sessions/${encodeURIComponent(SESSION_ID)}/events?wait=${WAIT_SEC}${first}`;
   const res = await fetch(url, { signal: AbortSignal.timeout((WAIT_SEC + 15) * 1000) });
   if (!res.ok) throw new Error(`HTTP ${res.status}`);
   firstAttach = false;

package/plugin/plugins/claude-code-kanban/skills/dispatch/SKILL.md

@@ -1,23 +1,29 @@
 ---
 name: dispatch
-description: Dispatch a task to another Claude Code session through the kanban board (cck), fire-and-forget or with a report back. Use when the user asks to dispatch, delegate, or start a session for a task, or to collect or check on a dispatched session's result.
-argument-hint: '<task> [--no-report] [--group <name>] [--model haiku|sonnet|opus|fable] [--worktree [name]]'
+description: Dispatch tasks to new Claude Code sessions in the kanban board's terminal. Use when the user asks to dispatch or delegate a task to another session.
+argument-hint: '<task> [--handoff] [--group <name>] [--model haiku|sonnet|opus|fable] [--worktree [name]] [-- <claude args>]'
 ---
 
 # Kanban dispatch
 
-This file only points at the guide. The guide ships with the `claude-code-kanban` binary, so it always matches the commands that binary accepts.
-
-Invoking this skill also arms this session's dispatch inbox: when a session you dispatched with `--report` reports or exits, a line arrives here:
-
-```
-[kanban board] Dispatch <dispatch-id> (session <uuid>) <reported success|reported failure|ended without a report>. Summary: <text>
-```
-
-Load the guide before running any dispatch command:
+The guide ships with the `claude-code-kanban` binary, so it always matches the commands that binary accepts. Load it before running any dispatch command:
 
 ```bash
 claude-code-kanban skills get dispatch
 ```
 
 Fall back to `npx claude-code-kanban` when the bare binary is not on PATH. If `skills get` is unknown, the installed cck is too old: tell the user to update it, and do not guess commands.
+
+## Reply
+
+End every spec with the reply line, because you usually need the result to continue:
+
+```text
+When you are done, or cannot finish, send the result to <your peer name> with the SendMessage tool, then stop.
+```
+
+`--handoff` is a skill argument that drops the reply line: the session owns the task, and the user follows it on the board. Keep it out of the `dispatch start` command.
+
+## Orchestration patterns
+
+Use request-reply, handoff or orchestrator-workers directly. When another shape fits better (a separate reviewer, steps that feed each other, a sub-orchestrator, a decision for the user), propose it in one line, the pattern and why, and dispatch only after the user agrees, unless the user named it. Details: [references/orchestration-patterns.md](references/orchestration-patterns.md).

package/plugin/plugins/claude-code-kanban/skills/dispatch/references/orchestration-patterns.md

@@ -0,0 +1,50 @@
+# Orchestration patterns
+
+Each pattern is only `dispatch start` plus `SendMessage`; the specs decide who talks to whom. A **worker** is a session you dispatch.
+
+## Select
+
+Use one of these directly:
+
+| Pattern | When |
+|---|---|
+| Request-reply | The default |
+| Handoff | The user passed `--handoff` or asked for no reply |
+| Orchestrator-workers | The task splits into parts that do not depend on each other |
+
+Propose these first, unless the user named one. Each adds steps, rounds or sessions the user did not ask for.
+
+| Pattern | Fits when |
+|---|---|
+| Prompt chaining | A step needs the previous step's output |
+| Evaluator-optimizer | There is a clear acceptance bar and a second look improves the result |
+| Hierarchical | A part is itself large enough to split |
+| Human-in-the-loop | The spec leaves a choice the user should make |
+
+## Request-reply
+
+One worker, one reply. The reply can go to any peer. When another session owns the work and should act on the result, name it in the reply line, and ask for a one-line note to you as well, so you know the worker finished.
+
+## Handoff
+
+One worker, no reply line. The worker owns the task, and you save the turn a reply costs.
+
+## Orchestrator-workers
+
+One worker per independent part, all started before you wait on any. They run at the same time, and each holds only its own part in context. Give each a unique `--name` and one shared `--group`, then combine the replies.
+
+## Prompt chaining
+
+Workers in sequence; each spec carries the previous reply. You check each output before you start the next step, and stop the chain when a check fails.
+
+## Evaluator-optimizer
+
+A generator and an evaluator that message each other until the evaluator accepts. A separate evaluator judges the work with fresh eyes. Give each the other's name, and cap the rounds in both specs: `stop after 3 rounds and send what you have`.
+
+## Hierarchical
+
+A worker that dispatches its own workers and replies once they all have. Your context then holds one reply per part instead of one per leaf. Its spec says to wait for its workers and to give them its own peer name.
+
+## Human-in-the-loop
+
+Add to the worker's spec: `When you need a decision, ask <your peer name> with the SendMessage tool and keep working on what does not depend on the answer.` Ask the user when the decision is theirs, and reply with `SendMessage`. You can steer a running worker the same way at any time.