wsp

Imported from Zingzy/wsp (skills/wsp/SKILL.md). Install upstream with npx skills add Zingzy/wsp --skill wsp. Copyright stays with the author.

wsp

wsp runs cloud machines called workspaces, forked in seconds from the image the person sealed with wsp init, each with coding agents working inside it as threads. A project is a repo on one computer, recorded with wsp add, and a workspace is a copy of that computer with that project inside, made for one piece of work and named by it. On the computer the app runs on a workspace is a copy of the project's folder beside it: it forks nothing, costs nothing and runs threads on the agents already on its PATH, which is where a quick subtask or a second harness goes when nothing needs a machine. The host on the person's computer (the desktop app, or the first command line that needs one, which starts it) owns the machines and the keys; the wsp command line and the wsp MCP server are thin clients of that same host, so whatever you do here shows in the person's sidebar and they can read and answer any thread. Start with wsp workspaces to see every workspace and wsp threads to see the threads inside them. Open a thread with run, giving the workspace, the task and the agent to run; it returns the reply as soon as the agent gives it, and the thread reads running until the agent process exits. Continue a thread with send, which is also how one thread talks to another, by that thread's id off threads: a send is never refused for meeting a turn, it joins a running turn where the agent takes a message mid-turn and otherwise runs as that thread's next turn, and the answer comes back as its own message when the other thread's start named you. A thread reaches every thread of its own tree, the lead that started it, the threads beside it under that lead and the threads it started, on whatever workspace each runs, and nothing else: the person's own thread and another lead's tree on the same workspace are left out of threads, a send into either reads as no such thread, and work that has to cross to them goes through the person. Stopping a thread stops every thread under it, so a child that stops its lead stops its siblings and itself with it. Both take detach, which answers with the thread id the moment the turn is started and leaves the reply to the thread's finished line. Which road you take for that line is decided by whether you are a wsp thread yourself, which the launch environment says: a thread starts every child with --notify me and ends its turn, and the child's finished line, carrying its whole report, wakes it as a message; a caller that is not a thread takes the reply of one turn as run or send returns it, and for more than one turn at a time starts one coordinator thread on the local workspace with the whole job and hands off, telling the person where to read it. stop ends a thread's running turn; run a command on a machine with exec; snapshot a workspace with a project loaded as a project image and new from it so the next machine starts with the project in place; export brings a folder and its agent sessions home; forget drops a workspace whose machine the provider no longer has, and delete deletes a workspace's machine and drops it here. pause naps a machine and wake wakes it; run, send and exec wake a paused workspace themselves before running, so a paused one needs no wake first. Setting someone up from nothing is its own sequence, and the next section is that sequence: a health check, then recipe_scan, which writes nothing and gives every row a recommended value with one line of why, so you apply those and put only the rows whose reason says worth a question, then recipe with their answers, then wsp init --recipe <path> --non-interactive --json from a shell, which builds their image and prints one JSON line per sign-in for you to hand to the person, since the sign-ins finish in their browser.

Setting a person up from nothing

Asked to set a person up, read this section before running a single verb: a verb's refusal is a branch in this list, not an answer to hand back. The road is a health check, then wsp recipe scan, which prints every option and writes nothing, then two questions to them, the heavy rows with their sizes and the sign-ins with their default choice, then wsp recipe --tick used with their answers, which writes the recipe, then wsp init --recipe ~/.wsp/recipe.json --non-interactive --json, which you run detached from a shell: it builds their image and prints one JSON line per sign-in, the page and the code the person finishes in their own browser, and waits for them, then the first workspace and wsp run <name> for the first thread. Two things are theirs and never yours: the sign-ins, which no tool can finish for them, and the keys, which live in their .env and are never typed into your terminal or read back to them. Starting the host is neither: any command that needs one starts it, and it reads those keys off the file itself, so nothing about them passes through you. Every step below ends in an Expect: line; run the command, read that line, and stop at the first one that does not match rather than carrying on. Read where they already are before running anything, and skip the steps that state has passed.

1. The health check comes before any verb: wsp --version. With no wsp on the path and a shell of your own, npm i -g @zingzy/wsp puts the wsp command there; prefer that over npx @zingzy/wsp, whose cache write fails under a sandboxed agent and leaves every command after it running with the sandbox off. Then wsp threads --json. A host is what answers it, and when none serves that state file this command starts one and waits for it, so there is nothing to start by hand. (wsp doctor is not this check: it forks a live machine to prove the whole reach path, it bills while it runs, and it does not speak JSON.)

   Expect: wsp <version>, then one JSON line on stdout, {"threads":[]} when nothing is running yet: go to step 6. A starting the host for <path>; its log is <path>, and wsp down stops it line on stderr before it means none was serving and this command started one, which is the ordinary road and not a failure to report. no host answered for <path> within 20.0s, with the log's last lines under it, means the host it started could not serve: read that log. Solari API key: no terminal to ask on; set SOLARI_API_KEY in the environment, ./.env, or ~/.wsp/.env. in it is no key at all: go to step 2. A Workspace <name> (ws_...) is a copy of <folder> on this computer; its threads run here, under your own sign-ins. line in it means the state held neither an image nor a workspace, so the host recorded this computer and served that: go to step 3 to seal an image, or to step 6 when this computer is enough to start on. A command not found with no shell to install from is the one thing to say and stop on, because nothing below can be run for them.

2. The keys are the person's. Ask them to write SOLARI_API_KEY=<their key from console.getsolari.com> into ~/.wsp/.env, one line, and ANTHROPIC_API_KEY=<key> beside it when they pay Anthropic by the token; on a Claude subscription they skip that one and sign in on the machine during init instead. Do not ask them to paste a key into this conversation, do not print that file, and do not commit it. Then take the host that started without a key down with wsp down and run step 1 again, so the new host reads the file.

   Expect: the host's log no longer names the Solari key, and wsp threads --json answers with one JSON line.

3. Read everything before writing anything: wsp recipe scan prints every option and writes no file. Five tables: the agents, with what each one's history on this computer says; the tools, each with why it is there (used 412 times in 37 sessions, installed here, never used, catalog default), its download size and, in the last column, what to do about it; what else a package manager on this computer has that the image could take, by manager, with the line that installs each and its size; the commands their agents ran that the catalog does not carry, with counts; and the sign-ins, each with the choice that would be taken by default. --json gives all of it as one object with a recommended value and reason on every row, which is the form to read when you are deciding rather than showing. --project <folder> weighs the histories by a folder, so a setup for one project counts that project's sessions first. Read the why and the size on every row instead of taking the defaults as given: they come from what their agents actually ran, not from what is installed, and an agent with no thread adapter stays off, which is right, since an image carries the agents that can run threads unless the person asks for another.

   Expect: the five tables on stdout, the agents and tools tables each ending in an On: line with the count and the total size, then Nothing was written. as the last line; wsp recipe scan --json answers with one object holding the same rows.

4. Put the two decisions to the person, each as one message, then write the recipe with their answers. First the heavy rows, over 300 MB, as one multiple-choice question with the size beside each and what the answer does to the total. Then the sign-ins, naming the default choice on each row and what the choices mean: copy it from this computer, sign in during the build, sign in when you first need it, hand it an API key, mint a token here that every turn gets, or skip it. Then write: wsp recipe --tick used, plus --set <id>=on|off for every row they flipped and for anything from the scan's own-computer table they want on the image, --add <id>="<install line>" only for a tool neither the catalog nor this computer has, --signin <id>=copy|machine|later|key|skip|token for every sign-in they chose, and --project <folder> when the setup is for one project, so that project's history weighs first. All of them repeat, all of them go in one call, and the file is never edited by hand.

   Three heavy ones are ticked because they are installed on your computer, and your agents never used them:
   Java 21 (620 MB), Gradle (410 MB), Android SDK (1.2 GB). Which do you want on the machines?
   (a) none of them, 3.4 GB down to 1.2 GB   (b) Java only   (c) all three, and the build takes longer
   

   Expect: the tables again with every flip in them and the total moved by their sizes, then Recipe written to <path>. opening the last line, ~/.wsp/recipe.json when the state file is the default one and a path beside their state file when it is not. That path is the one step 5 runs with.

5. Build their image. Run init yourself, detached, with the recipe step 4 wrote:

   nohup wsp init --recipe ~/.wsp/recipe.json --non-interactive --json > /tmp/wsp-init.jsonl 2> /tmp/wsp-init.log &
   

   It boots one builder machine, installs what is ticked, and at each sign-in the recipe answered machine it prints one JSON object on stdout and waits: {"event":"sign-in","tool":"gh","label":"GitHub CLI login","browserUrl":"https://github.com/login/device","code":"8F4A-C21B","nextCommand":"open 'https://github.com/login/device'","waitSeconds":960}. Hand that line to the person as it comes: the page to open on their computer, the code when there is one, and the command that opens the page. No thread and no tool can sign in for them; the run asks the tool's own status on the machine and moves on when it says signed in, or when waitSeconds pass. Read /tmp/wsp-init.jsonl as it grows rather than waiting on the process, which keeps serving the app after the seal. Say what it costs before starting it: about $0.11 an hour while the builder runs, and it holds one of the account's two machine slots. When the person would rather drive the wizard themselves, wsp init --recipe ~/.wsp/recipe.json in their own terminal draws six screens, Agents, Tools, Also on this computer, Sign-ins, wsp for your agents on this computer, and Build, of which the recipe has answered the first three, so their run opens on Sign-ins and ends on Build. A host already serving that state file stops none of this: the screens are the same and the build runs in that host, which records the image in the state it serves, so a box whose host is a service needs nothing taken down. That road refuses --json, since the build's objects then ride the host's own setup, which wsp setup --json reads; run init without --json beside a serving host, or take it down with wsp down first.

   Expect: one {"event":"sign-in-result","tool":"gh","label":"GitHub CLI login","state":"signed-in"} line per hand-off ("state":"not-signed-in" with a note saying why when the person did not finish in time; the run seals either way), then Image v<n> sealed. in the log, which is the seal, Workspace first (<id>) forked from image v<n>. on the first seal, and Open http://127.0.0.1:4400/. A JSON line from wsp threads is not that proof: init serves a host for the whole wizard, before the sign-ins and the seal, so step 6 is what tells a sealed image from an init still running.

   When the person set up from the app instead (the Set up cloud machines row in its sidebar), the same run is a job on their host: wsp setup --json answers with its phase, its rows and each sign-in with the page waiting for them, so hand an open one over as you would the line above, and never start a second init beside it.

6. First workspace. The first seal forks one, named first, so on a fresh image wsp wake first answers with its state (over MCP, workspaces lists it) and it is the one to use; wsp new dev makes another.

   Expect: created dev <id>, printed when the machine is booted and reachable, or with --json the creating stages and then the workspace, one JSON line each. wsp new: no image yet; run wsp init instead means the host is serving without a sealed image, because an init is still running or ended without sealing: wait for it, or go back to step 5. A refusal that names the account's machine cap means two are already up; the builder stays up ten minutes after a seal and counts as one, so right after a seal that is first and the builder, and the person chooses which workspace to pause.

7. Record the project: wsp add <url> --on <computer> for a repo the computer clones, wsp add <owner/repo> --on <computer> for one its signed-in gh or glab clones, or wsp add <folder> for a folder on this computer, which every workspace of it is a copy of. wsp add <folder> --on <computer> is the third road: that computer clones the folder's own remote and the folder seeds what git ignores on top, so the line prints a menu of those paths with their sizes and sends nothing until --yes; the person picks with --keep <path>, --cut <path>, --no-memory and --no-commits, and --remember keeps their ticks for the next add of that folder. wsp new "<what you are working on>" then makes the workspace with the project inside. Take wsp snapshot <workspace> once it stands, so the next workspace of that project starts from a project image with the checkout in place and no second clone.

   Expect: wsp exec first -- ls <folder> lists the repo on the machine with the command's own exit code, 0, and wsp snapshot first prints a project image <id> line naming the project.

8. First thread: wsp run first --cwd <the project folder on the machine, absolute> --notify me "<the task>".

   Expect: thread <id> as the first line on stdout, the reply on stdout when it is complete, and the same thread in the person's sidebar for them to answer. --notify me puts each later turn's reply in front of them, so nobody polls.

Last, say what to run next inside their own agent, which is where the work happens from here. wsp mcp install --agent <id> puts the tools and this skill into that agent (repeatable, and --json for a machine to read; the agents the catalog knows a config for are listed under the verbs below). The tools show up only after that agent restarts, and the wsp command line does the same job until then, so nothing waits on the restart. In Claude Code the skill is then /wsp; in any agent the line to paste is Use the wsp skill and open a thread on first that <the first task>.

Expect: that agent lists the wsp tools once it has restarted, run answers with a thread id, and that thread shows in the person's sidebar.

Verbs and tools

The command line and the MCP server call the same functions. Every verb takes --json (one JSON object per line, frames first, the last line the result; see the contract below) and --state <path> (the state file the host serves; default ~/.wsp/state.json, or ./.wsp/state.json in a checkout of wsp itself). A workspace is named by its name, or by its id when two share a name. A thread is named by its id or by a prefix that picks exactly one. Each tool's inputs are in the parentheses after its name; a flag on the command line is the input of the same name on the tool, --add-check being add_check, and a repeatable flag is an array.

The app's own roads

These stand behind the app's own screens rather than a page of the command line: they are still parsed, still served as tools, and wsp <verb> --help still answers for each.

The command line alone has wsp up, wsp down, wsp status, wsp init, wsp doctor, wsp mcp, wsp add, wsp remove, wsp join, wsp leave, the seven lines under the word host, wsp login, wsp logout, wsp hosts, wsp image export <file> and the three sign-in lines, since each starts, stops, installs or hands out access to something on the person's computer, the sign-ins run in a terminal a person types into, and wsp image export writes the person's own sign-ins into one file: any command that needs the host starts one when none serves that state file, on free ports, saying so in one line on stderr with the log to read and the wsp down that stops it, so wsp up is only for a host somebody wants to watch or to serve beyond this computer. wsp up [--port <n>] [--ws-port <n>] [--listen <addr>] [--state <path>] serves the host until it is stopped, so the terminal it runs in has to stay open; wsp up --service hands that same line to the computer's own service manager instead, a launchd agent on a Mac and a systemd user unit on Linux, which serves now and again at every login, and wsp down stops it and takes it away, as it stops a host a command started. A service starts without the shell that installed it, so the Solari key has to be in ~/.wsp/.env and not exported in that shell, and wsp up --service refuses with that line when it is only in the shell. wsp status prints whether a host is serving this state file, its ports, its token file and what keeps it there, with a non-zero exit code when none does; wsp status --host <alias> reads that host instead, where it answers and whether it did, since what keeps it up is read on the computer it runs on. On a computer joined to somebody's wsp there is no host and never will be, so wsp status there reads the agent that join installed instead: which wsp the computer belongs to, whether that agent is answering and on which port, what the computer is doing right now (cpu, memory, disk), one row per workspace it holds under those rows with the name and id that workspace has on the host, what it was given, what it holds of that now, its uptime, its process count and the address it answers on, and the ten processes spending the most of the computer, exiting non-zero when nothing answers; wsp status --watch draws those same rows again every second where they stand until Ctrl-C, which needs a terminal. It is the one line that leaves this computer only when a host is named on it or in WSP_HOST: the default alias and the host a turn's launch carries move every verb and not this one, since a bare wsp status asks whether the host here is serving and an alias answering for a box would hide that. wsp up --listen <addr> binds an address other than this computer's own, which is how a host on a box someone owns is reached from their laptop: the page is then served with no token in it and every client redeems a one time code for a token of its own. wsp up --provider <name> says which machine provider that host forks on, and --advertise <url> the address a machine reaches the host back at, which the host works out for itself when it binds an address of its own. wsp up --service carries every one of these into the unit it installs, so the service serves the line that was typed and not a shorter one. wsp add is how a computer the person owns becomes a place in their wsp: with no argument it prints the wsp join line and a code to type on that computer, which is spent by the first join and stands for ten minutes; wsp add <provider> asks for that provider's key, puts it to the provider before anything is written and saves it in ~/.wsp/.env; wsp add user@host [--name <name>] [--ssh-port <port>] [--ssh-key <path>] logs in over ssh as the person's own client would, installs the daemon on that box, starts it under that login's own service manager and waits for it to dial back, printing each step as it happens; the box is named after its hostname when no name is given. A bare alias from the person's ~/.ssh/config works in place of user@host: the add dials through that block, with its user and its port unless --ssh-port names another, and names the box after the alias up to its first dot. wsp remove <place> takes a computer back out: the agent and its files come off it over the link, the workspaces standing on it go with their threads, and the computer is otherwise left as wsp found it; a place that was not connected keeps its agent and the line says to run wsp leave there. The other two run on the computer being joined, not on the host: wsp join <address>... --code <code> [--name <name>] dials those addresses in turn until one answers, proves a key it makes there, writes the place file and installs the agent as a launchd agent or a systemd user unit which dials again at every login, --code-file <path> reading the code off a file and deleting it first; the service runs the daemon binary itself, and wsp leave sweeps wsp off that computer for somebody whose host is gone. wsp host pair prints that code, when it expires and the addresses to open; it is the person's own terminal on the computer the host runs on, never a thread's, since handing out a code hands out the host, and aimed at a host somewhere else, by --host, by WSP_HOST or by the default alias, it says in one line that it runs at that host's own terminal and dials nothing. wsp host devices lists the computers that took a code and what each token is read as (the owner's own browser, a paired device, a thread's token), and wsp host devices revoke <id> takes one back out; both take the host pick like every other verb, so wsp host devices --host box reads and cuts the devices of the box from the laptop paired with it. wsp host connect <url> --code <code> --name <alias> is the other side of that code: it redeems one against a host on another computer, keeps the token it buys in a file only this person can read, and gives that host a name. wsp hosts is the one listing of the hosts this computer can reach, the ones on the person's account and the ones it paired with a code, with the road each is held by in a VIA column, a live beat for the account's and the one every line takes marked; wsp host default <alias> moves that mark, and wsp host forget <alias> hands the token back and forgets it. A box nobody can reach inbound takes the third road: wsp host link <url> puts the computer the host runs on onto the person's relay account, printing a code and a page they approve in their own browser, and from then on every wsp up there asks that relay for a tunnel, runs the connector against its own loopback port and prints public https://<hostname> once it has one, so nothing has to be open to the world; wsp up --no-relay serves without the tunnel, and wsp host unlink takes the computer off the account and stops it. The other side of it is on the person's own computer: wsp login signs that computer in to their account, printing one word to approve on a computer already in and a page to approve it on when none is, and wsp hosts then lists the boxes on the account and writes a record for each, so every verb reaches them by name with no code typed; the first dial at one proves the key this computer signs with, which the box was told to trust at its link, and takes a device token of its own. wsp login <word> on a computer already in signs the admission for the one waiting, wsp login <id> does the same for a computer already on the account, wsp login on its own lists the account's computers with who admitted each, and wsp logout signs this computer out while wsp logout <id> signs another out, which every box reads on its next beat. wsp host link on a computer that is already signed in puts the box on that account with no code and no page at all. Keys and tokens never pass through the relay: an admission is bytes one computer signed and the relay carries, and every box verifies it with keys of its own. Every verb then takes --host <alias> for one line, as wsp threads --host box does, and the WSP_HOST environment variable does the same for a whole shell; --state names a file on this computer, so it is not read for a host somewhere else and a line that gives both says so. With no host named, a line goes to the host serving the state file on this computer, and only when none does to the default alias. wsp init [--recipe <path>] [--non-interactive] [--json] [--yes] builds the image, --json printing each sign-in and its outcome as one object on stdout with everything else on stderr, --non-interactive doing the same in prose, and --yes taking every default and skipping the sign-ins, which is why --yes is refused beside --json; wsp doctor forks a live machine to prove one workspace end to end; wsp mcp [--host <alias>] serves the tools over stdio, against this computer's host or the one that alias names; wsp mcp install --agent <id> [--host <alias>] writes the server into that agent's own MCP config, with the alias in the command it registers when the tools are for a host on another computer, this skill into its skills folder, and wsp's own marked section into the instructions the folder it runs in keeps, AGENTS.md for every agent and CLAUDE.md beside it for Claude Code. A second run replaces that section where it stands, so there is only ever one and everything around it is untouched, a file whose end marker somebody deleted is repaired to that one section rather than given a second begin marker, and wsp mcp install --agent <id> --remove takes it back out, leaving the file's other lines byte for byte and the config and the skill where they are. --agent repeats to do several in one call, one failing id costing the others nothing, and off a terminal a run that names none takes every agent whose own command is on the PATH. --json answers with one line holding the server command every config now runs, what each agent took, its docs naming the files the section went into, and a failures array, a provider failure when that array is not empty. The prose ends on the one thing to do next, which is inside the agent that was just set up. wsp image export <file> writes the image record and the sign-ins it holds into one encrypted file at that path, sealed to a passphrase: it asks for it twice at a terminal and reads WSP_IMAGE_PASSPHRASE where there is none, never a flag, since every process on a computer can read another's command line. There is no tool for it: the vault leaves the host only at a person's hand. The three sign-in lines are the person's: wsp agents signin opencode runs an agent's own sign-in on this computer in their terminal, wsp agents signin gemini <workspace> inside a workspace, and a box they added takes wsp add spoo --sign-in codex, which runs a shared login at that box's logins folder and any other as the owner of its home; wsp servers signin notion --agent claude --on spoo runs the harness's own sign-in for one MCP server where it is set up; wsp agents key claude puts the token claude setup-token prints, or an agent's API key, into the host's vault, typed where nothing echoes it and only at the host's own terminal. Hand the person the line; never run one for them. An entry under installed with no path took the skill and not the server, which is the by-hand line the prose prints. Only agents the catalog knows an MCP config for get the server: claude, codex, gemini, opencode. The rest get the skill and a by-hand line.

For a shell script

One verb is a shell script's and not an agent's, because it blocks: a script that starts threads and has to stand at the end of them has nothing else to do while they run.

In your own conversation this is the wrong road: a blocked wait is minutes of your turn spent on nothing, and nothing can reach you while it runs. Start children with --notify me and end your turn instead when you are a thread, and hand a job of more than one turn to a coordinator thread when you are not; the two rules are the next section's.

Running work on a workspace well

These decide whether work on a machine goes fast or stalls, and they hold on every workspace.

• A wsp thread starts every child with --notify me and ends its turn, and each child's finished line wakes it with that child's whole report, so nothing is polled and no turn is spent waiting. The launch environment says whether you are a thread, and --notify me resolves to whichever thread the request came out of.
• A caller that is not a wsp thread cannot be woken at all, so it takes the reply of one turn as the call returns, and hands work of more than one turn to a single coordinator thread on the local workspace, with the whole job in its brief and the person told where to read it.
• A project on this computer is a workspace too, the one wsp add <folder> and wsp new "<what you are working on>" make: put a quick subtask or a second harness on it, since it forks nothing, starts in a second, costs nothing and runs the agents already on this computer's PATH over the person's own files and sessions. Fork a cloud workspace for builds that run beside each other, for anything that should not touch this computer, and for a disk you can snapshot and hand to the next workspace.
• Snapshot a workspace once a project's dependencies are installed on it: wsp snapshot <workspace> keeps that disk as a project image, and wsp new <name> --from <that image> starts every later workspace with the install already there, so no thread installs the same dependencies twice.
• One heavy thread per machine: on 2 vCPU and 4 GB one thread runs tests or a build at a time and a second thread is a light send. Three test runs at once starve the machine and every turn in flight fails.
• A thread that builds gets its own git worktree, which is how two threads share one machine, and that worktree's setup is made cheap rather than skipped: pnpm's side-effects cache so a native module is compiled once per machine, and the checkout's node_modules hardlinked into the new worktree before pnpm install --offline, which then only verifies. A worktree set up from scratch relinks thousands of files and rebuilds native modules, minutes on 2 vCPU.
• wsp send <thread> continues a thread that has already replied; a send into a thread whose turn is still running opens no second turn and is a mistake. Wait for the turn to end, or wsp stop <thread> first.
• Restarting the host cuts every turn running on every workspace. Finish or stop the running turns before wsp down and wsp up.
• Pause a workspace nobody is using with wsp pause <workspace>: a sleeping machine costs nothing beyond its disk and gives back one of the two machines the account runs at once, and the next thread or command wakes it.
• The person's app and the command line read the same host, so every thread opened here shows in their sidebar and they read its reply there. Name each one with --title and keep the reply short and complete.

The contract

The command line, the MCP tools and this skill are one contract: every capability exists in all three or in none, and the parity test in the repo holds them to it. With --json, stdout carries JSON alone: one JSON object per line, frames first, the last line is the result; a verb with no stream prints the result alone. The result is the object the MCP tool of the same name answers with, less what the frames already carried, so no line prints twice: wsp exec --json prints one exec.output frame per output line and then a result with the exit code and the folder; wsp fork dev --send "<task>" --json prints the creating frames, the workspace and then {"turn": ...}. Without --json, stdout is for a person. Progress, the waking line and every refusal go to stderr. A refusal or a failure is one line on stderr, the failure object {"error": "<the line>", "class": "usage", "exit": 3} under --json, and the exit code is the class's:

wsp exec is the one exception: its exit code is the command's own, and only a machine that could not run it is a provider failure. A person saying no to a confirmation is <name> kept on stderr with exit c

Truncated - read the full file at https://github.com/Zingzy/wsp/blob/3d97283622eac0d770ca7ef43a64c63687374654/skills/wsp/SKILL.md.