| name | ci-testbed |
| description | Diagnose a CI failure locally instead of re-pushing to the runner. Use when CI is red but tests pass locally, a check is green on your machine yet fails in CI, or you're about to iterate on a hosted runner to find a failing test — reproduce the CI environment on this machine and name the failure in one local run. |
| role | tool-workflow |
CI Testbed
Reproduce a CI failure on this machine so the failing test is found in one local
run, not a dozen slow runner cycles. Re-pushing to a hosted runner to see the
next error wastes minutes per iteration and hides the failure behind compact
output — reproduce the CI environment locally instead.
Use when CI is red but the suite passes in your normal checkout, a check is green
on your machine yet fails on the runner, or you're about to push-to-see-the-error.
First safe action
Run the mechanical CI-repro setup, then read the diagnosis technique:
bun run skills/ci-testbed/scripts/ci-repro.ts --ref origin/main --test "<test glob>"
It builds a fresh worktree off the CI base ref, runs a real
bun install --frozen-lockfile, sets CI=true, and runs the target tests with a
failure-naming reporter — the four things a hosted runner does that a warm
local checkout does not. The named failing test is the output.
Then read references/ci-diagnosis.md for the trap catalogue (why a green local
suite goes red in CI) and how to gate the specific cause.
Invariants (fail closed)
- A bare git worktree has NO
node_modules. Workspace-package imports fail
there (Cannot find module @side-quest/...) and read as a phantom regression.
Always in the repro worktree before trusting any result — a red
worktree without an install proves nothing.
