Automate pull request review checks in GitHub Actions

Pull request review should not depend on whoever happens to be online when a branch opens. Automating review checks in GitHub Actions gives every PR the same deterministic scan: rule-backed findings on the diff, inline comments where authors already look, and optional merge gates when severity crosses your bar. Critiq ships that path as open source through critiq-dev/critiq-action and the same @critiq/cli engine you run locally.

This guide covers what to automate on pull_request, how the Action maps findings to GitHub review comments, and how to tune noise without turning the check off. If you have not installed the CLI yet, start with the OSS product page at https://critiq.dev/products/oss, then wire CI using the GitHub Actions integration at https://critiq.dev/integrations/github-actions.

What PR automation should guarantee

Automated pull request review checks should behave like infrastructure, not like a chatbot. Every run should use the same catalog version, scan the same diff scope, and emit findings with stable rule IDs your team can look up. Authors should see feedback on changed lines before merge policy blocks them, and reruns should not spam duplicate threads when nothing material changed.

• Diff-scoped scan on base and head SHAs so comments land on lines in the PR patch
• Inline review comments with rule id, severity, and remediation from the catalog
• Optional fail-on-severity so high findings fail the job without hiding context
• Dedupe across pushes so resolved threads stay resolved

Minimal GitHub Actions workflow for PR checks

Add .github/workflows/critiq.yml at the repository root. Checkout needs full history for diff mode; the job needs pull-requests: write when you post inline comments.

name: Critiq PR review

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Run Critiq
        uses: critiq-dev/critiq-action@v1
        with:
          comment-mode: inline
          fail-on-severity: high

Open a pull request and confirm the workflow on the Actions tab. With defaults, critiq check runs against the PR diff, posts inline comments for findings on changed lines, and fails the job when any high or critical finding is present. Pin @v1 or a commit SHA if your org requires supply-chain pinning.

Run the same check locally before you push

PR automation works best when local and CI agree. Run critiq check from the repo root before you open the PR so you fix findings with the same rule IDs reviewers will see on the diff.

npm install -D @critiq/cli @critiq/rules
npx @critiq/cli check .
critiq check --base origin/main --head HEAD .

The --base and --head flags mirror what critiq-action uses on pull_request. JSON output is useful for comparing runs across branches; the fields ruleId, severity, and location should match what lands in inline comments.

Tune comment mode and severity gates

comment-mode controls how findings reach GitHub. inline (default) posts one review comment per finding on diff lines. inline+summary adds a sticky issue comment with counts. off skips GitHub comments when you only need JSON or SARIF in a follow-up step.

fail-on-severity runs after scan and post. Start with off during adoption so authors learn the catalog without blocked merges, then raise the gate to high when the team trusts security and correctness rules. Severity order is low, medium, high, critical; each threshold includes that level and every more severe one.

      - name: Run Critiq
        uses: critiq-dev/critiq-action@v1
        with:
          comment-mode: inline+summary
          fail-on-severity: medium
          cli-version: "0.9.0"
          rules-version: "0.9.0"

Monorepos and reusable workflows

In a monorepo, set working-directory to the package root where dependencies install and target to the subtree the PR touches. That limits findings to the surface area authors actually changed.

Org-wide consistency is easier with the reusable workflow in critiq-action. Caller workflows stay small; you centralize checkout depth, permissions, and inputs once. Details and input reference: https://github.com/critiq-dev/critiq-action

jobs:
  review:
    uses: critiq-dev/critiq-action/.github/workflows/reusable-critiq.yml@v1
    secrets: inherit

Separate secrets from code review checks

critiq-action runs critiq check, not critiq audit secrets. If credential-shaped literals must block merge, add a dedicated audit secrets step or workflow. Do not assume the check exit code alone enforces secrets policy.

npx @critiq/cli audit secrets .

Next steps

• GitHub Action repo, https://github.com/critiq-dev/critiq-action
• Inline comments and dedupe guide, /blog/inline-pr-comments-dedupe-severity
• OSS CLI and rules, https://critiq.dev/products/oss
• GitHub Actions integration, https://critiq.dev/integrations/github-actions

Start with inline comments and a conservative severity gate, watch a few PRs for signal, then tighten policy when the catalog earns trust. Automated pull request review checks should feel like a teammate who always cites the rule, not a bot that nags without evidence.