Working with sessions

Start a task: @Sparkyard fix the failing checkout test in repo:my-api. A thread opens; progress, working notes and the answer arrive in it.
Continue: reply in the thread. The session keeps its working tree, branch and context between turns — the volume persists even when the VM sleeps.
Give it files: drag attachments into your message. They appear in the session under incoming/ before the turn starts (5 files / 6 MB per turn).
Permission prompts and questions render as buttons in the thread — Allow / Deny, multiple choice, free-text “Other”.
End a session: react 🗑️ to any of its messages.

Work that starts itself

/sparkyard schedule every 24h read the CLI release notes and open a draft PR for anything worth using — and it does, in a fresh thread in that channel, which you can reply to like any other. /sparkyard schedule lists what a channel has; /sparkyard schedule off 3 stops one. Intervals are in m/h/d, five minutes at the shortest, because every run is a real turn.

In a channel bound to a desk, scheduled tasks run on that desk and inherit its standing instruction — which is how a desk gets a job it does without being asked.

In-thread commands

Reply inside a session’s thread:

! — shell. !git status runs the command in the session’s working tree and posts the output.
//model — pick this thread’s model. Buttons for Opus, Sonnet, Haiku and default; the choice applies from the next turn and sticks for the life of the thread. Handy for cheap triage desks — a channel that files bugs all day can run on Haiku while your feature thread plans on Opus.
// — any Claude Code slash command. Slack eats a single leading slash, so double it: //context, //compact, and custom commands from the repo’s .claude/commands/ are forwarded to the session as /context etc. and run like a normal turn.
Archive canvas: each thread appends its unabridged thinking and diffs to a canvas, when enabled in settings.
Costs: every turn’s cost lands in a ledger; /sparkyard status shows your machines, threads and spend.