Update to Boltz

{
  "name": "boltz-cli-setup",
  "description": "Boltz CLI setup and auth. Use when installing, updating, verifying, or authenticating `boltz-api`, or fixing missing CLI, PATH, sandbox, browser login, or auth errors.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 247
    },
    {
      "relative_path": "references/sandbox.md",
      "size_in_bytes": 1548
    }
  ],
  "skill_md_contents": "---\nname: boltz-cli-setup\ndescription: Boltz CLI setup and auth. Use when installing, updating, verifying, or authenticating `boltz-api`, or fixing missing CLI, PATH, sandbox, browser login, or auth errors.\n---\n\n# Boltz CLI Setup\n\nUse this skill for `boltz-api` installation, version, PATH, and authentication issues. The workflow skills assume `boltz-api` is already installed.\n\n## Verify Installation\n\nCheck that the CLI is available:\n\n```sh\nboltz-api --version\n```\n\nIf `boltz-api` is missing or too old, prefer a version-pinned release artifact\nwhose checksum or signature can be verified. If Boltz does not publish one for\nthe user's platform, its official installer is the fallback.\n\nBefore downloading or running either installer, show the exact platform command\nand obtain the user's explicit confirmation. Explain that the command downloads\nmutable remote code, executes it as the user outside the sandbox, and therefore\ntrusts `install.boltz.bio` at execution time. A general request to use or install\nBoltz is not confirmation for this specific risk.\n\nmacOS and Linux:\n\n```sh\ncurl -fsSL https://install.boltz.bio/boltz-api/install.sh | sh\n```\n\nWindows PowerShell:\n\n```powershell\nirm https://install.boltz.bio/boltz-api/install.ps1 | iex\n```\n\nThe installer updates an existing `boltz-api` on `PATH`. If no binary is found, it installs to a user-local bin directory. Add the installed binary to `PATH` if `boltz-api --version` is still not found after install.\n\nThe sandbox can block browser login, OAuth callbacks, temp files, credential\nstorage, and user-wide install paths. Request the host sandbox bypass/escalation\nneeded for installation only after the installer confirmation above. The host\napproval must cover the exact command; do not treat an ordinary setup request as\nauthorization to execute mutable remote code outside the sandbox.\n\nRead [references/sandbox.md](references/sandbox.md) when an agent sandbox blocks the installer, browser auto-open, OAuth callback, credential storage, temp files, or global install path.\n\n## Authenticate\n\nCheck the current auth state with:\n\n```sh\nboltz-api auth status\n```\n\nIf `auth status` reports unauthenticated, or any Boltz command fails because authentication is missing or expired, start device-code login on the user's behalf before retrying:\n\n```sh\nboltz-api auth login --device-code\n```\n\nDo not ask the user for permission before starting device-code login; relaying the login URL/code and waiting for the CLI to complete is part of auth recovery. When sharing the authentication login URL/code, tell the user to use exactly `boltz-api auth login --device-code`.\n\nFor auth recovery, assume the CLI can auto-open the browser and run the exact command above. In sandboxed environments, request the host sandbox bypass/escalation needed for browser auto-open, OAuth callbacks, credential storage, or temp files.\n\nFor automation, an API key is still supported when it is already provisioned in\nthe environment:\n\n```sh\ntest -n \"${BOLTZ_API_KEY:+configured}\" && echo \"BOLTZ_API_KEY is configured\"\n```\n\nNever ask the user to paste an API key into chat or a command, and never print,\nlog, or persist it in shell history or generated files. If the variable is not\nalready provisioned, direct the user to their host's secret-management facility.\n\n## Version Checks\n\nDo not hard-code expected commands or minimum versions in this skill. Treat the CLI's own update check as the source of truth.\n\nWhen `boltz-api` reports that an update is available or required, relay that message and the install command it provides. The CLI may get this from a Boltz-hosted version metadata endpoint such as `/cli/version`, returning latest version, minimum supported version, whether an update is required, and platform-appropriate install instructions.\n\nIf a user asks why the CLI thinks it is stale, explain the split:\n\n- GitHub Releases define which CLI binaries are available to install.\n- The Boltz version endpoint defines API compatibility, including the minimum supported CLI version.\n\nRespect user or CI opt-outs such as `BOLTZ_API_NO_UPDATE_CHECK=1`; do not force update checks when the environment disables them.\n"
}