A PR can pass tests and still miss your standards.
Keep your bug reviewer for defects. Use Weave Checks for rules specific to your repo.
Your bug reviewer asks
“Will this break?”
Logic errors, regressions, and edge cases.
Weave Checks asks
“Does this follow our standards?”
It flags vague names, dead code, and tests that don’t exercise the code.
Comments that repeat the code
Flag comments that restate what the code already says. Comments that explain a decision, a constraint, or something surprising are fine.
src/users.ts
! Flagged code
1!Flagged: // Get the user's full name2export function getFullName(user: User) {3 return `${user.first} ${user.last}`;4}
weave-checksFinding
This comment restates the function name. Remove it, or replace it with something the code can't tell the reader.
src/users.ts
− Removed+ Added
1−Removed: // Get the user's full name1export function getFullName(user: User) {2 return `${user.first} ${user.last}`;3}
weave-checksFix pushed
A new commit addresses the comment.
src/users.ts
1export function getFullName(user: User) {2 return `${user.first} ${user.last}`;3}
weave-checksThread resolved
The comment was removed. Resolving this thread.
An illustrated example, not a live review. You push the fix, or your coding agent does.See a real review
Each check is a Markdown file.
Frontmatter sets the name and model tier. The rest is plain English describing what to flag. Checks reviews each diff against it and comments on anything that breaks the rule.
---
name: Documentation Signal
description: Flags comments that repeat the code
intelligence: low
---
## What to look for
Comments that restate what the next line does.
## What not to flag
- Comments that explain a constraint or workaround
- Comments that explain why a decision was made
- Links to issues or specs
Showing the Documentation Signal Markdown example.
No. Bug reviewers look for defects. Checks flags the standards a teammate would point out in review, like naming, structure, and test quality. Run it alongside your bug reviewer.
No. It leaves review comments on the pull request. You or your coding agent push the fix, and Checks resolves the thread on its next run.
Checks is free and open source. You pay for model usage and any GitHub Actions minutes. Your cost depends on your checks, your diffs, and the models you choose.
Checks and Pull requests write access to post reviews, and Contents write to resolve review threads. The agent’s tools are read-only, and it never sees the App token. Each run uses a short-lived token scoped to the repository, which is revoked when the job finishes. Fork pull requests are skipped.
Start with one check.
Pick the review comment you leave most often and write it down as a check.