tokenmaxxing 1.6.0 → 1.8.0

package/src/serve-plugin/skills/ask-the-user/SKILL.md

@@ -1,41 +0,0 @@
----
-name: ask-the-user
-description: Use when you need the requesting user's decision, approval, or missing information to proceed, when you are blocked, or when long-running work they asked about is done, in a Slack-relayed tokenmaxxing serve session. Explains how to ask so the user actually gets notified.
----
-
-# Asking the user from a serve session
-
-This session is relayed into a Slack thread. There is no interactive prompt:
-the AskUserQuestion tool is unavailable, and only what you write in your reply
-reaches anyone. A plain reply does not notify the user; a mention does.
-
-## How to ask
-
-1. Write the question into your reply and tag the requester by including their
-   mention token literally in the text: `<@U...>`, using the requester id from
-   the "Slack relay context" note in this turn. Slack renders it as @name and
-   notifies them.
-2. State the fork in one short paragraph: what you were doing, the options,
-   which one you recommend and why. One question at a time.
-3. Call the in-process `need_attention` tool (mcp__tokenmaxxing__need_attention)
-   in this same turn. The daemon then marks the thread as waiting on the user
-   (a question-mark reaction on their message), tags them once more if they
-   stay quiet, and relays a reaction from them back to you as their answer -
-   so phrase yes/no forks so a thumbs up picks your recommended option.
-4. End the turn after asking. Do not pick a real fork's option unilaterally,
-   do not busy-wait, and do not keep working past the fork: the user's thread
-   reply arrives as your next turn and continues this same session.
-
-## When to ask (and tag)
-
-- A real decision fork: destructive or irreversible actions, spending money or
-  metering account quota, a policy or design choice the user would want to
-  make, missing credentials or facts only they have.
-- You are blocked and cannot proceed.
-- You finished long-running work they asked to be told about.
-
-## When not to tag
-
-- Routine replies and progress: the user reads the thread, and a mention that
-  is not actionable trains them to ignore the real ones.
-- Never mention @here, @channel, or @everyone.

package/src/serve-plugin/skills/serve-session/SKILL.md

@@ -1,50 +0,0 @@
----
-name: serve-session
-description: How a tokenmaxxing serve session runs - the shared repo checkout, session resume across turns, when to cut your own git worktree, and how to hand finished work back. Use when deciding where to work, commit, push, or open a PR, or before any operation that moves, deletes, or switches the working directory.
----
-
-# How a serve session runs
-
-tokenmaxxing serve bridges a Slack thread to this Claude Code session. Every
-thread message becomes one turn; your streamed output posts back into the
-thread as Slack messages.
-
-## Working directory
-
-- This session runs directly IN the linked repo checkout, and it is SHARED:
-  the repo's owner and other Slack threads work in the same checkout at the
-  same time. Read-only work (answering questions, reviewing code, reading
-  logs or history) happens here freely and in parallel. Uncommitted changes
-  you do not recognize belong to someone else - never reset, restore, or
-  stash over them; stage only your own hunks; on a collision, stop and ask
-  (see the ask-the-user skill).
-- MUTATING work cuts its own worktree FIRST (`git worktree add`). If the
-  task will edit, create, move, or delete files - or run anything that
-  writes into the tree - do it from a fresh worktree by default: other
-  threads and the owner share this checkout, and two agents editing one tree
-  corrupt each other silently. Say in the thread that you cut one, do the
-  task's whole life there (follow-ups included), and remove it once the work
-  is merged. Skip the worktree only when the user explicitly asked for a
-  change in this checkout itself.
-- Your session's cwd stays the SHARED CHECKOUT on every turn regardless (each
-  turn is a fresh process at the recorded cwd, and resume is keyed to it, so
-  the daemon can never move it). Reach your worktree by absolute path - or
-  `cd` inside each command - every turn; never rely on a previous turn's
-  `cd`, and re-read the thread for the worktree path when resuming a task.
-- Session resume is keyed to the session's cwd. Never delete or move it, and
-  never switch the checkout's branch without asking: the thread (and other
-  people's work) would break.
-
-## Turns
-
-- Each turn is a fresh claude process resumed by session id: the conversation
-  transcript carries over, but background processes and unsaved in-memory
-  state do not. Persist anything a later turn needs to files.
-- Nothing can answer an interactive dialog mid-turn. To get the user's input,
-  follow the ask-the-user skill.
-
-## Handing work back
-
-- Follow the repo's own shipping conventions (its AGENTS.md or CLAUDE.md);
-  when in doubt, branch and open a PR rather than committing to the default
-  branch. Push or merge only when the user asks.