github-actions-builder
Skill22 starsChanged 2 months agoMITView on GitHub
Builds reliable, fast, and secure GitHub Actions CI/CD workflows with dependency caching, build matrices, scoped secrets, concurrency control, and reusable/composite workflows. Use this skill when the user asks to "create a GitHub Actions workflow", "set up CI", "add CI/CD", "fix a flaky/slow GitHub Actions pipeline", "add a build matrix", "cache dependencies in CI", "write a reusable workflow", "configure deployment with environments and secrets", or mentions files under .github/workflows.
- Reads credentials
- Installs packages
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 21
Pick triggers (
on:): Use pull_request for validation and push (filtered to the default branch) to avoid double-runs on PR branches. - Very specific: line 23
Set top-level defaults: Always add permissions: (least privilege, default contents: read) and concurrency: to cancel superseded runs.
- Very specific: line 29
Cache dependencies correctly: Prefer the built-in cache of setup-* actions (cache: 'npm'|'pip'|'gradle').
- Very specific: line 33
Factor shared logic: If two or more workflows repeat steps, extract a reusable workflow (on: workflow_call) or a composite action.
- Very specific: line 35
Validate: Run python3 scripts/validate_workflow.py <file> to catch missing permissions, unpinned third-party actions, plaintext secrets, …
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
GitHub Actions Builder
Overview
Author production-grade GitHub Actions workflows that are fast, deterministic, and secure by default.
Keywords: github actions, workflow, ci, cd, ci/cd, .github/workflows, jobs, steps, runs-on, matrix, build matrix, strategy, fail-fast, cache, actions/cache, setup-node, setup-python, setup-go, secrets, GITHUB_TOKEN, permissions, OIDC, environments, reusable workflow, workflow_call, composite action, concurrency, artifacts, upload-artifact, deploy, release, pinning SHA, dependabot.
This skill covers the full lifecycle: choosing triggers, structuring jobs, caching dependencies correctly, fanning out across a matrix, passing secrets safely, gating deployments with environments, and factoring shared logic into reusable or composite workflows. Always prefer the patterns and pinning rules in references/best-practices.md and validate output structure with scripts/validate_workflow.py.
Workflow
- Clarify intent. Identify: project language/runtime, the events that should trigger CI (push, pull_request, tag, schedule, manual), and whether deployment is in scope. If the user only says "add CI", default to lint + test on
pushto the default branch and onpull_request. - Pick triggers (
on:). Usepull_requestfor validation andpush(filtered to the default branch) to avoid double-runs on PR branches. Addworkflow_dispatchfor manual runs andtagsfilters for release pipelines. See the trigger matrix inreferences/best-practices.md. - Set top-level defaults. Always add
permissions:(least privilege, defaultcontents: read) andconcurrency:to cancel superseded runs. Pin a sensibletimeout-minuteson every job. - Structure jobs. Split lint, test, and build/deploy into separate jobs so failures are isolated and parallel. Use
needs:to express ordering. Gate deploy jobs onif: github.ref == 'refs/heads/main' && github.event_name == 'push'. - Add a matrix when relevant. Fan out across runtime versions and OSes with
strategy.matrix. Setfail-fast: falsefor test matrices so one failure does not cancel the rest. Useinclude/excludefor targeted combinations. Seeexamples/node-matrix-ci.md. - Cache dependencies correctly. Prefer the built-in cache of
setup-*actions (cache: 'npm'|'pip'|'gradle'). When you need finer control, useactions/cachewith a lockfile-hashedkeyandrestore-keysfallback. Cache rules and key recipes live inreferences/caching-guide.md. - Handle secrets and auth safely. Reference secrets only via
${{ secrets.NAME }}, never echo them, scope them withenvironment:, and prefer OIDC over long-lived cloud credentials. Followreferences/secrets-and-security.md. - Factor shared logic. If two or more workflows repeat steps, extract a reusable workflow (
on: workflow_call) or a composite action. Templates are intemplates/reusable-workflow.ymlandtemplates/composite-action.yml. - Validate. Run
python3 scripts/validate_workflow.py <file>to catch missingpermissions, unpinned third-party actions, plaintext secrets, missingconcurrency, and absenttimeout-minutesbefore committing.
Decision Framework
| Need | Use |
| Run checks on every PR | on: pull_request + separate lint/test jobs |
| Avoid duplicate runs on PR branch | push filtered to branches: [main] only |
| Test across versions/OS | strategy.matrix + fail-fast: false |
| Share steps across repos | Reusable workflow (workflow_call) |
| Share steps within one repo | Composite action under .github/actions/ |
| Gate prod deploy | environment: with required reviewers |
| Talk to AWS/GCP/Azure | OIDC + permissions: id-token: write |
| Pass build output between jobs | actions/upload-artifact + download-artifact |
| Cancel stale runs | concurrency: with cancel-in-progress: true |
Worked Example (minimal Node CI)
name: CI
on:
push:
branches: [main]
pull_request:
permissions:
contents: read
concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- run: npm ci
- run: npm testFor richer scenarios see examples/node-matrix-ci.md (multi-version + OS matrix with caching) and the templates directory.
Best Practices
- Pin third-party actions to a full commit SHA (e.g.
actions/checkout@<sha>), not a moving tag. Officialactions/*may use@v4if the org policy allows; everything else gets a SHA. Add a comment with the version for readability. - Least-privilege permissions. Declare
permissions:at the top, default tocontents: read, and grant write scopes only on the specific job that needs them. - Always set
concurrencyandtimeout-minutes. Prevents pile-ups of stale runs and hung jobs burning minutes. - Use
npm ci/pip install -r ... --require-hashes/ lockfile installs, never unpinnednpm install, for reproducible builds. fail-fast: falsefor test matrices,true(default) for build/release matrices where one failure invalidates the set.- Cache by lockfile hash and include
restore-keysso a near-miss still warms the cache. - Group related steps into reusable workflows once duplicated; keep individual workflow files focused on one purpose.
- Use
environment:for deploys to get protection rules, required reviewers, and scoped secrets. - Prefer OIDC (
id-token: write) over storing cloud access keys as secrets.
Common Pitfalls
- Double runs: triggering on both
pushandpull_requestwithout filteringpushto the default branch runs CI twice on PRs. Filterpushbranches. - Unbounded permissions: the default
GITHUB_TOKENmay be broad; not declaringpermissions:is a supply-chain risk. Always set it. - Broken cache keys: using a constant key never invalidates; hashing the wrong file (e.g.
package.jsoninstead ofpackage-lock.json) misses changes. Hash the lockfile. - Leaking secrets:
run: echo ${{ secrets.X }}or passing secrets into untrusted PR contexts (pull_request_target) exposes them. Never echo; avoidpull_request_targetwith checkout of PR code. - Floating tags on third-party actions:
@v1or@mastercan be hijacked. Pin to SHA. fail-fastcancelling a debug matrix: leaving ittruehides which versions actually fail. Setfalsefor tests.- Missing
actions/checkout: many workflows fail because the repo was never checked out before build steps. - Secrets unavailable in reusable workflows: caller must pass them via
secrets:(orsecrets: inherit); they are not auto-forwarded.
Validate every workflow you produce with scripts/validate_workflow.py and consult the references before finalizing.
Other versions2 projects use a version of this.
Word for word · 2
- JayRHa/agent-skills★ 12100% same
- JayRHa/AgentSkills★ 12100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository194 other files it gives its agents.
- 0-templateSkill
- ab-test-analyzerSkill
- academy-guideSkill
- add-to-my-skillsSkill
- adr-authorSkill
- ai-tools-setupSkill
- algorithmic-artSkill
- api-and-interface-designSkill
- api-designerSkill
- api-docs-writerSkill
- apple-store-submitSkill
- aws-cost-optimizerSkill
- bash-script-hardeningSkill
- blog-post-writerSkill
- book-summarizerSkill
- branch-cleanupSkill
- brand-copy-landingSkill
- brand-copySkill
- brand-designSkill
- brand-guidelinesSkill
- browser-testing-with-devtoolsSkill
- canvas-designSkill
- changelog-generatorSkill
- changelog-keeperSkill
- chart-chooserSkill
- ci-cd-and-automationSkill
- ci-fix-loopSkill
- claude-apiSkill
- cloudflare-block-countriesSkill
- coderabbitloopSkill
- code-review-and-qualitySkill
- code-reviewerSkill
- code-simplificationSkill
- codexloopSkill
- comms-notionSkill
- comms-slackSkill
- comms-whatsappSkill
- competitive-analysisSkill
- concept-explainerSkill
- constraint-driven-developmentSkill
- context-engineeringSkill
- context-repoSkill
- cover-letter-writerSkill
- crash-courseSkill
- cron-schedulerSkill
- data-digestSkill
- data-pipeline-architectSkill
- debug-detectiveSkill
- debugging-and-error-recoverySkill
- decision-matrixSkill
- dependabot-triageSkill
- dependency-upgraderSkill
- deprecation-and-migrationSkill
- dev-instantdbSkill
- discernment-nudgeSkill
- doc-coauthoringSkill
- dockerfile-proSkill
- docs-index-keeperSkill
- documentation-and-adrsSkill
- docxSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

