Skip to content

GitHub Action

Hand someone a reusable step that runs by itself inside their own project, on every change. They paste one reference once; from then on your step fires on every push, every proposed change, or on a schedule. You fix it once and the fix reaches everyone.

Reach for it when the same check should run automatically across many people's projects. Skip it when they'd run it by hand (a one-command tool) or it's their agent that should do it (an MCP server).

Last verified: 2026-06-07 · Confidence: high on the run-on-events model, the public/private reach, and the immediate-publish Marketplace flow; checked against docs.github.com/actions.

It allows you to

  • Make it run on their events, not yours. Once wired in, your step fires on every push, every proposed change, or a nightly schedule — nobody presses go. The line between this and a tool run by hand. [confirmed]
  • Hand over one reference, not a folder. The whole share is one line — uses: you/your-action@v1 — pasted into a workflow file. No copying, no install. [confirmed]
  • Ship a fix to everyone at once. They pull your action by reference, so re-pointing your version tag carries the fix to every project on its next run. [confirmed]
  • Take inputs and gate their pipeline. The same step adapts per project — a path, a threshold — and can pass or fail their build, blocking a bad change before it lands. [confirmed]
  • Reach a crowd or a named few. Details: Who can get in.

Ideal for

  • An org-standard check on every proposed change — "no dependency with a known vulnerability or a banned licence gets merged" — run identically on every repo, blocking the merge if it fails. GitHub's own Dependency Review action does exactly this.
  • A "build and publish the docs" step many projects reuse — one action turns the latest source into a live docs site on every push, so no team writes its own publish script.
  • A shared data-validation step — "check this CSV against our schema before it's accepted" — wired into a partner org's pipeline so bad input is caught automatically.

Who can get in

  • Public, found by anyone. List it on the GitHub Marketplace and strangers add it with one reference — the widest rung. [confirmed]
  • Private, to your own org. Keep it in a private repo and grant it to your other private repos — your team uses it, nobody outside sees it. [confirmed]
  • Crossing org lines needs the public route. To let people outside your org reference it, the repo must be public — no "anyone with the link but unlisted" middle. [confirmed]
  • A published action can't be un-shared. Once people pin to your version, deleting or breaking it breaks their pipelines — treat the version tag as a contract. (A copy already pulled keeps working — true everywhere.) [confirmed]

Which rungs it can hold. Named-within-org (private repo) or the whole internet (public listing) — no just-you, no anyone-with-the-link. → Who can see it? [confirmed]

Handing data to the host. The action's code lives on GitHub; a published one is readable by everyone, so put nothing secret in it. → Can you trust the company? [confirmed]

What you do to set it up

  • Ask: tell Claude Code "build a GitHub Action that does \<the one step>, test it, tag a version, and tell me the line people add to their workflow." It scaffolds, tests against a workflow, and cuts the first release. Every later fix: one sentence, ~0 effort. [confirmed]
  • One-time, in order:
    1. Set up Claude Code — builds, tests, and releases it, ~10 min once.
    2. A GitHub account + the CLI so your agent can make the repo and cut releases — ~13 min once.
  • The Marketplace listing is the un-delegable bit. To list publicly, you tick the "Publish to Marketplace" box on the release in the browser (needs 2FA); it goes live immediately — GitHub doesn't review it. ~5 min once. An unlisted action shared by reference skips this. [confirmed]

Full walkthrough in Publish a GitHub Action. Rather do it by hand? → the by-hand section.

What the other person does

  • Wire it in once. They add ~three lines to a workflow file (uses: you/your-action@v1, plus any inputs) — no install, no account beyond the GitHub one they already have for CI. Their agent can do it: "add the you/your-action@v1 step to our test workflow." ~1–3 min, then never again. [confirmed]
  • Forget it. From the next push on, your step runs automatically on their events. [confirmed]
  • Get your fixes. Pinned to @v1, they pick up fixes on the next run; pinned to an exact version or commit, they freeze it. [confirmed]
  • Pay: nothing — a public action is free; their CI minutes are their own (free on public repos, generous free tier on private). [confirmed]

Floor: they already have a repo with CI running. Never run a workflow before? Point them at GitHub's own quickstart first.

Other ways to share

  • They'd run it themselves, when they choose, in a terminal? → a one-command tool: they type one word and it runs — no repo, no CI, no automatic trigger.
  • It's their agent that should do the step, mid-task, in plain language? → an MCP server or a Claude skill — the automation lives in their agent, not their pipeline.
  • You just want to hand over the code to read and change? → a GitHub repo: the files themselves, not a step that runs on its own.

Sources

Good to know

  • Composite first, almost always. If your step is "run these commands", the simplest flavour needs no build and no container — the shortest route from a step you run to a step others run. The tutorial covers the code and container flavours. [confirmed]
  • Version tags, the Marketplace listing gotcha, and pinning for security-sensitive recipients — the moving parts and one widely-reported listing snag, dated and sourced. → GitHub Action fine print.