StarSling Skills

Agent skills from StarSling, for optimizing your GitHub Actions.

Website

npx skills add starslingdev/skills

Pick the skills you want and your agent (Claude Code, Codex, Cursor, …). Add -g to install for every project instead of just this one. Each section below gives the one-line command for that skill on its own.

Skill	What it answers	Source
🏎️ ci-speedup	Why is my CI slow?	skills/ci-speedup/
📋 ci-score	Is my CI config following best practices?	skills/ci-score/
🔒 ci-secure	Can someone attack me through my CI?	skills/ci-secure/
🛰️ sling	Why did this run fail, and what did it cost?	skills/sling/

The first three audit a checkout and end the same way: your agent offers to fix the findings you pick, or to just save the full report as markdown. sling is the odd one out — it answers questions about live runs instead of auditing files. Fixes land in your working tree for you to review, and nothing is ever committed, pushed, or opened as a PR.

The three audit skills — ci-speedup, ci-score, ci-secure — run from a local checkout and need python3 3.9+ and PyYAML (pip install pyyaml). ci-speedup also needs gh auth login, because it reads your run history over the GitHub API. What they read stays on your machine: nothing is sent to StarSling, and nothing is sent to any third party (data handling). sling is the exception by design: it queries StarSling's control plane for the CI data StarSling already collects — sending the org, repo and run identifiers you ask about — and stores a credential at ~/.config/sling/credentials.

---

ci-speedup

🏎️ Measures what actually makes your CI slow, from your own run history.

npx skills add starslingdev/skills --skill ci-speedup

Or paste this into your agent:

Run `npx skills add starslingdev/skills --skill ci-speedup` to install or
update the ci-speedup skill.

Then invoke it by name (/ci-speedup, or $ci-speedup in Codex), or just ask "why is my CI slow?"

It reports two axes, never blended: developer wall-clock wait (the merge-gating critical path, and the axis findings rank on, because it is what engineers feel) and runner-minutes (the bill). The numbers come from real runs: per-job P50/P95 sampled over the gh API, with the critical path re-derived from your actual job graph, then matched against a catalog of 80+ patterns.

It diagnoses; it does not prescribe. A generic tool can't tell deliberate from wasteful, so each finding ships a ready-to-paste prompt handing the root cause to your own agent, which reads the logs and git history before changing anything.

Example reports from real runs: pallets/flask and microsoft/playwright.

Read the skill: SKILL.md — what it does, step by step · ARCHITECTURE.md — how the pipeline fits together · CHANGELOG.md The catalog and the methods: optimization-patterns.md — all 80+ patterns · wall-clock-methodology.md — how the merge-gating critical path is derived · savings-methodology.md — how every number is sized Everything else: skills/ci-speedup/ · Learn more: starsling.dev/ci-speedup

---

ci-score

📋 Grades your CI configuration against best practices, and hands back the fixes.

npx skills add starslingdev/skills --skill ci-score

Or paste this into your agent:

Run `npx skills add starslingdev/skills --skill ci-score` to install or
update the ci-score skill.

Then invoke it by name (/ci-score, or $ci-score in Codex), or just ask "grade my CI". Runs fully offline.

Eleven configuration facts (caching, shallow checkout, sharding, concurrency cancellation, path filters, timeouts, action pinning, OIDC scoping and more), each checkable in your own workflow YAML in under a minute. The score is checks passed over checks applicable; every failed check gets one ranked fix.

It measures adherence, not speed, and it is not a security audit: two of the eleven checks are security-adjacent, and it claims nothing further.

Example report from a real run: pallets/flask, scoring 89/100.

Read the skill: SKILL.md — what it does, step by step · CHANGELOG.md The rubric: ci-score-methodology.md — what each check asks and why · ci-score-spec.json — the eleven checks, machine-readable Everything else: skills/ci-score/ · Learn more: starsling.dev/ci-score

---

ci-secure

🔒 Finds ten critical attack vectors an outsider could exploit, and fixes them.

npx skills add starslingdev/skills --skill ci-secure

Or paste this into your agent:

Run `npx skills add starslingdev/skills --skill ci-secure` to install or
update the ci-secure skill.

Then invoke it by name (/ci-secure, or $ci-secure in Codex), or just ask "is my CI secure?"

It scans for the ten critical attack vectors: template injection, fork code run with privileges, cache poisoning, impostor action SHAs, secret dumps, $GITHUB_ENV hijack, write tokens on untrusted triggers, credentials in caches and artifacts, unverified remote code execution, and install scripts running beside secrets. Each finding names the file and line, quotes your own workflow, and says in plain English what an attacker could do. It then offers to fix the ones you pick, leaving the diff in your tree. It never commits, pushes, or opens a PR.

Deliberately not comprehensive, and no security score. Ten closed-set vectors, each a full outsider → compromise chain with a real incident behind it (why these ten). Zero findings is a first-class result, and a check that could not run says did not run, never "pass".

Example reports from real runs over one workflow file in snowflakedb/snowflake-connector-net, scanned at two commits: 3 findings before the vendor's fix, and 0 findings after.

ci-secure CI check

A scan says what is wrong today. The CI check runs the same engine on every pull request, so the findings do not come back. Paste this:

Run `npx skills add starslingdev/skills --skill ci-secure` to install or
update the ci-secure skill, then install ci-secure as a CI check in this repo.

It is vendored, never fetched: the engine, the gate and the licence are copied into your repository, so the code judging your PRs is code you can read and it cannot change underneath you. It is two files plus the engine: scaffold/gate.py, which decides pass or fail, and scaffold/ci-secure.yml, the workflow that runs it. scripts/vendor.py is what copies them in. Because that writes into your working tree, the skill says exactly what it will write and asks for a yes first, works on a branch as one setup PR, and never pushes without asking.

It ships in --advisory mode, so it does not affect your merge path on day one. It becomes blocking when you drop --advisory and add the check to your repository's required checks.

Read the skill: SKILL.md — what it does, step by step · CHANGELOG.md The vectors and the scope: security-patterns.md — all ten attack chains · why-these-ten.md — the selection criterion, and what was rejected · security-facts.md — the pass/fail config checks · ci-gate.md — running it as a CI check · troubleshooting.md Everything else: skills/ci-secure/ · Learn more: starsling.dev/ci-secure

---

sling

🛰️ Answers questions about one live CI run — and knows when to reach for gh instead.

npx skills add starslingdev/skills --skill sling

Or paste this into your agent:

Run `npx skills add starslingdev/skills --skill sling` to install or
update the sling skill.

Then invoke it by name (/sling, or $sling in Codex), or just ask "why did this job fail?"

The skill is named after the CLI it drives. The other three skills read your workflow files; this one reads your live CI, through sling, StarSling's CLI, read-only against your CI: why a job failed (classified server-side, no LLM in the loop), where a run's wall-clock actually went, only the log lines that matter, and what your runner minutes cost, broken down by repo, workflow, or label.

The routing is the point. sling changes nothing on GitHub, so an agent that only knows sling will invent a sling rerun that does not exist, and an agent that only knows gh will download a whole transcript to grep it. The skill carries the table that decides which tool answers which ask — reads about a run, a job, or spend go to sling; anything that changes state (re-run, cancel, trigger, enable, disable, download an artifact) goes to gh — plus the exit-code handling and the --agent JSON shapes for every command, read off the binary rather than the docs.

It needs three things, and the skill checks all three before answering: the sling CLI installed, you signed in (a browser step it hands back to you), and the StarSling GitHub App installed on the organization whose CI you are asking about — that last one is what StarSling reads your runs from, and without it a perfectly valid login sees nothing. Organizations only; the app installs on a personal repository but StarSling never picks up its jobs. Everything the skill does is a read, unless you ask for a state change and it tells you before making it.

Read the skill: SKILL.md — the routing table, the preflight, the gotchas · CHANGELOG.md The commands: command-reference.md — every flag and JSON shape, read off the binary · gh-fallback.md — what gh does that sling cannot · command-surface.json — the complete command list, machine-readable Everything else: skills/sling/ · Learn more: docs.starsling.dev/sling-cli

---

For maintainers

Maintainer-only infrastructure lives outside the installable skill trees, under maintainers/, so the skills CLI never copies it into an install:

• maintainers/ci-speedup/: the self-improvement loops, which run locally via Claude Code and never as a GitHub Action. See MAINTAINERS.md.
• maintainers/ci-score/: maintainer notes for ci-score, including what was deliberately left out of the shipped skill. See MAINTAINERS.md.
• maintainers/ci-secure/: the disclosure rule for findings from a scan of a repository you do not own, and the guard that enforces it. See MAINTAINERS.md.
• maintainers/skills-registry-security/: triage for a failing registry security audit, answering whether a finding describes the skill as it is today or a stale copy. See README.md.

This repo's CI runs on StarSling Runners. Fork PRs run the identical suite on GitHub-hosted runners, so untrusted code never executes on the self-hosted ones. See CONTRIBUTING.md.

License

MIT