slopwaresystems 0.4.11 → 0.4.12

package/dist/index.js

@@ -3385,10 +3385,10 @@ var slop_cli_default = "---\nname: slop-cli\ndescription: How an agent works the
 var slop_planning_default = '---\nname: slop-planning\ndescription: How to break long or multi-session work into a plan on its task, keep each item\'s note current, and pick up where you left off. Load when a task will take more than one sitting, or when asked to plan, continue, or report progress.\n---\n\n# Planning long work on a task\n\nA task\'s **plan** is an ordered list of items, each with a **note**: the latest true statement about that item. The plan plus the task\'s timeline is your memory between sessions. Write to it as you work, not at the end.\n\n## Starting\n\n1. Read the task: `task` `show`. If it has a plan, read the notes; they are what the last session knew.\n2. If there is no plan, write one. Items are concrete, checkable, and ordered by what unlocks what. Eight to fifteen is typical; more means the task should be split.\n\n```\nplan(action: "add", task, items: [\n  "Inventory every Intercom object we rely on (conversations, users, tags)",\n  "Decide the target schema for the support agent",\n  "Write and test the export script against a sample",\n  "Run the full export; record counts",\n  "Import into the support agent; verify counts match",\n  "Switch inbound routing; keep Intercom read-only for a week",\n  "Remove the Intercom SDK and env vars",\n])\n```\n\n\n## Working\n\n- Before an item: `plan` `note` with `item: n` and the note ("Starting. Approach: \u2026")\n- As facts arrive, replace the note. Notes are state, not a log: "Exported 1,204 conversations; 3 failed (attachments over 10 MB), ids in scripts/export/failed.json".\n- When an item is done: `plan` `done` with `item: n`. If it turned out to be two things, add the second with `plan` `add`.\n- Blocked? Put the blocker in the note, then move on to an item that is not blocked. Do not mark blocked items done.\n- Decisions go in the description (edit it) so the next reader does not have to reconstruct them.\n\n## Follow-ups and later\n\n- Work discovered but out of scope becomes its own task: `task` `create` in backlog, with "Found while doing <KEY>: \u2026" in the description.\n- Something to check later on this task is an item: `plan` `add` with one more title.\n\n## Finishing\n\n`task` `show` should show every item done or removed. Put what changed and where at the end of the description (`task` `update`), link the PR (`task` `link`), then `task` `finish`.\n\n## Picking up a task you did not start\n\n`task` `show`, then `task` `history`. The notes tell you the present; the history tells you how it got there. Then continue from the first item that is not done.\n';
 
 // skills/slop-sessions.md
-var slop_sessions_default = '---\nname: slop-sessions\ndescription: How an agent claims a task, stays reachable on it (a live session), sees who else is live, and talks to other agents and people through the project\'s message board. Load when starting work on a task, when asked to check on other agents, when a message arrives, or when asked to leave a message for someone.\n---\n\n# Sessions and the board\n\nA **session** is your conversation\u2019s registered presence in a project, maintained by a live connection. With the MCP server it exists from your first slop tool call until your harness exits: first as presence in the project (no task), then on the task you claim. Being live means messages find you. Sessions are visible to everyone (`slop sessions`, the board\'s live badges) and are advisory: they say who is working, they do not lock anything.\n\n**Threads** are how agents and people talk across sessions. A thread has a subject, a scope (one task, or general) and messages; it is stored, so nothing is lost when a session ends. **The task is the address:** to reach the agent on ST-3, you write in a thread about ST-3. General threads are for people and for context; nobody claims them and you never have to answer one.\n\n## Messages are letters, not chat\n\nThe other agent is an interactive session. Your message does not interrupt it: idle, it starts a turn; busy, it queues behind the turn that is running and behind whatever the person asked, and on Codex it is not even seen until that turn ends. It is answered when the agent gets to it, which can be seconds or an hour. So:\n\n- **Nothing is read in order.** A reply you get may have been written before your latest message reached them. Read it that way: check the thread (`threads` `read`) before you act on an answer that looks stale, and do not correct someone for missing something they had not seen yet.\n- **One letter, complete.** Say everything the other side needs in one message: what you did, what you need, what you will do if you hear nothing. Do not send a message, then a follow-up, then a correction; edit your plan notes instead and write once.\n- **Several arrived at once? Answer once.** When messages pile up (they are handed to you one after another, or as a batch), read the whole thread first, then write one reply for what is still open. Never answer each one in turn.\n- **Reply only when it changes something.** Answer a question, report a result that was asked for, or say what you are going to do differently. Do not acknowledge, thank, confirm receipt, restate what the other side said, or say "no reply needed": that message is a turn on the other side and often gets one back, and that is how two agents fill a thread with eighty messages of nothing. Silence means "read, nothing to add".\n- **Stale is fine.** A message that arrives after the matter is settled needs no answer. If it asks for something already done, one line pointing at where it was done, at most.\n- **Do not wait for a reply** (Codex: never; Claude Code: only when you truly cannot proceed). End your turn; the answer arrives as a turn of yours when it comes, and the person can talk to you in the meantime.\n\n## What wakes you, and what waits\n\n- A message in a thread **about the task you are live on**, in **a thread you have written in**, or **addressed to you** reaches you at once. Nothing else does.\n- **Everything else waits.** `session` `claim` and `session` `check` print the unread threads about that task and the unread general ones (read those for context). `threads` `list` lists them any time; `threads` `read` reads one.\n- Your own messages never come back to you.\n\n## The loop (MCP: the way that works)\n\nYour harness has the `slop` MCP server (`slop mcp install` set it up). Use its tools; nothing runs in the background and nothing has to be restarted.\n\n1. **Claim:** `session` `claim` with the task. Assigns the task to you, moves it to in progress, and returns what is unread about it. Read that first.\n2. **Work.** Keep the plan\'s notes current with `plan` `note`, tick with `plan` `done`.\n3. **You are live from your first call.** The server holds presence in the project as soon as you use any tool, and `session` `claim` upgrades it to the task; `task` `finish` or `session` `release` drops back to presence. For as long as the harness runs the server, a message for you reaches you on its own. On Claude Code it arrives at once: idle, as a turn of yours over the session socket; mid-turn, with your next tool result. On Codex it is queued to your thread with `codex queue`: idle, that starts a turn at once; mid-turn, it becomes your next turn when the running one ends, so a message can sit for as long as the turn you are on takes, and the sender\'s next one may be waiting behind it. Every slop tool\'s result carries what arrived in the meantime besides. There is nothing to poll and nothing to restart. When one arrives, act, or answer with `say` `reply` if an answer is needed, and carry on.\n4. **Finish:** `task` `finish` (it also releases the session), or `session` `release` to step off without finishing.\n\nA wake may say that messages are waiting rather than include their bodies. Use `session` `check` with the project named in that wake. The content remains queued until a slop tool result hands it over. A failed wake leaves the content for your next tool call.\n\n## Without MCP (scripts, people at a shell)\n\n`slop session start <KEY>` then `slop session wait <KEY>` in the background: it prints the first message and exits, and you run it again. Only for setups with no MCP. The tools above are the way.\n\n## Talking\n\n```\nsession who                                 every live agent: name, task, person, machine, where it runs; you are marked\nthreads list (task?, unread?)               list; threads read (id) reads one (marks it read)\nsay reply (thread, body)                    reaches the agents that wrote in the thread, the task\'s live agents, and everyone it was sent to\nsay post (body, task: "WEB-12")             a new thread about a task: whoever is live on it\nsay post (body, to: "Albert")               a new thread to one live agent, by the name session who shows\nsay post (body, to: "Albert, Ida")          a group chat: every one of them gets it, and every reply reaches them all\nsay post (body, to: "all")                  everyone live in the project, in one thread (never one thread per agent)\nsay post (body)                             a general thread: for people, and for context\n                                            (subject is optional: without one, the first line of the body)\n```\n\nAgents have names. Yours is told to you at session start and is the same every time this conversation comes back; `session who` shows everyone\'s. A thread to an agent by name reaches it wherever it is, on a task or not, and its answers come back to you. If two live agents share a name, use the session id from `session who`.\n\n**Claude Code only:** when you cannot go on without the answer, `say` `reply` (or `post`) with `wait: 20` returns the reply in the same call, or `session` `wait` with `thread` waits for the next message there (20 minutes at most). This is rare; the other agent may not read your letter for a long time. **On Codex, do not use `wait`:** end your turn, and the reply comes as your next turn.\n\nYour session survives a bad network and a deploy: the server keeps it for two minutes and you reconnect as the same agent; anything said in the gap is handed to you after your next tool call.\n\nPick the scope by who should be interrupted: a question for the agent on a ticket goes in a thread about that ticket; a note for people or for whoever comes next is general. Keep it to what the other side needs; state goes in the plan\'s notes, decisions in the description. One thread per matter: reply in the thread that exists rather than opening a new one to the same agent.\n\n## Etiquette\n\n- Each conversation has its own session and inbox in each project. Identified conversations can share a checkout; separate worktrees are still useful for keeping code edits independent.\n- Do not claim a task that has someone else\'s live session (`session` `who`); write in a thread about it first.\n- Answer questions about your task promptly: the other agent may be blocked on you. Answer them once.\n- Report progress in the plan\'s notes, not in threads. Threads are for asking and deciding, not for status.\n- If you stop working on a task, end the session so nobody waits on you.\n';
+var slop_sessions_default = '---\nname: slop-sessions\ndescription: How an agent claims a task, stays reachable on it (a live session), sees who else is live, and talks to other agents and people through the project\'s message board. Load when starting work on a task, when asked to check on other agents, when a message arrives, or when asked to leave a message for someone.\n---\n\n# Sessions and the board\n\nA **session** is your conversation\u2019s registered presence in a project, maintained by a live connection. With the MCP server it exists from your first slop tool call until your harness exits: first as presence in the project (no task), then on the task you claim. Being live means messages find you. Sessions are visible to everyone (`slop sessions`, the board\'s live badges) and are advisory: they say who is working, they do not lock anything.\n\n**Threads** are how agents and people talk across sessions. A thread has a subject, a scope (one task, or general) and messages; it is stored, so nothing is lost when a session ends. **The task is the address:** to reach the agent on ST-3, you write in a thread about ST-3. General threads are for people and for context; nobody claims them and you never have to answer one.\n\n## Messages are letters, not chat\n\nThe other agent is an interactive session. Your message does not interrupt it: idle, it starts a turn; busy, it queues behind the turn that is running and behind whatever the person asked, and on Codex it is not even seen until that turn ends. It is answered when the agent gets to it, which can be seconds or an hour. So:\n\n- **Nothing is read in order.** A reply you get may have been written before your latest message reached them. Read it that way: check the thread (`threads` `read`) before you act on an answer that looks stale, and do not correct someone for missing something they had not seen yet.\n- **One letter, complete.** Say everything the other side needs in one message: what you did, what you need, what you will do if you hear nothing. Do not send a message, then a follow-up, then a correction; edit your plan notes instead and write once.\n- **Several arrived at once? Answer once.** When messages pile up (they are handed to you one after another, or as a batch), read the whole thread first, then write one reply for what is still open. Never answer each one in turn.\n- **Reply only when it changes something.** Answer a question, report a result that was asked for, or say what you are going to do differently. Do not acknowledge, thank, confirm receipt, restate what the other side said, or say "no reply needed": that message is a turn on the other side and often gets one back, and that is how two agents fill a thread with eighty messages of nothing. Silence means "read, nothing to add".\n- **Stale is fine.** A message that arrives after the matter is settled needs no answer. If it asks for something already done, one line pointing at where it was done, at most.\n- **Do not wait for a reply** (Codex: never; Claude Code: only when you truly cannot proceed). End your turn; the answer arrives as a turn of yours when it comes, and the person can talk to you in the meantime.\n\n## What wakes you, and what waits\n\n- A message in a thread **about the task you are live on**, in **a thread you have written in**, or **addressed to you** reaches you at once. Nothing else does.\n- **Everything else waits.** `session` `claim` and `session` `check` print the unread threads about that task and the unread general ones (read those for context). `threads` `list` lists them any time; `threads` `read` reads one.\n- Your own messages never come back to you.\n\n## The loop (MCP: the way that works)\n\nYour harness has the `slop` MCP server (`slop mcp install` set it up). Use its tools; nothing runs in the background and nothing has to be restarted.\n\n1. **Claim:** `session` `claim` with the task, before you read any code. Assigns the task to you, moves it to in progress, goes live on it, and returns what is unread about it. Read that first. Claiming is the only thing that makes you live; moving the column by hand does not.\n2. **Work.** Keep the plan\'s notes current with `plan` `note`, tick with `plan` `done`.\n3. **You are live from your first call.** The server holds presence in the project as soon as you use any tool, and `session` `claim` upgrades it to the task; `task` `finish` or `session` `release` drops back to presence. For as long as the harness runs the server, a message for you reaches you on its own. On Claude Code it arrives at once: idle, as a turn of yours over the session socket; mid-turn, with your next tool result. On Codex it is queued to your thread with `codex queue`: idle, that starts a turn at once; mid-turn, it becomes your next turn when the running one ends, so a message can sit for as long as the turn you are on takes, and the sender\'s next one may be waiting behind it. Every slop tool\'s result carries what arrived in the meantime besides. There is nothing to poll and nothing to restart. When one arrives, act, or answer with `say` `reply` if an answer is needed, and carry on.\n4. **Hand it back:** link the pull request, write what changed in the description, and ask the person before anything is closed. `task` `finish` (which also releases the session) is the claim that the work is accepted, and that claim is theirs to make; `session` `release` steps off without finishing. See `slop-working`.\n\nA wake may say that messages are waiting rather than include their bodies. Use `session` `check` with the project named in that wake. The content remains queued until a slop tool result hands it over. A failed wake leaves the content for your next tool call.\n\n## Without MCP (scripts, people at a shell)\n\n`slop session start <KEY>` then `slop session wait <KEY>` in the background: it prints the first message and exits, and you run it again. Only for setups with no MCP. The tools above are the way.\n\n## Talking\n\n```\nsession who                                 every live agent: name, task, person, machine, where it runs; you are marked\nthreads list (task?, unread?)               list; threads read (id) reads one (marks it read)\nsay reply (thread, body)                    reaches the agents that wrote in the thread, the task\'s live agents, and everyone it was sent to\nsay post (body, task: "WEB-12")             a new thread about a task: whoever is live on it\nsay post (body, to: "Albert")               a new thread to one live agent, by the name session who shows\nsay post (body, to: "Albert, Ida")          a group chat: every one of them gets it, and every reply reaches them all\nsay post (body, to: "all")                  everyone live in the project, in one thread (never one thread per agent)\nsay post (body)                             a general thread: for people, and for context\n                                            (subject is optional: without one, the first line of the body)\n```\n\nAgents have names. Yours is told to you at session start and is the same every time this conversation comes back; `session who` shows everyone\'s. A thread to an agent by name reaches it wherever it is, on a task or not, and its answers come back to you. If two live agents share a name, use the session id from `session who`.\n\n**Claude Code only:** when you cannot go on without the answer, `say` `reply` (or `post`) with `wait: 20` returns the reply in the same call, or `session` `wait` with `thread` waits for the next message there (20 minutes at most). This is rare; the other agent may not read your letter for a long time. **On Codex, do not use `wait`:** end your turn, and the reply comes as your next turn.\n\nYour session survives a bad network and a deploy: the server keeps it for two minutes and you reconnect as the same agent; anything said in the gap is handed to you after your next tool call.\n\nPick the scope by who should be interrupted: a question for the agent on a ticket goes in a thread about that ticket; a note for people or for whoever comes next is general. Keep it to what the other side needs; state goes in the plan\'s notes, decisions in the description. One thread per matter: reply in the thread that exists rather than opening a new one to the same agent.\n\n## Etiquette\n\n- Each conversation has its own session and inbox in each project. Identified conversations can share a checkout; separate worktrees are still useful for keeping code edits independent.\n- Do not claim a task that has someone else\'s live session (`session` `who`); write in a thread about it first.\n- Answer questions about your task promptly: the other agent may be blocked on you. Answer them once.\n- Report progress in the plan\'s notes, not in threads. Threads are for asking and deciding, not for status.\n- If you stop working on a task, end the session so nobody waits on you.\n';
 
 // skills/slop-working.md
-var slop_working_default = "---\nname: slop-working\ndescription: The working loop for tasks on the board (claim, do, report, finish) and what to record where. Load at the start of any coding session in a repository linked with slop.\n---\n\n# The loop\n\n1. **What is there:** `board` `list` with `mine`, or plain `list`. If nothing is assigned to you, take the top item of the first \"to do\" column.\n2. **Claim it:** `session` `claim`. It assigns you, moves the task to in progress, makes you reachable, and returns what is unread (see `slop-sessions`). Then `task` `show` and read all of it, plan and notes included.\n3. **Do it.** Long work: follow `slop-planning`. Short work: just do it.\n4. **Report as you go**: the item's note is the present state of that piece of work; the description holds what you decided and why. Write in sentences a teammate can act on.\n5. **Finish:** `task` `link` the PR, put what changed and where at the end of the description (`task` `update`), then `task` `finish`.\n\n# Where things go\n\n| This | Goes here |\n|---|---|\n| The current truth about a piece of the work | the item's note (`plan` `note`) |\n| A decision and its reason | the description (`task` `update`) |\n| A question for the agent on a ticket | `say` `post` with `task` (a thread about that ticket) |\n| A note for people, or for whoever comes next | `say` `post` without `task` (a general thread) |\n| A discovery, a hand-off | the description, or a new task if it is work |\n| A pull request, a design, a log | `task` `link` |\n| Loose working notes nobody needs to act on | the task's notes (`task` `update` with `notes`) |\n| Work you found but will not do now | `task` `create` in backlog |\n\n# Etiquette\n\n- One task in progress at a time per agent. `session` `who` shows who is live; do not take a task with someone else's live session without asking (`say` `post` on that ticket).\n- Never delete a task or someone else's items; archive and remove are for the owner.\n- Severity is the impact if nothing is done: `critical` is data loss or money, `high` is users blocked, `medium` is friction, `low` is polish.\n";
+var slop_working_default = "---\nname: slop-working\ndescription: The working loop for a ticket on the board: going live on it, keeping its column true, and handing it back to the person before it is closed. Load when told to work a ticket, given a ticket key or number, asked to pick up the next thing, or at the start of any coding session in a repository linked with slop.\n---\n\n# Told a ticket? Go live on it first\n\n\"Work LB-59\", \"take a look at ST-12\", \"pick up the next one\": before you read any code, claim it.\n\n`session` `claim` with the key. That one call assigns the ticket to you, moves it to the first in-progress column, and hands you what is unread about it (read that before you start). From then on you are **live on that ticket**: the board shows you working it, `session` `who` lists you on it, and messages about it reach you on their own. See `slop-sessions`.\n\nClaiming is the only thing that makes you live. `slop task start` at a shell moves the column and nothing else, because the CLI is one short-lived process and cannot hold a session; moving the column by hand leaves the board saying someone is on the ticket with nobody there. Through the MCP tools, `session` `claim` is the way in.\n\n- Given a key that does not exist, or an ambiguous one: say so and stop. Do not guess which ticket was meant.\n- Someone else already live on it (`session` `who`): do not claim it. Ask in a thread about that ticket first.\n- Told to work something that is not on the board yet: `task` `create` it, then claim it. Work an agent is doing should be a ticket someone can see.\n\n# The loop\n\n1. **Claim it:** `session` `claim`. Then `task` `show` and read all of it, plan and notes included.\n2. **Do it.** Long work: follow `slop-planning`. Short work: just do it.\n3. **Report as you go**: the item's note is the present state of that piece of work; the description holds what you decided and why. Write in sentences a teammate can act on.\n4. **Keep the column true.** The board is read by people who are not watching you. If you stop for the day or move to something else, `session` `release`. If you are blocked, say what on, in the item's note and in a thread about the ticket, and leave it in progress. Never leave a ticket in progress with no live session and no note saying why.\n5. **Hand it back** (below). Finishing is the person's call, not yours.\n\n# Handing a ticket back\n\nWork being done is not the ticket being done. When the code is ready:\n\n1. `task` `link` the pull request.\n2. Put what changed and where at the end of the description (`task` `update`).\n3. If the board has a column for review, move it there (`board` `columns` lists them; a review column still counts as in progress). Otherwise leave it in progress.\n4. **Ask the person, and stop.** Not in a thread: answer in your turn, to whoever asked you, because they are reading it. One message: what you did, where the PR is, and what is left to decide. Offer the things you could do next rather than choosing one, for example reviewing the PR yourself, addressing review comments, merging it, or deploying.\n\n**Do not call `task` `finish` until they answer.** `finish` moves the ticket to the first done column and releases your session, which is the claim that the work is accepted, and only a person can make that claim. Told to finish, finish. Told nothing, leave the ticket where it is: sitting in review is honest, marked done because an agent ran out of things to do is not.\n\nThe one exception is work with nothing to accept: a chore you were told to close, a one-line fix already on the main branch with no pull request. Finish that and say you did.\n\n# Where things go\n\n| This | Goes here |\n|---|---|\n| The current truth about a piece of the work | the item's note (`plan` `note`) |\n| A decision and its reason | the description (`task` `update`) |\n| A question for the person driving you | your own reply to them, in your turn |\n| A question for the agent on a ticket | `say` `post` with `task` (a thread about that ticket) |\n| A note for people, or for whoever comes next | `say` `post` without `task` (a general thread) |\n| A discovery, a hand-off | the description, or a new task if it is work |\n| A pull request, a design, a log | `task` `link` |\n| Loose working notes nobody needs to act on | the task's notes (`task` `update` with `notes`) |\n| Work you found but will not do now | `task` `create` in backlog |\n\n# Etiquette\n\n- One task in progress at a time per agent. `session` `who` shows who is live; do not take a task with someone else's live session without asking (`say` `post` on that ticket).\n- Never delete a task or someone else's items; archive and remove are for the owner.\n- Severity is the impact if nothing is done: `critical` is data loss or money, `high` is users blocked, `medium` is friction, `low` is polish.\n";
 
 // src/platform/skills.ts
 var SKILLS = { "slop-cli": slop_cli_default, "slop-planning": slop_planning_default, "slop-sessions": slop_sessions_default, "slop-working": slop_working_default };
@@ -27859,8 +27859,8 @@ This repository is linked to a Slopware Tasks board. Use the \`slop\` CLI to kee
 
 - When you find work that should be tracked (a bug, a follow-up, a TODO you are not doing now), create a task:
   \`slop task create "Short imperative title" -d "What, where, why" -s <low|medium|high|critical>\`
-- Before starting tracked work: \`slop task list\`, then \`slop task start <KEY>\`.
-- When it is finished and verified: \`slop task done <KEY>\`.
+- Told to work a ticket (a key like \`WEB-12\`, or "the next one"): claim it before you read any code. An agent claims with the \`session\` \`claim\` tool, which assigns the ticket, moves it to the first in-progress column and goes live on it so messages about it reach you. \`slop task start <KEY>\` at a shell only moves the column: the CLI is one short-lived process and cannot hold a session, so it leaves the board saying somebody is on the ticket with nobody there. Method: \`slop skill slop-working\`.
+- When the code is ready, hand the ticket back instead of closing it: \`slop task link <KEY> <pr-url>\`, put what changed in the description, and ask the person what they want next (the PR reviewed, review comments addressed, merged, deployed). \`slop task done <KEY>\` (\`task\` \`finish\`) is the statement that the work is accepted, and only they can make it. Told to finish, finish.
 - Descriptions are Markdown and are shown in full on the board. Write real ones: context, file paths, what done means. Pipe long ones in with \`-d -\`.
 - Agents use the six slop MCP tools for everything on the board (\`slop mcp install\` once per machine): \`board\`, \`task\`, \`plan\`, \`session\`, \`threads\`, \`say\`, each with an \`action\`. You have a name (session start tells you; \`session who\` lists everyone's); \`say post\` with \`to\` reaches one agent by name. If a wake says mail is waiting, use \`session check\` with the project it names. Each conversation and project has its own inbox. Messages are kept whole; use \`session check\` for any remaining messages. A crash just after output can repeat a message, so do not repeat an action you already completed. Messages for you reach you on their own: idle, as a turn of yours; while you work, as your next turn (Codex) or with your next tool result (Claude Code). Messages are letters, not chat: the other agent reads yours when it gets to it, its reply may predate your latest, so write once and completely, answer a pile of messages with one reply, and reply only when it changes something (never to acknowledge). Do not wait for replies; end your turn. The \`slop\` command is for people and scripts. Talk through threads: \`slop task ask <KEY> "\u2026"\` reaches whoever is live on that task, \`slop thread reply <id> "\u2026"\` answers, \`slop threads\` lists them; general threads are for people and for context. Method: \`slop skill slop-sessions\`.
 - Work that outlasts one session gets a plan on its task: \`slop task plan <KEY> -\` (one item per line), then \`slop task item note|done <KEY> <n>\` as you go; \`slop task items <KEY>\` shows where you are. \`slop skill slop-planning\` is the method; \`slop skills install\` puts the skills in this repository.
@@ -29385,7 +29385,7 @@ ${formatWaitOutcome(await waitForNextMessage(output2, result.thread.id, args.wai
     },
     {
       name: "claim_task",
-      description: "Take a task: assign it to you, move it to in progress, go live on it for as long as this server runs, and get what is unread about it. From now on a message in a thread about the task reaches you on its own, right after your next tool call; you do not have to wait or poll.",
+      description: "Take a task: assign it to you, move it to in progress, go live on it for as long as this server runs, and get what is unread about it. Do this first when you are told to work a ticket, before reading any code; nothing else makes you live on it. From now on a message in a thread about the task reaches you on its own, right after your next tool call; you do not have to wait or poll.",
       inputSchema: buildToolSchema({ task: buildStringSchema("Task key"), project: PROJECT }, ["task"]),
       run: async (args) => {
         const target = await fetchProject(api, (await resolveProjectWithPresence(args)).id);
@@ -29602,7 +29602,7 @@ ${task.notes}` : ""].filter(Boolean).join("\n");
     },
     {
       name: "finish_task",
-      description: "Move a task to the first done column.",
+      description: "Move a task to the first done column and release your session. Done is the person's call: link the pull request, say what changed, and ask them before you call this.",
       inputSchema: buildToolSchema({ task: buildStringSchema("Task key"), project: PROJECT }, ["task"]),
       run: async (args) => {
         const target = await fetchProject(api, (await resolveProjectWithPresence(args)).id);
@@ -29735,7 +29735,7 @@ async function trustCodexHooks(codexHome) {
   const sendNotification = (method, params) => server.stdin.write(`${JSON.stringify({ jsonrpc: "2.0", method, params })}
 `);
   try {
-    await callCodexMethod("initialize", { clientInfo: { name: "slop", version: "0.4.11" }, capabilities: { experimentalApi: true } });
+    await callCodexMethod("initialize", { clientInfo: { name: "slop", version: "0.4.12" }, capabilities: { experimentalApi: true } });
     sendNotification("initialized", {});
     const listed = await callCodexMethod("hooks/list", { cwds: [process.cwd()] });
     const ours = listed.data.flatMap((entry) => entry.hooks).filter((hook) => hook.command?.startsWith("slop hook "));
@@ -29872,7 +29872,7 @@ function buildTools() {
     ),
     buildGroupedTool(
       "task",
-      "One task. show; create; update (only given fields change); move; link; archive/restore; history; finish (first done column, releases your session).",
+      "One task. show; create; update (only given fields change); move; link; archive/restore; history; finish (first done column, releases your session: link the pull request and ask the person before you finish, see the slop-working skill).",
       { show: "show_task", create: "create_task", update: "update_task", move: "move_task", link: "link_task", archive: "archive_task", restore: "archive_task", history: "task_history", finish: "finish_task" },
       { task: buildStringSchema("Key, e.g. WEB-12 (all but create)"), title: buildStringSchema(""), description: buildStringSchema("Markdown"), notes: buildStringSchema("scratchpad, Markdown"), severity: buildStringSchema("low|medium|high|critical"), column: buildStringSchema("column key or label"), assignee: buildStringSchema("email, name, me, or none"), url: buildStringSchema("link: the URL"), limit: buildIntegerSchema("history: newest N (default 50)"), before: buildStringSchema("history: page back from this time") }
     ),
@@ -29884,7 +29884,7 @@ function buildTools() {
     ),
     buildGroupedTool(
       "session",
-      "Being live. claim: take a task, go live on it, get what is unread (messages then reach you on their own). release; finish is on task. who: live agents by name (you included). check: unread now. wait (Claude Code only, rarely): block for the next message, or the next one in a thread. Never wait on Codex.",
+      "Being live. claim: told to work a ticket, do this first, before reading any code: it assigns the ticket to you, moves it to in progress, goes live on it and returns what is unread (messages then reach you on their own). Nothing else makes you live. release; finish is on task. who: live agents by name (you included). check: unread now. wait (Claude Code only, rarely): block for the next message, or the next one in a thread. Never wait on Codex.",
       { claim: "claim_task", release: "release_task", who: "sessions", check: "check_messages", wait: "wait_for_message" },
       { task: buildStringSchema("Task key"), thread: buildStringSchema("wait: only a message in this thread"), minutes: buildIntegerSchema("wait: give up after (default 300; 20 with thread)") }
     ),
@@ -30017,13 +30017,13 @@ ${written.map((path2) => `  ${path2}`).join("\n")}`);
 }
 
 // src/index.ts
-var program2 = new Command().name("slop").description("Slopware Tasks from the terminal. Everything a person can do on the board, an agent can do here.").version("0.4.11").option("--json", "machine-readable output: JSON on stdout, errors as JSON on stderr").hook("preAction", (_, action) => updateJsonMode(Boolean(action.optsWithGlobals().json))).showHelpAfterError("(run with --help for usage)");
+var program2 = new Command().name("slop").description("Slopware Tasks from the terminal. Everything a person can do on the board, an agent can do here.").version("0.4.12").option("--json", "machine-readable output: JSON on stdout, errors as JSON on stderr").hook("preAction", (_, action) => updateJsonMode(Boolean(action.optsWithGlobals().json))).showHelpAfterError("(run with --help for usage)");
 registerAuthCommands(program2);
 registerProjectCommands(program2);
 var taskCommand = registerTaskCommands(program2);
 registerSessionCommands(program2);
 registerThreadCommands(program2, taskCommand);
-registerMcpCommands(program2, "0.4.11");
+registerMcpCommands(program2, "0.4.12");
 registerGuideCommand(program2);
 registerSkillCommands(program2);
 program2.parseAsync().catch(exitWithError);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "slopwaresystems",
-  "version": "0.4.11",
+  "version": "0.4.12",
   "private": false,
   "description": "slop: the Slopware Tasks board from the terminal, for people and coding agents.",
   "type": "module",