HackerTrans
TopNewTrendsCommentsPastAskShowJobs

dkargatzis

no profile record

Submissions

Show HN: Turn .cursorrules / repo guidelines into GitHub pre-merge checks (OSS)

watchflow.dev
4 points·by dkargatzis·4 месяца назад·8 comments

comments

dkargatzis
·4 месяца назад·discuss
There is a preview environment that is currently free for both private and public repositories (at least for now). Early access also helps us expand the rule set and harden the core engine.
dkargatzis
·4 месяца назад·discuss
Great stuff, I just had a look at the langchain-ai, nextjs, and tailwindcss rulesets. I'll try them out in our internal repos.

As for your question, the evaluation loop has access to the PR diff and can identify the file paths affected by the change. Each rule in rules.yaml can specify a path or scope, so framework-specific checks only trigger when the relevant parts of the monorepo are touched.
dkargatzis
·4 месяца назад·discuss
Yes, both public and private. There is a guide with instructions in the repo.
dkargatzis
·4 месяца назад·discuss
Hi HN!

Maintainers are increasingly dealing with large volumes of low-context PRs, especially as AI coding tools make it easier to generate changes without the surrounding intent.

Many repos already define contribution expectations in places like .cursorrules, CONTRIBUTING.md, or internal guidelines but those rules rarely translate into something enforceable during review.

We built Watchflow to bridge that gap: an open-source GitHub check that translates repository guidelines into enforceable validation logic that runs on every PR.

The model is intentionally hybrid:

- ~95% deterministic validators (fast, predictable, pure Python)

- Optional LLM checks for semantic cases like description / diff alignment

- LLM layer fails open so merges never block on model issues

Example rules:

- Require a linked issue

- Require CODEOWNERS review

- Block PRs above a LOC threshold

- Ensure PR descriptions align with code changes

- Validate contribution patterns defined in .cursorrules or agent guidelines

The goal is to close the loop between repository intent -> code diff -> enforceable governance.

Repo: https://github.com/warestack/watchflow

If there are review patterns you’re seeing that aren’t covered yet, happy to turn them into new validators!
dkargatzis
·5 месяцев назад·discuss
A PR kill switch is tempting, but it also kills collaboration.

What we’re building instead looks at review-time signals rather than hard blocks. It surfaces why a PR is expensive to review:

- diff surface vs scope

- files touched vs CODEOWNERS boundaries

- changes on auth / validation / error-handling paths

- PRs that pass CI by mocking or bypassing real execution paths

Nothing is auto-rejected by default, the goal is to reduce low-context PRs before a maintainer has to reconstruct intent manually.

There’s a preview at https://watchflow.dev if you want to see how this behaves on real PRs. Open to feedback on which signals actually help in practice.