The GitHub Actions optimization catalog

Every CI rule StarSling checks, as a page you can read and a catalog your coding agent can fetch. Each rule names how it is detected, the fix, and how to verify it.

34 rules in 4 categories

For coding agents

One compact JSON manifest sets out both ways to use these rules: run the skills, or apply the rules straight from these pages with nothing installed. It asks your agent which one you want before it installs anything. Then it names the three skills and lists every rule with its stable id, category, detection mode, and page URLs: /github-actions/catalog.json. This page mirrors to plain markdown at /github-actions/optimizations.md, and every rule page mirrors to its own .md.

Performance

Caching, sharding, scoping, and scheduling: the rules that decide how fast a run finishes.

Reliability

Timeouts and service readiness: the rules that keep runs from hanging or flaking.

Cost

The rules that stop CI from spending minutes and reviewer time it does not need.

Security

Permissions, pinning, secrets, and fork safety: the rules that close attack paths through CI.

Audit your repository

Run the detectors rather than reimplementing them. These rules come from StarSling's open-source agent skills, which carry the detection logic rather than describing it: ci-speedup for speed and cost, ci-secure for the security rules, and ci-score to grade a configuration against them. Install from the skills page.

To work from the pages instead, hand this prompt to your coding agent to run the whole catalog against your repository.

Prompt for your coding agent
Fetch https://starsling.dev/github-actions/catalog.json and read it. For each rule whose detectionMode is "static", fetch the markdown URL and run the page's detection steps against this repository. List every rule that applies, ordered by likely impact, with the file and line behind each finding. For "runtime" rules, list what run history you would need from the GitHub Actions API. A "hybrid" rule is both: run its detection steps against the repository AND name the run history that would confirm it. Then propose fixes for the top findings and open them as a reviewable PR; do not apply changes blindly.

Last updated 2026-08-31