PricingCustomersSkillsGuidesBlogDocsGet Started

← Back to blog

Introducing sling: an agent-first CLI for your CI

·By: Shreyansh Saurabh
View in markdown
The sling command typed at a terminal prompt, answering with its block-letter SLING banner

Today we're releasing sling, the official StarSling CLI. It's an agent-first CLI for your CI.

StarSling Runners are fast, AI-native GitHub Actions runners: a one-line swap for ubuntu-latest that our agents keep tuning. sling is how you and your agent see what those runners are doing. Why a job failed, where the time went, what it cost, and which workflow to fix first, without leaving the terminal.

curl -fsSL https://runners.starsling.dev/cli/install.sh | sh

Apple Silicon macOS and glibc x64 Linux.

Then sling login shows a short device code you approve in the browser with the GitHub account you're already signed into.

Or hand the whole setup to your coding agent. This prompt installs sling and the /sling agent skill, which teaches your agent when to reach for it, and it works in Claude Code, Codex, Cursor, OpenCode and more:

Set up the StarSling `sling` CLI and its agent skill on this machine (Apple Silicon macOS or glibc x64 Linux).

1. Install the CLI: run `curl -fsSL https://runners.starsling.dev/cli/install.sh | sh`,
   then confirm it with `sling --version`.
2. Install the agent skill: run `npx skills add starslingdev/skills --skill sling -y`,
   then read the installed SKILL.md end to end and follow it for every CI
   question I ask from now on.
3. Signing in is mine to do: `sling login` prints a short device code I approve
   in a browser. Print that command for me and wait until I tell you I am
   signed in.
4. Once I confirm, run `sling doctor` and tell me what it reports about the CLI,
   the login, and the StarSling GitHub App on my organization.

CLI for agents

Agents pick sling up seamlessly: it acquires the session you are already logged into. Three things make it usable from inside an agent loop:

  • Machine mode, one flag. --agent returns JSON on stdout, refuses prompts rather than waiting on them, and turns colour off, so an agent gets a shape it can parse and an exit code it can branch on.
  • Discoverable by design. sling --help maps every command to the question it answers, so an agent can find the right one without spending context hunting for it.
  • One command for what's broken. sling doctor checks your token, org, git remote, control-plane reachability and clock skew, and fails when something is genuinely broken.
$ sling top --agent
{
  "by": "workflow",
  "metric": "runner-minutes",
  "window": { "from": "2026-07-25T22:47:14.312Z", "to": "2026-08-24T22:47:14.312Z" },
  "rows": [
    {
      "key": "integration-tests",
      "repo": "web-platform",
      "runner_minutes": 69559,
      "cost_usd": 556.472,
      "runs": 12480,
      "jobs": 28715,
      "p50_ms": 69000,
      "p95_ms": 180000,
      "p99_ms": 358540,
      "queue_wait_ms": 14000,
      "trend_pct": 170.7
    }
  ],
  "local": { "org": "acme-corp" }
}

CLI for humans

When someone hits a failed job, they have three bad options: click through the GitHub UI, dump the whole log into an agent and pray, or pull raw data out of an API and diagnose by hand. sling lets you investigate a failed run, find the bottleneck in your pipeline, and share usage and cost with your team:

  • Deterministic diagnostics. sling why classifies a failure on the server with no LLM in the loop, so your agent spends its reasoning on the fix instead of the triage.
$ sling --help

USAGE
  sling <command> [flags]

AUTH & SETUP COMMANDS
  login:          Sign in via the GitHub device authorization flow
  logout:         Sign out and clear the stored credential and preferences
  whoami:         View your identity, organizations and credential
  doctor:         Check your environment and know what's broken
  org switch:     Set your organization that other commands use by default

INSPECT CI COMMANDS
  runs list:      Find workflow runs by branch, status, conclusion, or trigger
  runs show:      See which job in a run failed, or wait for it to finish
  jobs list:      List jobs in a run, or across a repo
  jobs show:      See which step in a job failed, and how long each took
  logs:           Read just the log lines you need, not the whole transcript
  resolve:        Resolve an id or GitHub Actions URL to its target

DIAGNOSE COMMANDS
  why:            Diagnose why a job failed, with evidence and next steps
  time:           Decompose CI wall-clock into runner-lifecycle phases

COST & CAPACITY COMMANDS
  usage:          Attribute runner minutes and usage cost over a window
  top:            Rank the biggest time and cost hotspots, with a trend
  bill:           See what you owe so far and the month-end projection
  bill history:   List prior finalized billed invoices
  labels list:    Compare runner sizes and per-minute cost for runs-on

Alongside gh

gh, GitHub's own command-line tool, lists and acts: it lists runs, streams logs, triggers workflows, re-runs jobs. sling reads and explains. It gives you a verdict instead of a transcript, a ranking instead of a list, and what CI costs, which gh does not report at all.

gh is already a prerequisite for every StarSling agent skill, so it is on every machine sling runs on. The two are built to sit beside each other, and the /sling skill decides which one answers each question. The full breakdown is on the sling CLI page.

The agent skill

Calling sling agent-first means more than machine-readable output. The other half is a skill that teaches your coding agent when to reach for it, and when not to:

npx skills add starslingdev/skills --skill sling -y

The skill's whole job is picking the right tool per request. A live question about a run, a job or your spend goes to sling. sling reads and analyzes, so anything that changes CI state goes to gh:

  • re-running a job
  • cancelling a run
  • triggering a workflow
  • enabling or disabling one
  • downloading an artifact

A repo-wide audit of your workflow files is neither, so it hands off to ci-score, ci-speedup or ci-secure and stops.

Analyze your CI

Find the bottlenecks across your workflows (sling top):

sling top

Diagnose a failed job and get a suggested path to a clean run (sling why):

sling why <job-url>
$ sling why https://github.com/acme-corp/api/actions/runs/1827/job/5274

JobName: Unit and E2E Tests / Affected UNIT Test
Failure Reason: A process ran out of memory. The runtime aborted, so the
                step's exit code is a consequence, not the cause.

Evidence
  Classification: oom
  Logs:
    node::OOMErrorHandler(char const*, v8::OOMDetails const&)
    Error: [vitest-pool]: Worker forks emitted error.
    Caused by: Error: Worker exited unexpectedly

Suggestions:
  1. Verify the logs
     sling logs 5274 --grep '##\[error\]|failures?:|FAIL|panicked'

Decompose CI wall-clock into phases with sling time, so you know whether the time went to a slow checkout, your own steps, or the managed infrastructure:

sling time <job-url>
$ sling time https://github.com/acme-corp/api/actions/runs/1831/job/5291

Job Name: Lint docs (att_5291.1) · Wall-Clock: 2m 55s · Queue-Wait: 1s

  PHASES           TIME %-SHARE  TIMELINE
  provision        3.0s  1.71%  █░░░░░░░░░░░░░░░░░░░░░░░
  checkout+patch  50.0s 28.57%  ███████░░░░░░░░░░░░░░░░░
  steps          117.0s 66.86%  ░░░░░░░████████████████░
  teardown         5.0s  2.86%  ░░░░░░░░░░░░░░░░░░░░░░░█


Top Steps

    STEP                    TIME
    Setup pnpm and Node.js 97.0s
    Check formatting        7.0s
    Lint with remark        6.0s

Attribute runner minutes and cost across your repos with sling usage:

sling usage
$ sling usage

StarSling usage — by repo
2026-08-08 → 2026-09-08 (current cycle)

KEY · REPO                         RUNNER MIN    JOBS     COST $  % TOTAL
acme-corp/web-platform                  975.0    1284      $7.80    52.0%
acme-corp/api-gateway                   630.0     856      $5.04    33.6%
acme-corp/mobile-app                    270.0     342      $2.16    14.4%

Inspect your CI

See every run and its status across the board with sling runs list:

sling runs list
$ sling runs list --limit 5

RUN         WORKFLOW                                 BRANCH EVENT         STATUS         DUR  JOBS CREATED
18274531902 .github/workflows/integration-tests.yml  main   push          in_progress      —  0/22 2026-08-24 09:14
18274418860 .github/workflows/integration-tests.yml  main   push          success     5m 42s 25/25 2026-08-24 08:51
18274102724 .github/workflows/changed-test-gate.yml  main   pull_request  success        32s   1/1 2026-08-24 08:33
18273960124 .github/workflows/flag-spam-comments.yml main   issue_comment success        13s   1/1 2026-08-24 08:19
18273943287 .github/workflows/codeql.yml             main   schedule      in_progress      —   0/2 2026-08-24 08:12

Billing

See what you owe so far and where the month is projected to land with sling bill:

sling bill
$ sling bill

Current cycle: 2026-08-08 → 2026-09-08
Invoice: pending (issued when the period closes)

Runner minutes        12500.0
Amount                $97.20
Projected month-end   $167.40

RUNNER LABEL                       TIME      COST
starsling-ubuntu-24.04      11800.0 min    $94.40
starsling-ubuntu-24.04-2      700.0 min     $2.80

Every command, with the install line and the skill that teaches your agent to use it, is on the sling CLI page. The full reference for every flag and exit code is at docs.starsling.dev/sling-cli.

sling is a client for StarSling's HTTP API, and that API is documented at docs.starsling.dev/api: the same runs, jobs, logs, labels, usage and billing endpoints the commands above call, generated from the OpenAPI spec. Reach for it when you want the data somewhere the terminal is not, like a dashboard or a bot of your own.

If your team runs CI on GitHub Actions, install the StarSling GitHub App to keep it in shape automatically.