---

name: github-actions-agent-ci description: Use when setting up GitHub Actions CI for a repo where coding agents open PRs, so the gate catches the failure modes agents produce: uncommitted imports, lockfile drift, and blocked dependency build scripts. Reproduces the deploy environment exactly.

GitHub Actions for Agent-Written Code

When to trigger

A repo where agents (or fast human iteration) push changes and you want CI to catch what passes locally but breaks the deploy, before it reaches production.

The failure agents produce most

An agent leaves an in-progress file unstaged, then commits code that imports it. Local checks pass (the file is on disk); CI checks out only the commit and fails. So the gate must test the committed tree, which a fresh checkout does by definition. Do not run checks against a dirty runner.

Reproduce the deploy environment exactly

Match the deploy's install and gate, or CI will disagree with production:

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: pnpm }
      - run: pnpm install --frozen-lockfile   # surfaces lockfile drift + blocked build scripts
      - run: pnpm typecheck                    # the SAME gate the deploy runs
      - run: pnpm build

• --frozen-lockfile fails on lockfile drift instead of silently updating, and surfaces ERR_PNPM_IGNORED_BUILDS when a dependency's build script is not approved (pnpm 11 blocks them by default; the approval list is allowBuilds: in pnpm-workspace.yaml).
• Run the exact type gate the deploy uses. If the deploy runs tsc --noEmit or a native preview, run that, not just next build, which does not fail on every type error.

Keep the gate fast and honest

• Add pnpm lint:ox (or your fast linter) as its own quick step so a lint error is not buried in a slow build.
• Cache the store (cache: pnpm) so installs are quick; never cache node_modules across lockfile changes.
• Fail the job on the first real error; a green PR check should mean the deploy will build.

Pitfalls

• Running checks with actions/checkout plus an unpinned pnpm install (not frozen) hides the exact drift the deploy will hit. Freeze the lockfile.
• next build passing is not proof the type gate passes. Run the gate the deploy runs.
• Skipping pnpm-workspace.yaml allowBuilds: means CI installs clean but the deploy hard-fails on ignored build scripts. Reproduce the install with --frozen-lockfile so CI catches it first.