Slash Command

/new-thread

From thread

Branch the conversation into a side thread for a side question, without disrupting the main work

Invocation

How this command is triggered — by the user, by Claude, or both

Slash command

/thread:new-thread <your side question>

Model invocable

No pre-commands

Context Preview

The summary Claude sees in its command listing — used to decide when to auto-load this command

The user is opening a SIDE THREAD — a multi-turn side discussion that should not derail or pollute the main conversation. Treat the side discussion as visually fenced and contextually isolated, in the spirit of a Slack thread on a parent message.

Their side question (everything after `/thread:new-thread`): "$ARGUMENTS"

## Protocol

1. **Detect prior thread state.** Read your recent assistant turns. If a `┌─── SIDE THREAD` opening fence appears without a matching `└─── back to main` closing fence, the conversation is already inside a thread. Refuse with:

   *"You're already in a side thre...

Command Content

37 lines · ~564 tokens

Stats

Stars0

MaintenanceGood

Last CommitMay 28, 2026

Actions

View Source View Plugin View on GitHub View README

Stats

Actions

Protocol

Detect prior thread state. Read your recent assistant turns. If a ┌─── SIDE THREAD opening fence appears without a matching └─── back to main closing fence, the conversation is already inside a thread. Refuse with:

"You're already in a side thread. Close this one with /thread:end-thread first."

Do not open a nested thread.
Otherwise, open the thread. Emit an opening fence on its own line:
```
┌─── SIDE THREAD · HH:MM ───────────────────
```
where HH:MM is the current wall-clock time (24-hour). Then continue every line of your reply with the prefix │ (vertical bar + space). Answer the side question inside the fence.
Multi-turn behavior. Until the user runs /thread:end-thread, stay in thread mode:
- Every line of every reply begins with │ .
- Each new user message is a thread turn — answer inside the fence.
- Do not perform main-conversation work (file edits, code-task work, tool calls related to the main task) inside the fence, unless the user explicitly asks for it inside the thread.
Closing. Closing is handled by the /thread:end-thread command — see commands/end-thread.md in this plugin. Do not close the fence on your own initiative.

Why

A side question shouldn't derail what you're working on, but answering it inline turns the scrollback into a tangle. The fence makes the side discussion visually obvious; the multi-turn rule lets you actually have the side conversation rather than getting one terse answer; the no-nest rule keeps the structure flat (mirroring Slack, where threads don't nest either).

There is no snapshot file or transcript. Your own conversation memory holds the main thread; the fence is purely a visual and contextual boundary.