skills/quality-gate/SKILL.md
Use when you need lint, typecheck, test, and build to pass before pushing, opening a PR, or merging. Also use when asked to run "checks", "quality gate", or "make sure everything is clean" before submission.
npx skillsauth add paulund/ai quality-gateInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Run lint → typecheck → test → build. Stop on first failure, diagnose, fix, and re-run.
Read package.json scripts (or composer.json, Makefile, Cargo.toml). Look for scripts named lint, typecheck / types, test, and build. Use pnpm if pnpm-lock.yaml exists, npm run otherwise. If a phase has no matching script, skip it.
<lint> && <typecheck> && <test> && <build>
Each must pass before the next runs.
git log, git blame, tests).Max 2 diagnose-fix cycles. If still failing, surface the failure — don't hide it.
On success: one-line summary listing phases that ran. On failure: failing phase, command that ran, and first ~20 lines of error output.
| Rationalization | Reality | |---|---| | "I don't need to run lint, I'll fix formatting later" | You'll fix it never. CI will fail. Run it now. | | "The tests pass in isolation, I don't need the full suite" | Missing integration failures is how production bugs ship. Run the full gate. | | "I'll skip typecheck, it takes too long" | Type errors caught in CI cost 10× more to fix than type errors caught locally. | | "The build is fine, I already tested it" | Build failures happen from environment drift, cache invalidation, and dependency changes. Trust the rebuild. | | "Just this once, I'll skip a phase" | One skipped phase becomes two, becomes all of them. Don't start. |
pnpm.development
Use when implementing any logic, fixing any bug, or changing any behaviour. Use when you need to prove code works, when a bug report arrives, or when modifying existing functionality. Do NOT use for config changes, data migrations, or dependency updates.
development
Use when starting a new feature, when requirements are unclear, when asked to write code without a clear spec, or before any non-trivial implementation. Do NOT use for trivial bug fixes or one-line changes.
development
Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. Detects the stack from dependency files, fetches official documentation, implements following documented patterns, and cites sources for every framework-specific decision.
development
Use when preparing to ship a feature, release, or deployment. Use before merging to main, creating a release, or deploying to production. Do NOT use for CI-only changes or internal refactors that don't reach production.