@wirecat/cli-core 0.404.0 → 0.406.0

package/skills/follow-ups/SKILL.md

@@ -67,13 +67,13 @@ For a chat in `owed` or `waiting`: read around its `lastMessage` the same way.
 | What you see | Do |
 |---|---|
 | A promise, a request, a question someone waits on | `tasks add <msg> --type promise\|request\|question --category <name>` with a plan; `tasks categories` lists the names |
-| `tasks add` answers `created: false` | the message already has that task (a rule made it): `tasks plan` that one |
+| `tasks add` answers `created: false` | the message already has that task (a rule made it): `tasks update` that one |
 | `tasks add` refuses with `task.duplicate-candidates` | read the listed tasks: the same job → repeat with `--into <key>`; a different one → repeat with `--new` |
 | `tasks add` answers `follow_up_of` | the message is about a task closed lately: a new task was opened and linked to it, the closed one stays closed — plan the new one |
-| `tasks duplicates` lists pairs a rule opened | one job → `tasks merge <task> --into <other>`; two jobs → `tasks duplicates reject <task> <other>`; the meaning cannot tell (mum's gift or dad's) → `tasks duplicates defer <task> <other>` for the owner. A wrong merge: `tasks unmerge <task>` |
+| `tasks duplicates list` lists pairs a rule opened | one job → `tasks merge <task> --into <other>`; two jobs → `tasks duplicates reject <task> <other>`; the meaning cannot tell (mum's gift or dad's) → `tasks duplicates defer <task> <other>` for the owner. A wrong merge: `tasks unmerge <task>` |
 | A task that is done (the reply came, the file was sent) | `tasks close <key> --as done --certainty <0..1> --reason "<one line>"` — say honestly how sure you are; below the owner's threshold the task stays open with `close_suggestion` and the owner decides, so do not close it again |
-| A task still open, nothing new | `tasks plan <key> --remind-time <when>` — 1d if hot, 3d–7d if not |
-| A task with the wrong category | `tasks plan <key> --category <name>` |
+| A task still open, nothing new | `tasks update <key> --remind-time <when>` — 1d if hot, 3d–7d if not |
+| A task with the wrong category | `tasks update <key> --category <name>` |
 | A task you are about to work on with other agents around | `tasks claim <key>`, and `tasks release <key>` when you stop |
 | An `owed` chat that needs no answer (thanks, a sticker) | nothing; it leaves the agenda on the next message |
 | A `waiting` chat with an open question of the owner's | a task for it, and a follow-up draft |
@@ -81,7 +81,7 @@ For a chat in `owed` or `waiting`: read around its `lastMessage` the same way.
 Every task gets a plan, so the next run needs no rereading:
 
 ```sh
-{{command}} tasks plan <key> --title "<action and its object>" --due <when> --remind-time <when> \
+{{command}} tasks update <key> --title "<action and its object>" --due <when> --remind-time <when> \
   --description "Owes: <me → them | them → me>
 Counterpart: <name>
 Done when: <one observable line>

package/skills/link-conversations/SKILL.md

@@ -10,14 +10,14 @@ metadata:
 A busy group mixes several conversations at once. `{{command}}` already links what it can without
 you: the messenger's own replies, mentions, and one person's messages in a row. You decide the rest:
 for each message, **which earlier message it answers**, or that it starts a new conversation. You
-read the messages; `{{command}}` checks and stores your answers. By default it leaves analysis to your agent. An explicit configured analysis provider can also process these batches through `conversations build --analyze`; that path asks for consent and validates the same answers.
+read the messages; `{{command}}` checks and stores your answers. By default it leaves analysis to your agent. An explicit configured analysis provider can also process these batches through `conversations links rebuild --analyze`; that path asks for consent and validates the same answers.
 
 ## Before the first batch: say what it costs, and wait
 
 The messages you read go into your own context, and through it to your model's provider. So first:
 
 ```sh
-{{command}} conversations build --chat "<chat>"                       # the rules' links, as candidates for you
+{{command}} conversations links rebuild --chat "<chat>"                       # the rules' links, as candidates for you
 {{command}} conversations batches status --chat "<chat>" --json
 ```
 
@@ -27,7 +27,7 @@ quarter as many tokens). **Wait for a yes.** A yes for one chat is not a yes for
 ## The loop
 
 ```sh
-{{command}} conversations batches next --chat "<chat>" --json         # one batch, or null when done
+{{command}} conversations batches show --chat "<chat>" --json         # one batch, or null when done
 ```
 
 A batch is `{ "batch": "<id>", "messages": [...], "remaining": {...} }`. Each message has `id`, `at`,
@@ -53,8 +53,8 @@ Then store the answer, as JSON on stdin:
 ANSWER
 ```
 
-Repeat `batches next` until it answers `null`. Then rebuild once, so your answers shape the
-conversations: `{{command}} conversations build --chat "<chat>"`. On a long chat, rebuild every 20
+Repeat `batches show` until it answers `null`. Then rebuild once, so your answers shape the
+conversations: `{{command}} conversations links rebuild --chat "<chat>"`. On a long chat, rebuild every 20
 batches too, so the owner sees progress.
 
 ## When an answer is refused
@@ -80,9 +80,9 @@ was added or deleted inside it: ask for the next batch instead.
 ## Through MCP
 
 Follow the same cost gate and loop through MCP: each step is the same command, run with
-`{{command}}_read` (`conversations batches status`, `conversations batches next`,
-`conversations show`) or `{{command}}_write` (`conversations build`, `conversations links add`,
-`conversations links clear`), as `{ "command": "conversations build", "arguments": { … } }`.
+`{{command}}_read` (`conversations batches status`, `conversations batches show`,
+`conversations show`) or `{{command}}_write` (`conversations links rebuild`, `conversations links add`,
+`conversations links clear`), as `{ "command": "conversations links rebuild", "arguments": { … } }`.
 `{{command}}_tools_search` shows each one's arguments.
 
 Use `chat` for the chat reference, and `size` for the batch size (10–200, default 50).