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.
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:
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
