CI Verify Setup

Goal

Give any coding agent one dependable command that verifies the project locally, then mirror that command in CI so local and remote feedback agree.

Use this skill when the user asks you to:

Add or repair a project-level verify, check, or equivalent command.
Set up GitHub Actions or another CI workflow for lint, typecheck, build, or tests.
Make the repo easier for Codex, Claude Code, Cursor, or other agents to validate.
Replace scattered manual checks with one documented verification path.

Inspect before editing.
- Identify the package manager, language, framework, and existing scripts.
- Read current CI config, contributor docs, and agent instructions if present.
- Note whether tests, linting, typechecking, formatting, and builds already exist.
Define the smallest honest local verification command.
- Prefer an existing command if it already covers the important checks.
- If no command exists, add one named according to local convention: verify, check, or the repo's established equivalent.
- Compose existing scripts instead of introducing new tooling unless a required check has no existing runner.
Make CI run the same contract.
- Add or update the CI workflow so it installs dependencies, restores cache if appropriate, and runs the local verification command.
- Keep local and CI commands aligned; do not let CI become a separate checklist.
- Use the repo's default branch, package manager lockfile, and supported runtime versions.
Document the verification path.
- Update README, contributing docs, or agent instructions with the exact command agents should run before handing off.
- Mention any checks that are intentionally excluded and why.
Verify the setup.
- Run the local verification command if the environment allows it.
- Validate workflow syntax when possible.
- If checks fail for pre-existing reasons, report the failure clearly instead of hiding it.

Never add a new package manager, lockfile, linter, formatter, or test framework just to make CI exist.
Never delete existing CI jobs without explaining what replaces their coverage.
Never make CI pass by weakening tests, suppressing type errors, or skipping meaningful checks.
Never claim verification works unless you ran it or clearly state why it could not be run.
Never commit secrets, tokens, or environment-specific credentials into workflow files.

[ ] Existing local scripts and CI were inspected before editing.
[ ] A single local verification command exists or an existing one was documented.
[ ] CI runs the same verification contract as local development.
[ ] Runtime versions, package manager, and lockfile usage match the repo.
[ ] Verification instructions were documented for future agents.
[ ] Local verification or workflow validation was run, or the blocker was reported.