Use with an Agent

Syndroo contains no language model and no natural-language step. A local-shell Agent can establish the project and its runtime first, check that the resolved Node.js and npm are the ones the project uses, install 0.7.2, read the bundled Skill, and ask whether you want the local workflow or the self-hosted Server workflow. After setup, the protocol is the contract; terminal prose is a convenience.

Set up with an Agent

Paste this prompt into a local-shell Agent. It asks for the project directory and runtime manager before anything is installed, records the resolved node and npm versions and the global root and prefix in that directory, verifies the executable a shim resolves to, includes the install command, finds the bundled Skill through npm root --global, and keeps Server choices and authorization explicit.

You are a local-shell coding Agent. Set up Syndroo 0.7.2 for me.

1. Before installing anything, establish where Syndroo will run. If I have not said, ask me which project directory will use Syndroo and which runtime manager that directory declares (mise, asdf, Volta, nvm, Homebrew or a system Node), and stay in that directory. A chat scratch directory or my home directory is not the project.
2. In that directory, record the runtime that is actually in effect: `command -v node npm`, `node --version` (24.19.0 or newer), `npm --version`, `npm root --global` and `npm prefix --global`. Confirm macOS or Linux for supported local writes.
3. Use that one runtime for the install, the version check, the Skill lookup and every later command. With mise, prefix commands with `mise exec --`; `mise which node`, `mise which npm` and `mise which syndroo` each take one argument, so run them separately. Do not assume Homebrew, do not compare pathnames across managers, and never prepend another bin directory to `PATH` to get around a shim.
4. Install Syndroo and its official platform plugins with:
   npm install --global @syndroo/cli@0.7.2 @syndroo/provider-sdk@0.7.2 @syndroo/provider-bluesky@0.7.2 @syndroo/provider-threads@0.7.2 @syndroo/provider-linkedin@0.7.2 @syndroo/provider-mastodon@0.7.2 @syndroo/provider-devto@0.7.2
5. Check what the shell resolves, then read and follow the packaged Skill: `command -v syndroo`, `syndroo --version`, then `npm root --global` and read `<global-root>/@syndroo/cli/skills/syndroo/SKILL.md`. Do not run or invent a separate Skill-installer command.
6. Ask whether I want the local workflow or the self-hosted Server workflow, then continue with my choice. For Server setup, ask whether I want GitHub; create or push a repository only when I explicitly authorize it, and reuse authorization I have already given. In 0.7.2, `connect threads` and `publish threads` need the project passed explicitly, for example `syndroo server --project . connect threads --app-id <app-id>`. Select my intended account from the accessible accounts listed by the project-local `wrangler whoami` output and pass that account ID with `--account`; if my intended account is not listed, stop and ask me instead of deploying to another account. Authenticate only when the session is missing or expired.
7. Keep secrets out of prompts, command arguments, logs, and tracked files. Publish content only with authorization for that content and destination.

One runtime, chosen before the install, is used for the version check, the Skill lookup and every later command. mise is one example, not a requirement: the prompt tells the Agent to run mise which with a single argument per command and never to assume Homebrew, compare pathnames across managers or edit PATH around a shim.

For Server setup, the Agent asks whether GitHub is wanted before creating or pushing a repository. It reuses authorization you already gave and stops when an action still needs you. Because the published 0.7.2 release requires it for connect threads and publish threads, the Agent passes --project . before a Server subcommand instead of guessing the directory. This prompt does not activate a Skill automatically in every Agent client; the Agent must read and follow the installed file.

Always ask for JSON

--json is a global flag, so it is accepted before or after the command. On success the envelope carries the operation name and the result; on failure it carries a stable code and a fixed message that was never built from a stack, a path or an argument.

{
  "protocolVersion": 1,
  "operation": "publish",
  "ok": true,
  "result": { "status": "confirmation_required" },
  "error": null
}

The failure shape is the same envelope with ok set to false, result as null, and an error object holding a code and a message. Branch on code; do not parse the message.

Read the exit code as a family

0 means the call was handled as documented, which can still be a pending authorization or a preview that needs confirmation. Exit 4 means a write may have reached the provider and no result is known. Exit 6 means an execution finished and is known not to be fully successful. The other values cover usage and preflight refusals, an explicit decline, an internal failure and an interrupted process; the CLI reference lists all seven.

Two phases, and a token that stays on stdin

Prepare first, execute second. The prepared result carries the frozen preview and a single-use approvalToken, and the execute request may only be read from standard input:

syndroo publish --input post.json --json > prepared.json
syndroo publish --input - --json < execute.json

An execute request that arrives from a file path or from --data is refused, so a live token cannot be left in the process arguments of a background call. Nothing is sent between the two phases: the content is frozen at prepare time and the second phase cannot re-read the original input.

An agent that already holds approval for one publication can do both phases in one call: syndroo publish --input post.json --yes --json prepares, auto-confirms and executes, and stdout is exactly one final execution or error envelope with no second prepared result and no approval token. With --json and no --yes the single envelope is the prepared result. --yes re-mints no credential, bypasses no identity, expiry, provider validation or idempotency rule, and creates no second prepare.

Give each logical call a stable identity

--request-id names one logical intent. Repeating the same call with the same id returns the recorded outcome instead of sending a second time, and reusing an id with different content is refused rather than silently overwriting the earlier record. For a connection, the same guarantee is built in: a repeated connect request replays the stored step.

Never put a credential in the request document

Credentials travel in SYNDROO_CREDENTIALS or a private file, never in the publish document and never in --data. If the content must stay out of the process arguments, read the request from standard input with --input - instead of passing it inline.

The packaged Skill

The installed CLI package contains @syndroo/cli/skills/syndroo/SKILL.md. Resolve the package with npm root --global from the same runtime that ran the install, then read <global-root>/@syndroo/cli/skills/syndroo/SKILL.md and follow it. There is no separate Skill-install or activation command to invent. Automatic discovery still depends on the Agent client.

Deploy a server

When you want a user-owned Cloudflare Worker, deployed Threads OAuth or manual GitHub CI, follow Deploy a server. GitHub repository creation and pushes are opt-in. Reuse authorization you already have and stop only for actions that still need the user, such as Wrangler or Meta browser authorization.

On the published 0.7.2 release, connect threads and publish threads need the project passed explicitly with --project . before the subcommand; deploy and doctor already use the current directory. Passing it on every project command stays correct. The reviewed fix makes the current directory the default, but it is not in a published release yet.

server init uses 0.7.2 @syndroo/cli and @syndroo/cloudflare packages and installs project-local Wrangler. Cloudflare, GitHub, Meta and Threads acceptance remains unverified in this project; see the CLI reference for limits.

Confirmation is not user authorization

A confirmation prompt is a local guardrail, not a grant of authority. An agent that runs without a human present is responsible for deciding whether the publication is allowed in the first place; the CLI only guarantees that nothing is sent before the prepare phase has produced a token for exactly this content and these targets.