agentsclimarketplace

Github actions

Skill ahtishamshahzad/agent_dev_flow/.ai/skills/devops/github-actions

Tool-neutral AI Engineering System: 174 reusable skills (installable as Claude Code plugins) for planning and building software with AI agents. Classify → plan → approve → build under quality gates. Works with Claude Code, Codex, Cursor, Windsurf, Copilot & Antigravity. Canonical in .ai/.

Install
npx -y skills add ahtishamshahzad/agent_dev_flow --skill github-actions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use to implement the designed CI/CD pipeline as GitHub Actions workflows — jobs/matrices, dependency + build caching, pinned action versions, least-privilege GITHUB_TOKEN, secrets from the store, environment protection rules for approval-gated deploys. Implements the ci-cd design; adds no jobs for nonexistent apps.

SKILL.md

5.1 KB, as published. Nobody here has run it

GitHub Actions

Purpose

Turn the ci-cd pipeline design into secure, efficient GitHub Actions workflows — correct triggers, caching, pinned actions, least-privilege permissions, and environment protection for gated deploys — without introducing jobs the design didn't call for.

When to Use

  • When the CI platform is GitHub and the ci-cd design is ready to implement.
  • Not for designing the pipeline (ci-cd) or on non-GitHub platforms.

Inputs

  • The ci-cd job design (app-derived jobs + gates).
  • Secret store + environments (secrets-management, environment-management), repo/monorepo shape.

Discovery Questions

  • What triggers each workflow (PR, push to main, tag, manual dispatch)?
  • Which jobs need which secrets, and from where (repo/environment secrets)?
  • Which deploys need environment protection rules (required reviewers) for approval gating?

Responsibilities

  • Implement the designed jobs as workflows/jobs with correct needs ordering and matrices where useful (Node versions, packages); implement exactly the app-derived set from ci-cd — no invented jobs for absent apps.
  • Cache dependencies and build outputs (setup-action caches, Turborepo remote cache if configured — turborepo-foundation); frozen installs (npm ci/pnpm --frozen-lockfile).
  • Pin action versions (by major tag at least, commit SHA for third-party actions) — floating @main is a supply-chain risk (../../security/dependency-security).
  • Apply least-privilege GITHUB_TOKEN: default read-only permissions, granting write scopes only per job that needs them.
  • Source secrets from GitHub secrets / environment secrets (secrets-management) — never inline; never echo into logs; be mindful of untrusted pull_request_target and fork PRs (don't expose secrets to fork code).
  • Gate deploys with GitHub Environments + required reviewers so production deploy jobs pause for approval (ci-cd, ../../release-planning); run post-deploy smoke (../../testing/smoke-testing).
  • Keep workflows DRY (reusable/composite workflows) where the repo has several apps.

Required Workflow

  1. Map the ci-cd jobs to workflows + triggers.
  2. Implement jobs with needs ordering + matrices; frozen installs + caching.
  3. Pin all actions; set least-privilege permissions.
  4. Wire secrets from the store; guard fork/PR secret exposure.
  5. Add environment protection rules for gated deploys + post-deploy smoke.

Decision Rules

  • Implement only the designed, app-derived jobs — the platform layer doesn't invent scope.
  • Default permissions: read-all; escalate per job, never globally to write.
  • Pin third-party actions to a SHA; a hijacked floating tag runs arbitrary code with your token/secrets.
  • Never expose secrets to untrusted fork PR code (pull_request_target care).
  • Production deploys pass through an Environment with required reviewers.

Rules

  • Actions pinned; GITHUB_TOKEN least-privilege.
  • Secrets from the store, never logged or inlined.
  • Deploy jobs approval-gated via Environments.

Anti-Patterns

  • Adding workflow jobs for apps the project doesn't have.
  • uses: some/action@main (unpinned third-party).
  • Global permissions: write-all.
  • Secrets echoed in logs or exposed to fork PRs.
  • Auto-deploy to production with no environment approval.

Validation Checklist

  • Designed jobs implemented (no extras for absent apps).
  • needs ordering + matrices; frozen installs + caching.
  • Actions pinned; least-privilege GITHUB_TOKEN.
  • Secrets from store; fork/PR exposure guarded.
  • Environment protection for gated deploys + post-deploy smoke.

Definition of Done

The ci-cd design implemented as GitHub Actions workflows — correctly ordered cached jobs, pinned actions, least-privilege token, store-sourced secrets, and environment-protected approval-gated deploys — matching the app-derived job set exactly.

Related Skills

ci-cd, secrets-management, environment-management, turborepo-foundation, deployment-selection, ../../testing/smoke-testing, ../../security/dependency-security, ../../release-planning, ../../github-repository.

Related Knowledge

../../../knowledge/ (triggers, environments, reviewers).

Related References

../../../references/devops/ (workflow patterns, when populated).

Context Loading Guidance

  • Requires: the ci-cd job design, secret store + environments, repo shape.
  • Does not require: re-deciding the pipeline scope, app feature code.
  • May load: secrets-management, deployment-selection.
  • Stop when: workflows implement the design with security + gates in place.

Token Efficiency Guidance

Work from the ci-cd job matrix; the workflow is its implementation. Keep YAML discussion to triggers, permissions, and gates.

Gives 0 of the 12 instructions most ci cd skills give

Counted across 392 of the 394 authors here whose files we hold, read 2026-08-06

  • pin third-party actions to full commit SHAsin 33 of 392
  • cache dependencies appropriatelyin 24 of 392, across 12 files
  • optimize pipelines exceeding ten minutesin 20 of 392, across 6 files
  • enforce all quality gates before mergein 20 of 392, across 7 files
  • Configure branch protection rulesin 19 of 392, across 5 files
  • use environments for deployment trackingin 19 of 392, across 7 files
  • implement manual gates for productionin 19 of 392, across 7 files
  • implement security scanningin 18 of 392, across 5 files
  • fix failing code instead of disabling checksin 18 of 392, across 4 files
  • use CI/CD variables for secretsin 18 of 392, across 6 files
  • move checks upstream in the pipelinein 17 of 392, across 3 files
  • use specific image tagsin 17 of 392, across 5 files

Said here and by no other author read

  • map pipeline jobs to workflows and triggers
  • implement designed jobs with needs ordering
  • implement jobs with matrices where useful
  • use frozen installs for dependencies
  • source secrets from GitHub secrets
  • gate deploys using environments and reviewers

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.