Perch: code review with repository-specific rules

Perch is a code-review tool built around rules a repository’s owners define. The official page gives examples such as keeping timestamps in UTC, storing money in integer cents and preventing password logging. Those rules run alongside the product’s defect and security checks on changed code.

Write an invariant the team can explain

Perch stores custom rules in a repository configuration file. Its site describes parsing code with tree-sitter, mapping callers and callees, then checking changed methods. A flagged issue can fail the check and receive a comment on the pull request.

The useful starting point is a small number of real invariants that reviewers already enforce. Choose a rule with a concrete example of a violation and an acceptable implementation. A broad instruction such as making all code secure is much harder to evaluate than a specific rule about where a credential may be logged.

Check the unconfigured baseline too

The product says it examines changed methods for defects and security issues even before custom rules are written. Its examples include unchecked empty values, weak hashing and missing authorization. It advertises support for several languages and integrations with coding assistants.

Those are product claims, not evidence that every defect will be found. Try the scanner on a known issue and a valid change, then inspect the comments for actionable locations and explanations. Keep human review responsible for context that the rule or scanner has not captured.

Separate billing estimates from results

The page quotes usage pricing per thousand rule checks and describes cached checks as free. Its typical pull-request cost is an estimate, so actual repository size and scan behaviour matter. Check the current pricing before connecting a large workflow.

Perch Cloud reviews GitHub pull requests; the open-source CLI can also run in GitLab CI. Teams should review the documented code-handling and retention policy for their deployment. A successful pilot should measure useful findings, incorrect flags and reviewer effort, rather than treating a passing check as proof that a change is safe.