Menu
Add or review GitHub Actions CI for programming-language and skills projects, including README badges linked to workflow runs.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when changing what a running devloop harness serves — pointing it at a different directory or worktree, or making the live harness serve newer or different code (a newer commit, another branch, or in-progress edits) without a wasteful restart.
Use when verifying that a UI change works end to end by driving the running app in a real browser — confirming a fix, reproducing a reported UI symptom, or proving a wizard/form/flow behaves — with Playwright against the exact code under review.
Enforce a Roborev plus Kata development workflow for code changes. Use when Codex is asked to implement, fix, refactor, or review work tracked by Kata and Roborev, especially when branch discipline, non-blocking review jobs, validation gates, SemVer, changelog checks, and final delivery reporting matter.
Use when working on GitHub pull requests that need PR-ready validation, review-thread replies, reviewer mentions, linked external references, or merge readiness checks.
Create or review a standalone repository that publishes a set of Codex or Claude skills with shared validation, linking, eval, and agent metadata conventions.
Prepare small, reviewable local commits with explicit rationale, SemVer impact, task hygiene, branch cleanup expectations, and clear commit commentary. Use when asked to commit work, prepare a PR-ready change, decide version impact, write commit messages, or clean up merged feature branches.
| name | ci |
| description | Add or review GitHub Actions CI for programming-language and skills projects, including README badges linked to workflow runs. |
Use this skill when adding, reviewing, or fixing repository CI.
Implement a GitHub Actions workflow under .github/workflows/ unless the repository already has the correct workflow.
For programming-language projects, run the repository's deterministic tests, linters, format checks, builds, or package checks. Prefer the project's existing commands and package manager. Do not invent a test command when the repository has a clear one.
For skills projects, run skills validation with the repository's validation wrapper and validate the smallest affected skill set. In this repository shape, CI keeps one stable required validate job, uses the scope script to decide skip, focused, or full validation, and runs the wrapper only for affected skills:
scripts/skill_ci_scope.sh "$event_name" "$head_sha" "$base_sha" "$before_sha"
scripts/run_skill_ci_validation.sh
Do not make skills-project CI revalidate unrelated skills for ordinary pull requests. Shared validation infrastructure, cross-cutting configuration, and scope script changes should keep the required job stable, validate script syntax or equivalent static checks, and still run skill validation only for the changed src/<skill> directories.
When asked to state the CI behavior for a standalone skills repository, explicitly include the workflow path, pull-request trigger, stable validate job, scope script, validation wrapper, smallest affected skill set, and README badge link.
For hybrid projects, include both the programming-language checks and the skills validation.
Make pull requests run the CI workflow. Add push on main when post-merge validation is needed. Add tag triggers only when the repository actually publishes release artifacts from tags.
If a required CI job can skip work by scope, the workflow must still report a stable required check. Do not suppress a required workflow with paths-ignore. When rejecting that pattern, state all replacement parts together: keep the required workflow/check running, put skip/focused/full validation decisions inside the job based on affected files, and for skills projects validate the smallest affected skill set so ordinary changes do not revalidate unrelated skills.
Add or update a CI badge near the top of README.md.
Use the workflow badge image for the chosen workflow and link the badge to the GitHub Actions workflow runs page filtered to the default branch, so readers can reach the latest relevant run. Use this shape:
[](https://github.com/<owner>/<repo>/actions/workflows/<workflow>.yml?query=branch%3A<default-branch>)
Keep the badge label aligned with the workflow name, such as CI, Tests, or Skill CI.
When reviewing an incorrect badge target, explicitly require the replacement to link to the workflow runs page with the default-branch query, not only to the workflow file page. Name the query requirement directly, such as query=branch%3A<default-branch>.
After changing CI, validate at the narrowest useful boundary:
Do not claim CI is complete until the workflow file, README badge, and selected validation evidence agree.