Add Snyk vulnerability scanning

Create a Snyk account, copy the Snyk API token into a SNYK_TOKEN GitHub Actions secret, and add a Snyk workflow that runs on pull requests with an appropriate severity threshold.

Run Snyk across monorepo packages

For a monorepo, add separate Snyk steps for each package directory such as backend and frontend so vulnerable dependencies are detected in every package before merge.

Connect SonarQube Cloud

Create a SonarQube Cloud project for the repository, generate a SONAR_TOKEN, store it as a GitHub Actions secret, and add sonar-project.properties at the repo root.

Add the SonarQube GitHub Actions workflow

Add a workflow that checks out full git history, installs dependencies, runs tests with coverage, and executes SonarSource/sonarqube-scan-action so pull requests receive a Quality Gate result.

Enable Kilo Code Review

Create a Kilo account, install the KiloConnect GitHub App, select the repositories to review, and configure the Code Review Agent with model, review style, focus areas, max review time, and optional custom instructions.

Configure Dependabot limits

Add .github/dependabot.yml with one npm ecosystem entry per package directory, set open-pull-requests-limit to 1, and group related dependency updates where useful.

Require PR checks before merge

Configure branch protection rules so Snyk, SonarQube Cloud, and code review checks must pass before changes can merge into main or develop.

Article 3 of 3 in the CI/CD series: add dependency vulnerability scanning with Snyk, static analysis with SonarQube Cloud, AI code review with Kilo, and Dependabot configured so it does not flood your board.

How I Added Snyk, SonarQube Cloud, and Kilo Code Review to Every PR in My Monorepo

Install Husky, lint-staged, and commitlint

Add Husky, lint-staged, @commitlint/cli, and @commitlint/config-conventional at the monorepo root, then wire Husky with a prepare script so hooks are installed automatically after dependency installation.

Configure lint-staged for frontend and backend files

Add lint-staged rules that route backend TypeScript files to the backend ESLint and Prettier configs, and frontend TypeScript, JavaScript, JSX, and MJS files to the frontend configs.

Add a pre-commit hook for typecheck and linting

Create .husky/pre-commit to run frontend typecheck, backend typecheck, and pnpm exec lint-staged. If any command fails, the commit is blocked before it reaches the remote branch.

Enforce conventional commit messages

Create .husky/commit-msg with commitlint and add a .commitlintrc.json that limits commit types, allows flexible subject case, and caps the commit header length for readable history.

Add AI-focused ESLint guardrails

Enable rules such as no-console, @typescript-eslint/no-explicit-any, @typescript-eslint/no-floating-promises, @typescript-eslint/no-unused-vars, and no-return-await so predictable AI-generated TypeScript mistakes fail before commit.

Create GitHub Actions workflows for each app

Add backend and frontend workflow files that run on push and pull_request, use paths filters for the relevant app directories, and call a reusable CI workflow with working-directory, node-version, and pnpm-version inputs.

Add a pull request template

Create .github/pull_request_template.md with fields for change summary, test steps, screenshots or recordings, and a short checklist for human review items that automation cannot fully verify.

Require passing checks before merge

Configure the repository so the app-specific GitHub Actions status checks must pass before merging. The resulting gate blocks code that fails typecheck, lint, tests, or build.

A practical walkthrough of the Husky pre-commit hooks and GitHub Actions CI setup I built for my NestJS + Next.js monorepo: TypeScript typecheck, lint-staged, reusable workflows, and a PR template that actually enforces quality. Part 2 of a 3-part CI/CD series.

How to Add TypeCheck, Lint, Tests, and Build to Every PR with Husky and GitHub Actions

Install Testing Dependencies

Run npm install with Jest, ts-jest, testing libraries, and supertest. These provide the foundation for reliable unit and integration tests.

Configure Jest with 80% Coverage Thresholds

Create jest.config.ts with coverageThreshold set to 80% for branches, functions, lines, and statements. Use collectCoverageFrom to target source files and exclude tests and bootstrap code.

Add Test Scripts to package.json

Create test and test:coverage scripts that run Jest locally and in CI. This ensures coverage checks are enforced automatically.

Write Failing Tests First

Before asking AI for implementation, write a test that describes the behavior you want. Be specific about inputs, outputs, and edge cases.

Ask AI to Make Tests Pass

Show the failing test to the AI and ask it to write code that makes the test pass. The test becomes the specification the AI must satisfy.

Run Coverage Check and Merge

Execute test:coverage before merging. If coverage drops below 80%, the build fails. No override, no exceptions — the gate is automatic.

AI generates plausible code fast. Tests are the only signal that it's actually correct. Here's how to set up Jest, coverage thresholds, and CI gates before you touch a single line of AI-generated code.

Cicd

How I Added Snyk, SonarQube Cloud, and Kilo Code Review to Every PR in My Monorepo

How to Add TypeCheck, Lint, Tests, and Build to Every PR with Husky and GitHub Actions

Don't Write a Line of AI Code Until Your Tests Are Green