mgiovani/cc-arsenal/skills/ci-local/SKILL.md
ci-local
Run the checks a GitHub Actions workflow would run, locally, when Actions is unavailable or out of quota. Parses .github/workflows/*.yml, extracts the jobs/steps that gate merges (lint, typecheck, test, build), translates them to local commands respecting the workflow's pinned node/python versions and env, executes them sequentially, and reports a parity table of what passed locally vs. what can't be replicated (service containers, secrets, matrix dimensions) and why. Activates on "CI quota", "A
- Source repository stars
- 6
- Declared platforms
- 0
- Static risk flags
- 1
- Last source update
- 2026-08-04
- Source checked
- 2026-08-04
Decision brief
What it does—and where it fits
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.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/mgiovani/cc-arsenal --skill "skills/ci-local"Inspect the Agent Skill "ci-local" from https://github.com/mgiovani/cc-arsenal/blob/410f2649860bb1892ee8c66721f57462eeefcf13/skills/ci-local/SKILL.md at commit 410f2649860bb1892ee8c66721f57462eeefcf13. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Phase 1: Find the merge-gating jobs
1. 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. Otherwise Glob for .github/workflows/.yml (and .yaml). If none exist, tell the user there's no workflow to mirror and stop. 2. Read each file.…
If invoked with [workflow-file] and/or --job name, skip the glob: read onlyRead each file. A job gates merges if its workflow triggers on pullrequestFor a multi-file or multi-job repo, use a haiku Explore subagent to read all - 02
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.
services: (Postgres, Redis, etc.): note the service and image; only attempt it if${{ secrets. }}: check if a local .env supplies the same variable name; if not,strategy.matrix: run the one combination that matches the local machine (current - 03
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.
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 st… - 04
Phase 4: Report the parity table
Any 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.
Any 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. - 05
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).
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).
Permission review
Static risk signals and limitations
Reads files
The documentation asks the agent to read local files, directories, or repositories.
Read each file. A job **gates merges** if its workflow triggers on `pull_request`Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 6 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- mgiovani/cc-arsenal
- Skill path
- skills/ci-local/SKILL.md
- Commit
- 410f2649860bb1892ee8c66721f57462eeefcf13
- License
- MIT
- Collected
- 2026-08-04
- Default branch
- main
View the original SKILL.md
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 .env
Any 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.
Alternatives
Compare before choosing
K-Dense-AI/scientific-agent-skills
simpy
Build, inspect, test, and analyze bounded process-based discrete-event simulations with SimPy, including events, resources, interrupts, monitoring, replications, warm-up, and reproducible output analysis.
PramodDutta/qaskills
Allure Report Generator
Configure and generate rich Allure test reports with test categorization, historical trends, environment details, and CI/CD integration for comprehensive test visibility
muend/geoai-skills
swe-devops-standards
Always invoke to review, repair, or deliver geospatial or GeoAI code, including contract compliance, security, error handling, transactions, tests, scripts, functions, notebooks, packages, CI/CD, and repository changes, even when deployment is not requested. Pair with the domain skill for ETL and other production code. Covers CRS/data invariants, dependencies, cross-platform reproducibility, automation, and shipping. Do not trigger for unrelated software or analysis requesting no code or reposit
maziyarpanahi/openmed
gating-deid-leakage
Add a CI gate that fails the build when an OpenMed de-identification model's recall on a held-out PHI set drops below threshold or any critical identifier leaks. Use when the user wants a pytest test or CLI step that exits nonzero on de-id regression, wants to wire OpenMed's leakage-first release gates into GitHub Actions / CI, needs a recall floor plus zero-leakage assertion against a synthetic held-out set, or wants to block merges that weaken de-identification. Trigger on "CI gate", "fail the