You push a commit. CI runs for 8 minutes. Fails on 12 fixable ESLint errors. You fix them. Push again. Wait 8 more minutes. Quick Gate auto-fixes lint and type errors in CI — up to 3 attempts, 150-line patches, 20-min cap. If it fixes everything, the build passes. If it can't, it fails with a diff showing what it tried. npm install -g quick-gate Not replacing your linter. Just the part where you manually fix errors a machine could fix. Apache 2.0.

Framer — Launch websites with enterprise needs at startup speeds.

Launch websites with enterprise needs at startup speeds.

Hey Product Hunt! I built Quick Gate after one too many late-night CI failures on errors that eslint --fix would have solved in 3 seconds. The idea: instead of failing immediately on lint or type errors, try to fix them first. Deterministic fixes only (eslint --fix, scoped to your changed files). If it works, build passes. If not, you get a structured diff showing exactly what failed and what it tried — not just "exit code 1." The bounds are aggressive on purpose: 3 attempts, 150-line patch budget, 20-minute cap. Unbounded auto-fix loops are how you get CI silently mangling code for an hour. Why not lint-staged or Husky? Those run on your machine pre-commit. Quick Gate runs in CI — for repos where not everyone has hooks set up, or where a merge introduces new violations. npm install -g quick-gate Apache 2.0. Would love feedback on whether the retry bounds feel right for your codebase.

Framer — Launch websites with enterprise needs at startup speeds.

Launch websites with enterprise needs at startup speeds.

QuickGate-JS

Auto-fix Typescript/ESLint errors before CI fails the build

Auto-fix Typescript/ESLint errors before CI fails the build