# Evals — github-actions

`cases.yaml` is a routing-and-capability spec, not an automated test runner. Read `should_trigger` / `should_not_trigger` as a judgement set: feed each prompt to the skill router and check it lands here for the trigger cases and routes to the named sibling (docker, git-workflow, ship, deployment, vercel) for the non-trigger cases — the non-obvious ones (caching by symptom, concurrency by symptom, OIDC instead of stored keys) are the ones worth watching. For `capability`, have the agent produce the hardened CI+deploy pipeline from the scenario and score it against the `must_include` rubric — every bullet should be present (SHA-pinned third-party actions, read-only default permissions, built-in cache, version matrix, gated OIDC deploy job, tuned concurrency). To sanity-check the artifact the skill emits, run `scripts/verify.sh <repo>` against a repo containing the generated workflows; it is read-only and exits non-zero only on a hard error.
