Skip to content
Weave ChecksOpen source

Ship the code.
Skip the slop.

Weave Checks reviews pull requests against your team’s standards. Write a rule in Markdown. Let the check do the reminding.

Get started on GitHubTake a check for a spin
Your rules. Your repo. Every pull request.

Tell me why. Not what.

Flag comments that repeat the code. Keep the ones that explain a decision, a constraint, or a surprising detail.

src/users.tsNew commit
! Flagged code
Flagged: // Get the user's full nameexport function getFullName(user: User) {  return `${user.first} ${user.last}`;}
weave-checksFinding

The function already says this. Remove the comment—it adds a line, not information.

1 / 3Finding
An automatic walkthrough, not a live review. You or your agent make the fix.See a real review
The other half of code review

“It works” is
a pretty low bar.

Your bug reviewer asks

“Will this break?”

Check behavior and correctness.

Weave Checks asks

“Does this belong?”

Check conventions and code quality.

Keep your bug reviewer. Add checks for the standards you’re tired of repeating.

Opinionated. In your own way.

Your codebase.
Your house rules.

One Markdown file. One standard worth keeping.

Explore the check library
documentation-signal.md.md
---
name: Documentation Signal
description: Keep comments worth reading
intelligence: low
---

Flag comments that only repeat the code.

Keep the why:
- Non-obvious constraints
- Decisions and trade-offs
- Context the code can’t tell you
Lives in your repo.Belongs to your team.
Yep. That’s the whole check.
Showing the Documentation Signal Markdown example.
A few rules to get you thinking

Familiar code-review conversations?

All starter checks

Names that say something

What is data2, anyway?

Code with a reason to exist

“We might need it” isn’t a caller.

Defenses that make sense

Does this case actually happen?

Fewer homemade wheels

There’s a platform API for that.

Less ceremony. More checking.

Make it part
of your next PR.

Runs in GitHub Actions. Works with Weave Router or your own Anthropic-compatible provider.

Catch it before you push.

Already have checks in your repo? Run them locally, too.

Full setup instructions
  1. 1

    Install the GitHub App

    Choose which repositories Checks can review.

    Install app
  2. 2

    Give it a model

    Create a Router key and save it as the WEAVE_ROUTER_KEY repository secret.

    Create a key
  3. 3

    Add the workflow. Make the rules.

    Commit the GitHub Actions workflow. Add your own Markdown files in .weave-checks, or opt into the starter checks.

    Get the workflow
Before you let it into your repo

Fair questions.

Permissions & securityExample costs

It’s a complement, not a replacement. Bug reviewers look for defects. Checks focuses on the other half of code review: keeping the codebase consistent with your team’s principles. Use both.

No. It posts findings on the pull request. You or your coding agent make the fix; Checks can then resolve the comment thread. The interactive example above shows that sequence, not an automatic code edit.

Checks is open source under Apache-2.0. Model usage and any applicable GitHub Actions charges are separate. Use Weave Router or an Anthropic-compatible provider; cost depends on your checks, diffs, and chosen models.

Checks and Pull requests write access for reviews, plus Contents write to resolve review threads. The agent’s tools are read-only and it does not receive the App token. The action uses a short-lived, repository-scoped token and revokes it when the job finishes. Fork pull requests are skipped.

A little less “please fix this.”

Good code.
By your definition.

Pick one standard you care about.
Make it your first check.

Set up Weave ChecksOpen source. Apache-2.0. Yours to make better.
Built in the open. Take a look under the hood.