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.

Several repos at once

Name one to start in: repo:my-api. Later messages in the thread do not need to repeat it — the session stays where it was working.
Name someone else’s: repo:other-org/their-lib, for a fork or a dependency outside your own account. A name with no owner means your own.
Let the session find the rest: ask it to change something across your services and it can search, then open each repo it needs. Every repo gets its own working tree on the same branch, so one task becomes one pull request per repo.
Repos opened this way are cloned without file history, which is what keeps a dozen of them affordable on your volume. When a turn changes more than one, it says what it left in each.

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.

Installing things

A session runs as root and can apt-get install anything — but the machine’s root filesystem is a verified image with an overlay in RAM, so an install lasts until the next cold boot and occupies memory until then. Only /work, the session’s volume, persists. Two ways to keep a tool:

/work/setup.sh — a bash script the machine re-runs at every boot, as root, before the session starts. Ask the session to “add ffmpeg to /work/setup.sh so it survives a rebuild” and it writes the line and runs it. Ninety seconds, then the script is stopped; if it fails or is stopped, the machine boots without it and the thread gets one line saying so, with the log at /work/.sparkyard/setup.log. Start with apt-get update — the image ships no package lists — and downloads are cached on the volume, so a re-run is fast.
/work/opt/bin — on PATH for the session and for workbench shells. Drop a binary there and it stays.

If a later image ships a tool your script also installs, you will have it twice; harmless for a package, less so for something on PATH at two versions — trim the script when that happens.

Seconds belong in the script; minutes belong in an image. A recipe that installs a JDK and a Gradle distribution at every boot is the wrong tool for the job, and organisation images are the plan for that.

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.
//agent — which agent answers this thread.
- //agent on its own shows what it is running on, and buttons for the others you have.
- //agent chatgpt switches it.
A thread picks its agent on the first turn and keeps it, so changing a default halfway through does not change a conversation already under way. Switching starts a fresh session — the old one belongs to the old agent — and hands the new agent the last few turns so it knows what happened.

Two things can refuse a switch, and both say so: an agent nobody here has connected, and an agent that cannot enforce a rule this workspace has set (see Workspace settings).

Strongest wins: this thread’s //agent, then your /sparkyard agent, then the desk’s, then the workspace’s.
//compare <task> — ask two agents the same thing. Each gets its own branch, so neither can overwrite the other. You end up with two answers and two branches; nothing is merged and neither is preferred. It costs two turns instead of one, which is why you have to ask for it.
//exchange <task> — let two agents take turns on one piece of work. They share a working tree and every turn posts as it happens, so you can watch and interrupt. //stop ends it after the turn in flight.

It stops itself, and this is the part worth knowing: at a turn cap, or as soon as two turns in a row change no file and ask no question. Two agents agreeing politely with each other looks exactly like progress, so it does not wait to find out.
// — 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.