ci-local
Skill8 starsChanged 48 days agoMITView on GitHub
Run the checks a GitHub Actions workflow would run, locally, when Actions
- Reads credentials
1 other project uses a version of this.
Adopted by
Most recently taken up by
- cristian-robert/claude-code-harnesstheir own version, first seen Sep 15, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- cristian-robert/claude-code-harness★ 2same name
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 repository53 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-browserSkill
- anything-to-skillSkill
- ci-generateSkill
- clotho-researchSkill
- codex-imagegenSkill
- create-ruleSkill
- create-skillSkill
- db-migrateSkill
- docker-initSkill
- docs-adrSkill
- docs-checkSkill
- docs-diagramSkill
- docs-initSkill
- docs-rfcSkill
- docs-updateSkill
- env-setupSkill
- find-skillsSkill
- fix-bugSkill
- git-commitSkill
- git-create-prSkill
- gitflowSkill
- git-releaseSkill
- git-syncSkill
- i18n-checkSkill
- implement-featureSkill
- improve-skillSkill
- inject-docsSkill
- jira-cliSkill
- motion-studioSkill
- optimize-ai-setupSkill
- orchestrateSkill
- oss-launchSkill
- prd-to-issuesSkill
- product-design-specSkill
- product-design-tokensSkill
- product-prdSkill
- project-illustratorSkill
- project-plannerSkill
- refactorSkill
- renderSkill
- review-codeSkill
- review-depsSkill
- review-designSkill
- review-perfSkill
- review-planSkill
- review-securitySkill
- shipSkill
- stopslopSkill
- test-suiteSkill
- vrt-checkSkill
- wtfSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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 34
If invoked with [workflow-file] and/or --job name, skip the glob: read only that file, and if --job is given, extract only that job.
- Very specific: line 38
Read each file. A job gates merges if its workflow triggers on pull_request or push to a protected branch: ignore jobs that only run on …
- Distinctive: line 46
No subagent tool available?
- Very specific: line 63
If no explicit version is pinned in the workflow, check .nvmrc / package.json#engines.node or .python-version / …
- Very specific: line 78
Run the translated commands via Bash, in the same order the workflow declares them, stopping to report clearly the moment one fails (don't …
- Distinctive: line 103
Every row's result comes from a command you actually ran this session: never write PASS, FAIL, or a test count you didn't observe in the …
- Very specific: line 120
Matrix build,
strategy.matrix: node: [18, 20, 22]: run once on whatever fnm/nvm resolves locally (say 20), mark 18 and 22 as NOT … - Distinctive: line 128
If the same repo asks for this repeatedly, that's a signal to fix the actual CI quota/outage, not to keep leaning on the local stand-in: …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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
CI Local
Reproduce a GitHub Actions run on the local machine. The workflow YAML is the spec: read it, don't guess at what "the lint step" or "the test step" means.
Scope
GitHub Actions only (.github/workflows/*.yml). If the repo uses GitLab CI, CircleCI,
or Jenkins instead, say so and stop: no translation layer exists for those yet
(add one if it comes up twice, not speculatively).
Phase 1: Find the merge-gating jobs
- If invoked with
[workflow-file]and/or--job name, skip the glob: read only that file, and if--jobis given, extract only that job. OtherwiseGlobfor.github/workflows/*.yml(and.yaml). If none exist, tell the user there's no workflow to mirror and stop. - Read each file. A job gates merges if its workflow triggers on
pull_requestorpushto a protected branch: ignore jobs that only run onschedule,workflow_dispatch, orreleaseunless the user asks for those specifically. - For a multi-file or multi-job repo, use a haiku
Exploresubagent to read all workflow files in parallel and return a structured list of: job name, trigger, runs-on, steps (withuses/run/env/working-directory),services:,strategy.matrix, and any${{ secrets.* }}references. Keep this out of the main thread: workflow YAML is verbose and you only need the extracted summary. No subagent tool available? Read the workflow files directly and extract the same summary inline.
Phase 2: Translate steps to local commands
Walk the steps in order and translate each one. Do not invent a generic
lint && test && build: use exactly what the workflow does.
| Workflow step | Local translation |
actions/checkout | no-op: you're already in the working tree |
actions/setup-node with node-version: X | fnm use X (or nvm use X) before the next steps; if neither is installed, warn and continue on whatever node -v reports |
actions/setup-python with python-version: X | uv python pin X / uv run --python X ...; same fallback-and-warn if uv isn't available |
run: <cmd> with a working-directory: or env: block | run <cmd> from that directory with those env vars exported for just that command |
cache steps (actions/cache) | no-op: local disk cache already exists |
a run: step gated by if: on OS or event | skip if the condition can't hold locally (e.g. runs-on: windows-latest step on a Mac), and say so |
If no explicit version is pinned in the workflow, check .nvmrc / package.json#engines.node
or .python-version / pyproject.toml#requires-python before falling back to whatever's
on PATH.
Can't be replicated, flag, don't fake:
services:(Postgres, Redis, etc.): note the service and image; only attempt it if Docker is available and the user wants the extra step, otherwise mark the steps that depend on it as skipped.${{ secrets.* }}: check if a local.envsupplies the same variable name; if not, mark the step as skipped with the missing secret name, never substitute a fake value.strategy.matrix: run the one combination that matches the local machine (current node/python/OS); list the other matrix entries as not covered.
Phase 3: Execute sequentially
Run the translated commands via Bash, in the same order the workflow declares them,
stopping to report clearly the moment one fails (don't silently keep going past a
failed lint step and call the run "done"). Capture stdout/stderr for the report.
Phase 4: Report the parity table
CI Local Parity — <workflow file>, job "<job name>"
Step Local result Notes
---------------------------------------------------------------
checkout n/a already in working tree
setup-node 20 ok fnm use 20
lint (eslint) PASS
typecheck (tsc) PASS
test (vitest) FAIL 2 tests failing, see output above
build SKIPPED not run, blocked by failing test
postgres service NOT REPLICABLE no service container locally (Docker not requested)
deploy (secrets.AWS_*) NOT REPLICABLE secret not present in .envAny version-fallback warning from Phase 2 (pinned node/python version unavailable,
falling back to whatever's on PATH) must surface as a caveat/NOT REPLICABLE note in
this parity table: never absorbed into a PASS.
Every row's result comes from a command you actually ran this session: never write PASS, FAIL, or a test count you didn't observe in the Phase 3 output.
State plainly at the end whether the branch would pass the real CI gate, and what's still unverified because it couldn't run locally.
Examples
Targeted job, --job lint given: skip the glob, read only the named job's steps
from the file the user pointed at, translate and run just those, report a parity
table scoped to that one job.
Python repo, no pinned version in the workflow: actions/setup-python has no
python-version: key → check pyproject.toml#requires-python, find >=3.11, run
uv run --python 3.11 pytest. Note the fallback source in the parity table
("version from pyproject.toml, not workflow"), don't silently treat it as pinned.
Matrix build, strategy.matrix: node: [18, 20, 22]: run once on whatever fnm/nvm
resolves locally (say 20), mark 18 and 22 as NOT REPLICABLE: matrix entry not run
locally in the table instead of guessing they'd also pass.
Notes
- This is read-only with respect to git: no commits, no pushes, no workflow file edits.
Installing dependencies (
npm ci,uv sync, etc.) as part of a step is expected and fine. - If the same repo asks for this repeatedly, that's a signal to fix the actual CI quota/outage, not to keep leaning on the local stand-in: mention that once, don't nag.
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.

