agentsclimarketplace

Github actions

Skill mickzijdel/dev-hooks/plugins/dev-hooks/skills/github-actions

Hooks and skills for Claude to write better code and verify its work, and an easy start to using Claude Code

Install
npx -y skills add mickzijdel/dev-hooks --skill github-actions

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

One thing to look at

  • 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

Write, review, and harden GitHub Actions workflows against supply-chain attacks, and bump a whole fleet of repos' action pins to the latest versions. Use when writing or editing a workflow YAML (.github/workflows/*.yml, ci.yml), when asked to review a CI workflow or audit GitHub Actions security, when the ci-action-ref-reminder hook fires, or when the user wants to "bump my actions", "update the fleet", "pin actions to SHAs", run zizmor, or close supply-chain / pull_request_target / script-injection / GITHUB_TOKEN-permissions gaps. Pairs with references/security-checklist.md (the full checklist) and dev-env-setup's CI templates.

SKILL.md

6.8 KB, as published. Nobody here has run it

github-actions

The canonical home for everything GitHub Actions in your repos: the security checklist to apply when writing or reviewing a workflow, and the fleet-wide procedure for bumping action pins to their latest versions. The full checklist lives in references/security-checklist.md; read it whenever you touch a workflow. This skill is the security layer over [[dev-env-setup]], which owns the CI templates (already hardened to this standard).

The five that matter most

If you do nothing else when writing or reviewing a workflow, get these right:

  1. Pin every uses: to a full commit SHA, not a tag or branch — owner/repo@<40-hex-sha> # vX.Y.Z. Tags are mutable; a compromised maintainer can repoint @v3 to malicious code and every downstream run picks it up silently (tj-actions, Trivy).
  2. Default GITHUB_TOKEN to read-only. Add permissions: { contents: read } at the workflow level; grant more only on the specific job that needs it, at the job level.
  3. Never pull_request_target (or workflow_run) in public repos. They run with secret access on fork-PR-controlled input. Use plain pull_request, or gate on the upstream event.
  4. Never interpolate ${{ github.* }} into run:. Branch names, PR titles, issue bodies are attacker-controlled. Assign to an env: var first, then reference $VAR in the shell (Ultralytics, Nx/s1ngularity). Same rule for LLM output and anything written to $GITHUB_ENV / $GITHUB_PATH.
  5. Use OIDC for cloud credentials (AWS/Azure/GCP) instead of long-lived static secrets — short-lived, job-scoped, nothing to steal.

Writing or reviewing one repo's workflow

  1. Read references/security-checklist.md and walk the workflow against it. The most common real finding is unpinned actions and a missing permissions: block.
  2. Pin/verify the refs. Resolve each action's latest release SHA and pin it with a version comment:
    a=actions/checkout
    tag=$(gh release view --repo "$a" --json tagName -q .tagName)   # e.g. v7.0.0
    sha=$(gh api "repos/$a/commits/$tag" --jq .sha)                 # dereferences annotated tags
    echo "uses: $a@$sha # $tag"
    
    pinact automates this across a whole file (pinact run to pin tags→SHA with comments, pinact run -u to update to latest). Install it with mise use -g pinact or mise exec -- pinact if a repo pins it.
  3. Verify the pins resolve and the comments are honest before finishing:
    bash "$CLAUDE_PLUGIN_ROOT/skills/dev-env-setup/scripts/check_action_refs.sh" .github/workflows
    # SHA-pinned refs with a `# vX.Y.Z` comment are checked: the tag is resolved on the remote
    # and its SHA must match the pin. A mismatch (lying comment / wrong SHA) FAILs.
    
    If gh/pinact is unavailable or unauthenticated, say so and ask the user — never guess a SHA.
  4. Run actionlint + zizmor — correctness then security (the two analyzers the standard wires in). actionlint catches schema/expression/needs: errors; zizmor catches credential persistence, template injection, over-broad permissions:
    actionlint -shellcheck=                      # correctness; -shellcheck= skips the run: shellcheck pass
    zizmor --no-progress .github/workflows/       # security; exit 0 = clean, non-zero = real findings
    zizmor --no-progress --fix=all .github/workflows/<file>.yml   # apply mechanical fixes, then review
    
    Both are mise-pinned in every dev-env repo (mise.toml); install ad hoc with mise use -g zizmor actionlint elsewhere. Suppress a deliberate zizmor exception inline with # zizmor: ignore[<audit>], never by lowering the persona. (Dogfooded: the dev-env-setup CI templates ship one actions-lint job that runs both.)

Fleet-wide bump

Turn the per-repo recipe into one cross-repo pass (this is the "bump my fleet's actions" request). Mirror the cadence in the [[dev-env-bump-backfill-fleet]] memory: do the whole fleet in one session — branch, bump, verify, commit, push — so the repos stay in lockstep.

  1. Enumerate the fleet. Start from the dev-env fleet (repos carrying DEV_ENV_VERSION in mise.toml; the [[dev-env-bump-backfill-fleet]] memory lists the current set), and cross-check with live discovery:
    gh repo list "$(gh api user -q .login)" --source --no-archived --limit 200 --json nameWithOwner -q '.[].nameWithOwner'
    
    Keep only repos that actually have .github/workflows/. Show the user the target set and confirm it before changing anything — don't sweep in repos they don't want touched.
  2. Per repo (work in a temp clone or worktree, never on a dirty main):
    git switch -c chore/bump-actions
    pinact run -u                       # pin + update every uses: to the latest SHA + comment
    bash "$CHECKER" .github/workflows   # verify refs resolve and comments match
    git diff                            # eyeball before committing
    
    Also add a permissions: { contents: read } block to any workflow missing one, and apply any other checklist gaps you spot.
  3. Commit + push/PR with a consistent message per repo (e.g. chore(ci): pin actions to SHAs and bump to latest). Open a PR unless the user wants direct pushes. Do all repos in the same session, then report a one-line summary per repo.

Guardrails: gh/pinact missing or unauthenticated → stop and surface it. A repo whose CI is intentionally bespoke → flag it, don't force the standard. Never push to a repo's default branch directly.

How this skill is reached

  • Editing a workflow → the ci-action-ref-reminder hook fires and points here.
  • Setting up / upgrading the dev env → dev-env-setup's CI templates ship pre-hardened to this standard (SHA pins + permissions:) and link back here; the dev-env v16 bump is where this became the default.
  • "Review this CI workflow" / "audit my GitHub Actions" → this skill's description triggers directly.

Gives 0 of the 12 instructions most docs writing skills give

Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-06

  • announce the skill at startin 54 of 1637, across 21 files
  • convert legacy doc files before editingin 45 of 1637, across 7 files
  • predict questions readers might askin 42 of 1637, across 3 files
  • Generate clarifying questions for initial contextin 42 of 1637, across 3 files
  • Create document scaffold with placeholder textin 42 of 1637, across 3 files
  • Brainstorm content options for each sectionin 42 of 1637, across 3 files
  • Test document with fresh context-less instancein 42 of 1637, across 3 files
  • ask interview questions one at a timein 42 of 1637, across 26 files
  • include exact file paths in every taskin 42 of 1637, across 15 files
  • Apply surgical edits during refinementin 41 of 1637, across 2 files
  • Offer structured workflow or freeformin 40 of 1637, across 1 file
  • Ask for document meta-contextin 40 of 1637, across 1 file

Said here and by no other author read

  • read the security checklist before touching workflows
  • default the github token to read-only
  • never use pull_request_target in public repos
  • never interpolate github context into run blocks
  • run actionlint and zizmor before finishing
  • confirm the target repository set before changing anything

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.