CI

ci - set up automatic GitHub checks

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

First action: Before project inspection, preflight, or any other tool call, publish running to blueprint/.state/run.json using the dashboard activity contract in AGENTS.md.

Where this sits in the workflow:

/onboard or /adopt  ->  [ci]  ->  Verify locally  ->  GitHub runs Verify
(project commands)     (setup)    (same recipe)      (pull requests)

This skill gives local work and GitHub one shared automated command. It is an optional setup task, not a requirement for using the Blueprint.

Keep the beginner explanation simple:

• Verify is the recipe. It runs checks the project already has.
• GitHub Actions is the worker. It runs the same recipe automatically.
• A GitHub ruleset is the lock. That optional remote setting can require the worker to report green before merge.
• A pre-push hook is the early warning. That optional local setting runs the recipe before a push leaves the machine. It is a convenience, not the lock: git push --no-verify skips it.

This skill configures the recipe and worker, and adds the hook only when the user opts in. It never changes the remote ruleset, pushes, publishes, or deploys.

Input

No argument is required. A named provider or workflow preference is a request to review, not permission to replace existing CI. This skill's default provider is GitHub Actions because it creates GitHub pull-request checks.

Step 1 - inspect without changing files

Read enough to identify the real project setup:

• AGENTS.md, especially Commands and any documented Verify command
• package or language manifests and task-runner files
• lockfiles and the package manager they imply
• existing typecheck, test, build, lint, and other quality commands
• test configuration and actual test files
• runtime version files such as .nvmrc, .node-version, .python-version, go.mod, or rust-toolchain.toml
• .github/workflows/ and any documented external CI
• git's current branch, configured default branch, and remotes when available

Do not assume npm, Node.js, main, or GitHub from the Blueprint template. Do not run installs or edit files during inspection.

If an existing workflow already provides equivalent pull-request checks, explain what it runs. If it is healthy and aligned with a documented Verify command, report that no setup is needed. If normalization would change existing CI, show the proposed change and get explicit approval before editing it.

Step 2 - define one Verify command

Build one command from meaningful checks that actually exist, in this order:

1. typecheck
2. tests, only when a runner and real test command are configured
3. build

Omit missing checks. Do not install a test runner, invent an empty test suite, or add a placeholder command. Lint, formatting, coverage, browser tests, security scans, dependency audits, and version matrices are not part of the beginner default. Preserve them when existing CI already requires them, and discuss any normalization before changing that behavior.

For JavaScript and TypeScript, add or reuse a package script named verify and invoke it with the detected package manager. For other stacks, use the existing native task runner or the smallest clear combined command. Document the exact invocation as Verify in the Commands section of AGENTS.md.

Examples are explanatory only. Never copy them without detecting the project:

Verify: npm run verify
Verify: make verify
Verify: cargo test && cargo build --locked

If no meaningful check exists, stop and explain what is missing. Do not create a workflow that always passes.

Step 3 - create or align the workflow

Create .github/workflows/verify.yml only when that path is free. If it already exists, never overwrite it silently. Show the exact proposed diff and ask before changing it.

The workflow should contain only what the detected project needs:

• a clear workflow name such as Verify
• pull_request
• pushes to the detected default branch
• permissions: contents: read
• the real runtime version
• checkout and the appropriate runtime setup action
• the lockfile-safe dependency install command
• one final step that runs the exact Verify command from AGENTS.md

If the default branch cannot be identified from git or project context, ask before writing the push trigger instead of guessing. Preserve all other workflow files. When another workflow overlaps, report the overlap and ask whether to reuse, align, or leave it alone.