Automated Standards Review on Every Pull Request

Mar 25, 2026

C65 LLC

The standards compliance linter shipped in Phase 2 can now run automatically on every pull request and post its findings as a structured comment — without any manual CI configuration from your team. Phase 3 ships the standards-review composite GitHub Action and installs the workflow into consumer projects during setup.

What gets checked

The PR review bot runs the full lint-standards.sh suite on every pull request. That includes:

Conventional Commits — verifies recent commit messages match type(scope): subject format.
Test directory — confirms a non-empty tests/, spec/, or __tests__/ directory exists.
Secret detection — scans source files for AWS keys, private key blocks, and hardcoded passwords.
Coverage configuration — checks that a coverage threshold is declared in CI or .standards.yml.
Language-specific checks — type annotations, banned functions, linter configs — activated by your .standards.yml language list.

See the linter blog post for the full check catalogue.

What it looks like on a PR

When the action runs it posts a comment with a summary line and a table of results:

## Standards Review

:x: 1 failure(s) found

| Status | Check | Details |
|--------|-------|---------|
| :white_check_mark: PASS | conventional-commits | All recent commits follow Conventional Commits format |
| :white_check_mark: PASS | no-secrets | No hardcoded secrets detected |
| :warning: WARN | test-directory | Test directory found but appears empty |
| :x: FAIL | python/banned-functions | eval() usage detected in src/utils.py |
| :white_check_mark: PASS | python/ruff-config | [tool.ruff] section configured in pyproject.toml |

---
*Generated by Coding Standards linter*

If any check returns FAIL, the action exits with a non-zero code and the workflow step is marked as failed — blocking merge when branch protection is configured.

How to install

Automatic (via setup.sh)

Running make setup (or the one-line curl installer) now copies the workflow template automatically:

curl -fsSL https://raw.githubusercontent.com/c65llc/coding-standards/main/install.sh | bash

This places .github/workflows/standards-review.yml in your project on first setup. The workflow references the composite action from the .standards/ submodule, so it stays in sync with the rest of your standards configuration.

Manual

Copy the template from the standards repository:

cp .standards/templates/standards-review.yml.example .github/workflows/standards-review.yml

Then grant the workflow permission to comment on pull requests by ensuring your repository’s Settings > Actions > General > Workflow permissions allows pull requests write access, or rely on the permissions block already present in the template.

SARIF integration for GitHub Code Scanning

The linter also supports --format sarif output (SARIF 2.1.0). You can extend the workflow to upload results to GitHub Code Scanning, which surfaces violations as inline annotations directly on the diff:

- name: Run standards linter (SARIF)
  run: |
    .standards/scripts/lint-standards.sh --format sarif > standards.sarif || true

- name: Upload SARIF to Code Scanning
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: standards.sarif

SARIF maps WARN checks to warning level and FAIL checks to error level in the Code Scanning UI. PASS results are omitted to keep the annotation list focused.

What’s next

Phase 4 adds --dry-run support and a make diff-standards target so you can preview what a standards sync would change before applying it.