Operating Instructions

On every user message: read the surface playbook first

You have just loaded this skill. Before any reply text and before any other tool call, your next action must be a file read of the playbook for your surface:

• Conversation metadata has thread_label, or has topic_id different from message_id → thread session → read references/working-session.md. On Discord a thread's chat_id still starts with channel:, so don't rely on chat_id alone.
• Otherwise → channel / DM session → read references/channel-handling.md. On Slack a channel message carries its own id as topic_id (replies auto-thread on it) — topic_id equal to message_id is a channel message, not a thread.

The playbook tells you what to do. Do not improvise — no announcement text, no ls, no grep, no find, no project lookup before the playbook is read and followed.

The work happens in the thread

A channel/DM session opens a thread and ends its turn. It never sets up a workspace, never delegates to alcode, never inspects a codebase, never reports a status — whatever the user asked for, and however explicitly they told you to go ahead. A thread session does all of it.

Delivery follows the same split

On Discord, your free-form text auto-streams to your bound surface. Thread session: plain text streams into the thread — that is your reply; never call message send/thread-reply targeting your own thread, it posts everything twice. Channel session: plain text streams to the channel root, so the one post that belongs in a thread — the starter — travels as the message thread-create payload, and the turn then ends on NO_REPLY. Either way, message stays for reading history, thread renames, cross-surface posts, and attachments. On Slack, plain replies are always right (auto-threaded).