GitHub Actions Cache Tuner

What this skill does

Pulls the timing breakdown for a workflow run, finds the steps that dominate wall-clock time, and proposes actions/cache configurations with predicted hit rates based on the lockfile invalidation cadence.

Inputs

• repo: <owner>/<name> for the GitHub repo.
• workflow_file: path under .github/workflows/ (e.g., ci.yml).
• run_id (optional): a specific run to analyze; defaults to the most recent successful run on the default branch.
• GITHUB_TOKEN env var with actions:read scope.

Steps

1. Fetch the run via gh api /repos/<repo>/actions/runs/<run_id>/timing --jq '.' to get billable minutes per job.
2. List jobs with gh run view <run_id> --json jobs and download per-step timings.
3. Sort steps descending by duration; flag any step over 60 seconds as a tuning candidate.
4. Parse the workflow YAML with yq '.jobs[].steps' .github/workflows/<workflow_file> to map durations back to step names and uses: actions.
5. For each candidate, classify by action: actions/setup-node, actions/setup-python, actions/setup-go, docker/build-push-action, custom run: install steps.
6. Suggest a cache spec per class: Node uses ~/.npm keyed on package-lock.json; Python uses ~/.cache/pip keyed on requirements*.txt; Go uses ~/go/pkg/mod keyed on go.sum; Docker uses type=gha.
7. Predict hit rate by counting how often the relevant lockfile changed in the last 30 days: git log --since='30 days ago' --pretty=format: --name-only -- <lockfile> | grep -c <lockfile> divided by total runs.
8. Emit a YAML diff per workflow file showing the new cache step in context.

Output

A markdown report with a "top 5 slow steps" table and a per-step proposed YAML patch (in fenced ```diff blocks). Includes predicted hit rate and expected per-run minutes saved.

Verification

After proposing the patch, lint the modified workflow YAML with actionlint to confirm syntactic validity. Re-fetch run timings for the previous five runs and confirm the slow-step ranking is consistent (a one-off slow step is a flake, not a tuning target). If the suggested cache key already exists in the workflow, downgrade the suggestion to "no change needed".

Edge cases

• First-time workflow with no historical runs: skip hit-rate prediction, mark all suggestions as "uncalibrated".
• Cache size cap (10 GB per repo): if predicted cache exceeds the cap, propose a narrower path scope.
• Self-hosted runners: cache action behavior differs; warn that hit-rate predictions assume hosted runners.
• Matrix builds: aggregate timings across matrix legs and report the median, not the max.