CI

When to use it

Run $ci in Codex or /ci in Claude Code after onboarding or adoption when the project should run automatic GitHub checks. CI is optional and sits outside the normal feature loop.

The mental model

The CI skill configures Verify and the GitHub Actions worker, and adds the pre-push hook only when you opt in. It does not change a remote ruleset.

What it detects

The skill inspects the real stack, package manager, lockfile, runtime version, default branch, configured typecheck, test and build commands, test files, existing GitHub workflows, and documented external CI. It does not assume Node.js, npm, main, or an empty .github/workflows/ folder.

What it writes

The skill:

1. Creates or reuses one Verify command from configured checks, ordered as typecheck, tests, then build.
2. Records the exact invocation in the AGENTS.md Commands section.
3. Creates .github/workflows/verify.yml when that path is free and no equivalent CI already exists.
4. Offers an optional local pre-push hook with one question that defaults to no.
5. Runs the exact Verify command locally as the final proof.

Missing checks are omitted. If the project has no meaningful automated check, the skill stops instead of creating a workflow that always passes.

Optional pre-push hook

After the workflow exists, the skill asks once whether to add a local pre-push hook. The default is no, and the question is skipped when the request already answered it, such as /ci with hook or /ci no hook. When you accept, the skill:

1. Writes .githooks/pre-push, which runs the exact documented Verify command so the command’s exit code decides whether the push proceeds.
2. Points Git at that folder with git config core.hooksPath .githooks.
3. For JavaScript and TypeScript projects, adds a prepare script that repeats that git config line after install, so a fresh clone wires the hook without a manual step. Other stacks get the line documented in the README instead.
4. Runs the hook once. If it fails, the skill removes what it added and reports the failing command instead of leaving a hook the project cannot pass.

The hook and the workflow run the same Verify command, so a change to one applies to both. git push --no-verify bypasses the hook, which is why the GitHub ruleset remains the lock and the hook is only an early warning.

Local proof versus CI proof

A passing local Verify run proves the recipe against the current working copy. It does not prove that dependency installation and every command work from a fresh checkout. Until the workflow is pushed and reports green on GitHub, CI reports the setup as prepared locally, not CI verified. The first successful GitHub run is the authoritative clean-checkout proof.

Existing CI safety

Existing workflows and custom checks are preserved. When an equivalent workflow already exists, the skill reports it instead of adding a duplicate. When normalization would change existing CI, it shows the proposed change and waits for approval.

The default workflow runs for pull requests and pushes to the detected default branch, uses the project’s real runtime and lockfile-safe install command, grants only contents: read, and finishes by running the documented Verify command. If the default branch cannot be detected, the skill asks instead of guessing.

Relationship to tests

/ci never invents a test suite or installs a runner. Run /tests when the project needs unit testing. If Verify already exists, /tests adds the real test command to that recipe without creating or replacing CI.

After setup, /implement, /complete, /autopilot, and every feature completed by /continuous run Verify when it is documented. /doctor diagnoses drift between the documented command, the project script, and the GitHub workflow.

Boundaries

The beginner setup does not add lint, formatting, coverage thresholds, browser tests, security scanners, dependency audits, version matrices, or a required GitHub ruleset. A git hook is added only through the opt-in question, never silently. Existing CI checks remain intact. The skill does not push, publish, deploy, or change repository settings.

See Testing and CI for the full relationship between test evidence, Verify, GitHub Actions, and merge rules.