feat: add github actions and codespaces efficiency skill

Author: Mark Heynes

docs/README.skills.md

@@ -177,6 +177,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [gh-cli](../skills/gh-cli/SKILL.md)<br />`gh skills install github/awesome-copilot gh-cli` | GitHub CLI (gh) comprehensive reference for repositories, issues, pull requests, Actions, projects, releases, gists, codespaces, organizations, extensions, and all GitHub operations from the command line. | None |
 | [git-commit](../skills/git-commit/SKILL.md)<br />`gh skills install github/awesome-copilot git-commit` | Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping | None |
 | [git-flow-branch-creator](../skills/git-flow-branch-creator/SKILL.md)<br />`gh skills install github/awesome-copilot git-flow-branch-creator` | Intelligent Git Flow branch creator that analyzes git status/diff and creates appropriate branches following the nvie Git Flow branching model. | None |
+| [github-actions-codespaces-efficiency](../skills/github-actions-codespaces-efficiency/SKILL.md)<br />`gh skills install github/awesome-copilot github-actions-codespaces-efficiency` | Audit and improve GitHub Actions and Codespaces efficiency. Use this skill when a user wants to reduce CI minutes, cancel redundant runs, add dependency caching, narrow workflow triggers with path filters, slim devcontainers, right-size Codespaces, tune idle timeout guidance, or scope prebuilds to high-value branches. | `agents`<br />`references/actions.md`<br />`references/codespaces.md`<br />`references/patterns.md`<br />`references/reporting.md` |
 | [github-copilot-starter](../skills/github-copilot-starter/SKILL.md)<br />`gh skills install github/awesome-copilot github-copilot-starter` | Set up complete GitHub Copilot configuration for a new project based on technology stack | None |
 | [github-issues](../skills/github-issues/SKILL.md)<br />`gh skills install github/awesome-copilot github-issues` | Create, update, and manage GitHub issues using MCP tools. Use this skill when users want to create bug reports, feature requests, or task issues, update existing issues, add labels/assignees/milestones, set issue fields (dates, priority, custom fields), set issue types, manage issue workflows, link issues, add dependencies, or track blocked-by/blocking relationships. Triggers on requests like "create an issue", "file a bug", "request a feature", "update issue X", "set the priority", "set the start date", "link issues", "add dependency", "blocked by", "blocking", or any GitHub issue management task. | `references/dependencies.md`<br />`references/images.md`<br />`references/issue-fields.md`<br />`references/issue-types.md`<br />`references/projects.md`<br />`references/search.md`<br />`references/sub-issues.md`<br />`references/templates.md` |
 | [github-release](../skills/github-release/SKILL.md)<br />`gh skills install github/awesome-copilot github-release` | Guides IA through releasing a new version of a GitHub library end-to-end.  Handles SemVer versioning and Keep a Changelog formatting automatically. | `references/commit-classification.md`<br />`references/semver-rules.md` |

skills/github-actions-codespaces-efficiency/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: github-actions-codespaces-efficiency
+description: Audit and improve GitHub Actions and Codespaces efficiency. Use this skill when a user wants to reduce CI minutes, cancel redundant runs, add dependency caching, narrow workflow triggers with path filters, slim devcontainers, right-size Codespaces, tune idle timeout guidance, or scope prebuilds to high-value branches.
+---
+
+# GitHub Actions and Codespaces Efficiency
+
+Use this skill as a lean entrypoint for GitHub Actions and Codespaces efficiency work. Keep the hot path small: inspect the repo, identify the waste source, then load only the reference material needed for the current task.
+
+## Use This Skill When
+
+- The user wants to reduce GitHub Actions runtime, CI cost, or wasted workflow runs.
+- The user wants faster Codespaces startup or lower Codespaces spend.
+- The repo has `.github/workflows/*.yml`, a `.devcontainer/`, or explicit Codespaces configuration questions.
+- The user asks for caching, concurrency, path filters, matrix reduction, prebuild strategy, machine sizing, or idle-timeout guidance.
+
+## Load Only What You Need
+
+Start with the repo configuration, then load references selectively:
+
+- Read [`references/actions.md`](./references/actions.md) for GitHub Actions audits, job gating, matrix reduction, live validation, and workflow-specific fixes.
+- Read [`references/codespaces.md`](./references/codespaces.md) for devcontainer, machine-sizing, prebuild, and idle-timeout guidance.
+- Read [`references/reporting.md`](./references/reporting.md) when the user asks what changed, wants a before/after efficiency report, or wants another review pass over the remaining expensive jobs.
+- Read [`references/patterns.md`](./references/patterns.md) only when you need concrete YAML or configuration examples during implementation.
+
+If the task is CI-only, do not load the Codespaces reference. If the task is Codespaces-only, do not load the Actions reference.
+
+## Core Workflow
+
+### 1. Measure first
+
+Inspect the current configuration before proposing changes:
+
+- Workflow triggers and whether repeated pushes waste runs
+- Dependency installation and cache behavior
+- Whether docs-only or config-only changes trigger heavy validation
+- Whether matrix breadth matches the actual decision being made
+- Whether devcontainers or Codespaces defaults are oversized
+
+### 2. Rank fixes by payoff
+
+Prefer this order unless repo context says otherwise:
+
+1. Add dependency caching with lockfile-based keys
+2. Add or correct `concurrency` cancellation
+3. Remove duplicate workflow coverage before merging jobs together
+4. Narrow workflow or job triggers safely
+5. Reduce matrix breadth to match risk and event type
+6. Trim oversized devcontainer or Codespaces defaults
+
+### 3. Keep changes conservative
+
+- Do not hide required release, schema, migration, or shared-library validation behind overly-broad filters.
+- Do not assume fewer jobs means faster PR feedback; preserve parallelism unless runner cost matters more and the critical path stays acceptable.
+- Treat compatibility matrices as policy, not default ceremony.
+- Prefer opt-in triggers for nonessential write-back jobs such as formatting bots.
+- Separate repo-editable changes from GitHub/org settings recommendations.
+
+### 4. Verify in GitHub when possible
+
+YAML lint is necessary but not sufficient.
+
+- Validate trigger behavior with live runs when possible.
+- Use a low-scope change, such as a workflow-only or docs-only update, to prove heavy jobs actually skip.
+- Treat unexpected live behavior as a real bug even when the YAML looks correct.
+
+## Required Output Shape
+
+When using this skill, keep the response compact and structured around these four sections:
+
+1. `Waste sources`: the top cost or latency drivers you found
+2. `Proposed fixes`: the small set of highest-confidence changes
+3. `Validation`: what was proven live, what was only checked locally, and any remaining risk
+4. `Impact`: expected savings separately from measured savings
+
+For measured impact, separate:
+
+- PR wall-clock time
+- Total runner time across jobs
+- Jobs or matrix legs avoided entirely
+
+## Review Rubric
+
+Use this rubric when reviewing current or updated efficiency work:
+
+- `Scope discipline`: only relevant domain guidance was loaded
+- `Safety`: required validation coverage was preserved
+- `Token efficiency`: the skill or report stayed focused on the active task
+- `Measurement quality`: expected and measured gains were clearly separated
+
+If one rubric dimension is weak, call that out explicitly instead of averaging it away.
+
+## References
+
+- [`references/actions.md`](./references/actions.md)
+- [`references/codespaces.md`](./references/codespaces.md)
+- [`references/reporting.md`](./references/reporting.md)
+- [`references/patterns.md`](./references/patterns.md)

skills/github-actions-codespaces-efficiency/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "GitHub Actions and Codespaces Efficiency"
+  short_description: "Reduce GitHub CI and Codespaces waste"
+  default_prompt: "Use $github-actions-codespaces-efficiency to audit this repo for GitHub Actions and Codespaces efficiency, then propose the highest-value fixes with clear validation and expected impact."

skills/github-actions-codespaces-efficiency/references/actions.md

@@ -0,0 +1,72 @@
+# GitHub Actions Efficiency
+
+Load this reference only when the task involves GitHub Actions or CI workflow efficiency.
+
+## Audit Order
+
+Inspect in this order:
+
+1. `.github/workflows/*.yml`
+2. Docs describing CI expectations
+3. Existing reports or run history if the user wants measured impact
+
+Start with common, low-risk waste:
+
+1. Missing dependency caches
+2. Missing `concurrency` cancellation
+3. Over-broad workflow triggers
+4. Duplicate workflow coverage across files or jobs
+5. Expensive jobs that run on every change regardless of scope
+
+## Actions-Specific Guidance
+
+### Trigger scoping
+
+- Use `paths` or `paths-ignore` when whole workflows truly should not run for some file classes.
+- Use job-level gating when event-level filters are too coarse.
+- Prefer explicit changed-file detection when reliability matters more than clever filter expressions.
+
+### Job shaping
+
+- Do not merge jobs blindly. If separate jobs preserve parallelism and shorten the critical path, keep them separate.
+- Keep lightweight coordination or change-detection jobs separate from heavy execution jobs when that makes skip behavior obvious.
+- If a workflow-only change still runs the full suite, treat that as evidence the gating model is too broad.
+
+### Matrix reduction
+
+Match matrix breadth to the decision being made:
+
+- Full matrix for releases or explicit compatibility validation
+- Reduced compatibility matrix for runtime, plugin, packaging, or framework-integration changes
+- Single representative latest-version leg for ordinary code changes
+- No heavy test job for clearly non-runtime changes when lighter protection already exists
+
+### Optional maintenance jobs
+
+Formatting or autofix jobs that write back to a branch are often better as opt-in jobs.
+
+Good triggers:
+
+- PR label such as `ci:format`
+- Manual dispatch
+- Explicit comment-command flow if the repo already supports it
+
+If you use a label trigger, remember to listen for PR `labeled` and usually `unlabeled` events or the label change will not reevaluate the job.
+
+## Safe-Change Rules
+
+- Do not hide required release, migration, or shared-library validation.
+- Do not widen changed-file scope accidentally when replacing a wrapper action.
+- Treat severity drift as a regression risk.
+- Match the real check surface before replacing a broad action with native tools.
+
+## Live Validation
+
+Prefer live GitHub validation when possible:
+
+- Trigger `workflow_dispatch` workflows once
+- Verify stale-run cancellation with two quick updates
+- Verify path-gating with an incremental ignored-only or workflow-only change on an existing branch
+- Confirm heavy jobs skip in the UI instead of assuming they would
+
+Do not treat the first push on a brand-new branch as a clean path-ignore test.

skills/github-actions-codespaces-efficiency/references/codespaces.md

@@ -0,0 +1,43 @@
+# Codespaces and Devcontainer Efficiency
+
+Load this reference only when the task involves `.devcontainer/`, Codespaces sizing, prebuilds, or workspace cost.
+
+## Audit Order
+
+Inspect:
+
+1. `.devcontainer/devcontainer.json`
+2. Related Dockerfiles, features, and setup scripts
+3. Any docs that recommend machine sizes, prebuilds, or startup expectations
+
+## Common Waste Sources
+
+- Oversized base images
+- Unnecessary packages or extensions
+- Slow post-create bootstrap steps
+- Prebuilds enabled for too many branches
+- Missing guidance on machine sizing or idle timeout discipline
+
+## Preferred Fix Order
+
+1. Remove unnecessary packages, features, and extensions
+2. Reduce startup commands and post-create installs
+3. Recommend the smallest machine size that preserves throughput
+4. Narrow prebuild scope to default and high-traffic branches
+5. Add or tighten idle-timeout and cleanup guidance
+
+## Safe-Change Rules
+
+- Do not optimize startup by removing tools the team actually needs every day.
+- Distinguish repo changes from org or user settings.
+- Prefer documentation when the effective control lives outside the repo.
+- Avoid turning the devcontainer into a production-like image unless the team explicitly needs that.
+
+## Reporting Focus
+
+When reporting Codespaces improvements, separate:
+
+- Faster startup
+- Lower steady-state workspace cost
+- Lower prebuild spend
+- Guidance-only recommendations that still need org or user action

skills/github-actions-codespaces-efficiency/references/patterns.md

@@ -0,0 +1,60 @@
+# Canonical Patterns
+
+Load this reference only when you need concrete examples during implementation.
+
+## Dependency Cache
+
+```yaml
+- uses: actions/cache@v4
+  with:
+    path: ~/.npm
+    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
+    restore-keys: |
+      ${{ runner.os }}-node-
+```
+
+Adapt the cache path and invalidation file to the repo's ecosystem.
+
+## Cancel Stale Runs
+
+```yaml
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+```
+
+## Scope Triggers
+
+```yaml
+on:
+  push:
+    paths:
+      - "src/**"
+      - "tests/**"
+      - "package.json"
+```
+
+Use `paths-ignore` when exclusion is easier to maintain than inclusion.
+
+## Job-Level Changed-File Gating
+
+Use a small change-detection step that emits explicit outputs such as:
+
+- `docs_relevant`
+- `runtime_relevant`
+- `compat_relevant`
+- `run_tests`
+
+Gate downstream jobs on those outputs when event-level filters are not expressive enough.
+
+## Matrix Reduction
+
+Use the minimum matrix that matches the decision:
+
+- Full matrix on release
+- Reduced compatibility matrix on sensitive runtime surfaces
+- Single representative leg for ordinary code changes
+
+## Optional Write-Back Job
+
+Use label-driven or manual triggers for jobs that mutate the PR branch, such as formatting bots.

skills/github-actions-codespaces-efficiency/references/reporting.md

@@ -0,0 +1,42 @@
+# Efficiency Reporting and Follow-Up Review
+
+Load this reference when the user asks what changed, wants a before/after report, or asks for another pass over remaining expensive jobs.
+
+## Reporting Rules
+
+- Separate expected savings from measured savings.
+- Do not claim exact time or cost savings without before/after run data.
+- Call out confounders such as cache warm-up, changed matrix breadth, runner changes, or unusually small PRs.
+
+Use this phrasing when data is incomplete:
+
+`I can report the efficiency mechanisms that changed, but I cannot honestly claim exact minutes saved without comparing before/after GitHub Actions runs.`
+
+## What To Measure
+
+Gather:
+
+1. A baseline sample before the change
+2. A post-change sample after caches warm
+3. Per-workflow or per-job duration comparisons
+4. Avoided runs, skipped jobs, or avoided matrix legs
+
+Always separate:
+
+- PR wall-clock time
+- Total runner time across jobs
+- Work avoided entirely
+
+These answer different questions. A change can reduce runner spend without materially improving the fastest feedback path.
+
+## Follow-Up Review Pass
+
+After the first round of fixes is validated, inspect the remaining expensive jobs:
+
+- Compare setup time versus execution time
+- Identify heavyweight wrapper actions and confirm what they really enforce
+- Review whether each matrix dimension still serves an active decision
+- Recheck after caches warm
+- Break down the dominant slow step before proposing further changes
+
+Keep the follow-up compact. Report the next few highest-value opportunities, not a long wishlist.