Put an agent in your pull request.
Some changes cannot be checked by a linter. A skill file, a semantic view, a prompt, a policy: these are prose and configuration that no compiler validates, and a bad edit does not fail loudly, it changes behaviour quietly. This is a pattern for reviewing that class of change in CI, where Cortex Code reads the diff, judges it against a rubric you own, and the workflow turns that judgement into a merge decision.
Get the code
Every use case here is a working template, not a description of one. The repository holds the workflow, the evaluator, the rubric, the scripts, and fixtures that exercise each outcome, so you can run it before you adopt it.
What stays the same, and what changes
Every use case below shares the same plumbing. A GitHub Action installs and pins the Cortex Code CLI, the workflow computes what the pull request actually changed, the agent runs headlessly with a read-only tool allowlist, and a small script maps the agent's verdict to an exit code. None of that varies.
What varies is the rubric and the prompt. That is the point: the judgement lives in a markdown file you can read, review, and change without touching the workflow. Making the gate stricter is a documentation edit, not a code change.
Use cases
SKILL.md before it reaches an agent
running in production. Business users own the domain vocabulary in a skill file, but
prose has no compiler: a removed description silently stops the skill firing, and a
contradictory instruction makes agent behaviour nondeterministic rather than wrong in a
fixed way. The gate catches both.Why an agent rather than a linter
A script can check that a file has a description, that its referenced paths exist, and that its code fences are closed. Those checks are worth having and they are cheap. But the defects that actually cause incidents are not shaped like that. Two instructions that contradict each other are both individually valid. A description that is technically present but uses vocabulary no user would type is syntactically fine. A workflow branch that never terminates parses cleanly.
Judging those requires reading the change the way the agent consuming it will read it. That is what this pattern delegates. It also means the gate has to be built so it can never silently approve, because a reviewer that sometimes fails to answer must fail loudly rather than default to yes. Each use case documents how it handles that.
Prerequisites
A Snowflake account with Cortex Code available, a service user the workflow can authenticate as, and a repository on GitHub Actions. Workload identity federation via OIDC is the recommended auth path because it mints a short-lived token per run and leaves no long-lived secret in the repository.
The action referenced throughout is the official
snowflakedb/snowflake-actions, pinned to a major tag. Each use case explains
which parts of it are used and which are deliberately bypassed.