The Agent Skill

Teach your coding agent the CLI

A SKILL.md (plus reference docs) that drops into your coding agent's skills folder and teaches it exactly how to drive sproobo inside your repo — the same audited, role-gated CLI a human runs, with the same safety rules baked in as instructions the agent reads before it acts.

Install

One command, for Claude Code, Codex, or Cursor:

curl -fsSL https://cp.sproobo.com/skill/install.sh | sh
FlagMeaning
--tool claude|codex|cursorWhich agent tool to install for (default: claude).
--projectInstall into the current repo (./.<tool>/skills/sproobo) instead of your home directory (~/.<tool>/skills/sproobo).

It downloads SKILL.md plus three reference files — commands.md, ci.md, troubleshooting.md — into that folder. See Scripts & one-liners for exactly what the installer downloads and where.

Update: re-run the same one-liner — it overwrites the skill files in place, no uninstall step. Start a new agent session afterward to pick up the change.

What it teaches

The skill's first instruction is sproobo whoami — before doing anything else, confirm the CLI is installed and see what org and role it's signed in as. From there it walks the agent through:

  • CLI missing — install it with the same one-liner used on CLI reference, then re-check.
  • Auth errorsproobo login opens a browser for a human to approve. The agent can't complete that step itself, so it asks you to run it (or, for CI/headless, to supply SPROOBO_TOKEN as an sk_ API key instead).
  • The mental model — one org per key; the org owns servers; servers run apps (git-deployed, blue-green) and services (pinned-version containers); get ids from the list commands.
  • Plan-first writes — without -y, a write prints a PLAN and changes nothing.
  • Idempotent retries — every write carries a correlation id; reusing it via --correlation-id makes a retry replay instead of re-apply.
  • Machine-readable output — add --json to any command when parsing instead of reading.

The safety rules it enforces

Four rules, in the skill's own words, ranked non-negotiable:

  1. Destructive ops need the human. Never run secrets rm, rollback, or any op whose plan removes or replaces something with -y unless you explicitly asked for that exact action in the conversation — run the plan-only form first and show it.
  2. Secrets are write-only. secrets ls returns names only, by design. Never attempt to read a value back; never echo one into logs, files, or chat.
  3. Deploys you asked for are safe to run. They're blue-green with a health gate and automatic rollback on failure — a different risk class from a destructive rewrite.
  4. --help is the tie-breaker. If the skill and sproobo <command> --help ever disagree, trust --help — the CLI ships and updates independently of the skill text.
Same rules as the MCP connectors — restated as instructions.

These aren't a separate policy layer bolted onto the skill: they're the CLI's own plan-first / destructive-approval mechanics (see AI & MCP connectors) written as instructions an agent reads before acting, not a technical restriction unique to this skill. A human running the identical commands faces the exact same -y decisions.

MCP alternative

A tool that already speaks MCP doesn't need this CLI-driving skill at all — sproobo mcp runs a stdio bridge directly, and sproobo mcp config prints the client-config JSON to wire it in. Same tool catalog, same permissions, same audit trail either way.

Next