Auto-detected checks
How your build, lint, typecheck and test commands are proposed, edited, and used as a hard ship floor.
Checks are your own build, lint, typecheck and test commands, run as gates on every ticket. They exist independently of the AI reviewer: a failing check blocks shipping no matter what the reviewer or verifier concluded.
Detection
Step 5 of the setup wizard inspects your repository and proposes commands based on what it finds:
| File | Ecosystem |
|---|---|
package.json scripts | Node.js / JavaScript / TypeScript |
pyproject.toml | Python |
composer.json | PHP |
go.mod | Go |
Cargo.toml | Rust |
pom.xml / build.gradle | Java / Kotlin |
Nothing here is fixed: edit any proposed command, or write your own from scratch, in Settings → Checks. Re-run detection or re-check the base branch any time from Project → Check base branch.
Beyond build, lint, typecheck and test
A few more gate types run automatically or are available to turn on:
- Secret scan: built in, no script of your own required. See Built-in secret scanner and protected paths.
- Stub scan: catches placeholder code (a stub left in place of a real implementation) instead of letting it pass as done.
- Dependency policy: flags new or changed dependencies that don't match your rules.
- Diff coverage (optional): requires the lines a ticket actually changed to be covered by tests, not just the file overall.
- Runtime smoke test (optional): starts the app or service to catch a runtime error that static checks alone would miss.
- Custom command gates: add any command you want run as a hard gate.
Why a failing check always blocks shipping
Checks are a deterministic floor, independent of the AI's own verdict. However confident the reviewer and verifier are that a ticket is satisfied, one failing check (a broken build, a red test, a lint error) vetoes shipping. Nothing overrides it, and nothing routes around it silently. This is the direct fix for "the agent said it shipped, but it's actually broken."