How PRCheck actually reviews code
PRCheck is not a linter and not a SAST scanner that runs weekly on your full codebase. It reads the PR diff, walks the AST, and posts findings inline before the first human reviewer looks.
AST-level diff: what PRCheck reads that linters skip
A linter reads a line. PRCheck reads a program. When your PR changes a function, PRCheck parses the abstract syntax tree of the modified files and traces the execution paths that changed. It understands call graphs, scope boundaries, and data flow across the diff.
That structural understanding is why PRCheck can explain why a specific change introduces a bug, not just flag that a line matches a pattern. A linter tells you a line looks wrong. PRCheck tells you the call path that leads to a null dereference three functions away from the changed line.
- Parses TypeScript, Python, Go, Java, Ruby, and more
- Traces cross-function data flow within the diff scope
- Understands control flow: branches, loops, async paths
- Generates human-readable explanations, not just codes
Logic errors, null dereferences, race conditions
PRCheck's bug engine traces execution paths through changed code to find logic errors that only appear under specific conditions. Not just missing null checks, but the path that leads to a null dereference in a function three calls away.
- Null and undefined dereference across call chains
- Race conditions in async/await and Promise chains
- Off-by-one and boundary errors in loops and slices
- Unreachable branches and dead code paths
- Type mismatches in dynamic languages
OWASP patterns, hardcoded secrets, SQL injection
Security findings are posted as inline review comments with severity badges (High/Medium) and a remediation note. No separate dashboard to check; the finding lands in the PR where the reviewer already is.
- OWASP Top 10 pattern library, updated quarterly
- Hardcoded secrets and credentials detection
- SQL injection in dynamic query construction
- Insecure deserialization and path traversal patterns
- Severity tagging with High/Medium classification
Beyond format: naming, complexity, architecture
Formatters handle indentation. PRCheck handles the rules formatters cannot express: naming conventions your team agreed on but never enforced consistently, cyclomatic complexity thresholds that flag functions growing too complex to reason about, and cross-module import constraints that keep your architecture from collapsing into a ball of dependencies. PRCheck is not a replacement for your formatter. Run both.
- Naming conventions by type, file, and module scope
- Cyclomatic complexity thresholds (configurable)
- Disallowed imports between modules (architectural rules)
- Max function length and parameter count
YAML rules your team writes and owns
Write rules in YAML, commit them to .prccheck/rules.yml in your repo, and PRCheck picks them up on the next scan. No dashboard step, no deploy. Rules travel with the code they govern. Regex rules are quick to write for text-pattern checks; AST matchers handle structural constraints that regex cannot express, like requiring every unhandled await to be wrapped in a try-catch.
- YAML format, committed alongside code
- Regex patterns for fast text-based rules
- AST matchers for structural rules
- Per-repo and org-level rule inheritance
Security: String interpolation in SQL query allows injection. Use parameterized queries.
HIGH