Turn Review Feedback into Repository Rules
When teams repeatedly correct coding agents, this tool turns review and rollback history into testable repository rules that prevent the same mistakes from being generated again.
Once teams begin having coding agents write patches, reviewers often repeat the same feedback: use the internal wrapper, do not modify a particular directory, or add a specific test for every new interface. The product sits between code review and agent tasks, reading accepted, revised, and reverted machine-generated patches alongside their review comments. It grounds feedback in specific files, calling patterns, and test requirements instead of pasting entire comments back into a prompt.
The system first proposes candidate rules, such as “payment modules must not access the database directly” or “new HTTP routes must include authorization tests.” Each rule is replayed against historical patches, showing which mistakes it would have caught and which legitimate changes it might have blocked. Maintainers can revise the applicable directories, add exceptions, or decline to promote a comment into a repository constraint.
Rules that pass replay are compiled into the next agent task. If a patch in progress violates a constraint, the product identifies the team precedent it broke and provides an approved wrapper or test example. The review page also shows how much rework a rule has actually reduced, helping teams retire stale constraints. An early version would support GitHub pull requests and a single repository, focusing on rules that can be consistently inferred from revisions and reverts.
Why now
As observed on August 28, GitNexus (Akon Labs) ranked No. 11 in Product Hunt’s new-product feed and positions itself around an open-source coding-agent kernel. S1 As teams bring this kind of infrastructure into everyday development, repeated reviews and reverts become a more immediate workflow burden.
Target user
Small platform and infrastructure teams, along with codebase maintainers, that already have coding agents continuously submitting PRs. The trigger is when the same review feedback keeps appearing in machine-generated patches, or a rollback exposes an architectural constraint that was never documented. At that point, maintainers remember the concrete cost and can judge whether a candidate rule reflects team precedent, making them more willing to define exceptions and accept the configuration work.
Minimal entry point
Connect a single repository through a GitHub App and subscribe to pull request, review, and comment events. GitHub’s API can provide review status, body text, commit versions, and line-level comments. S2 The service stores each patch iteration and links it to subsequent changes to the relevant code. It first generates candidate rules from paths, call relationships, and test-file changes, then uses Tree-sitter for structural matching in a limited set of languages. Replay initially covers only high-confidence rules, such as bans on direct dependencies or required companion tests. Once approved, rules are exported as AGENTS.md or path-specific instruction files. S3 The first version does not promise to understand every natural-language comment or automatically merge rules without maintainer confirmation.
Punching above its weight
Start with small engineering teams that publicly use coding agents and have visible PR rework. Open-source a read-only repository scanner that produces a recurring-review-feedback report with reproducible evidence from historical patches. Then route trials through the GitHub App installation page, where maintainers can select a candidate rule and replay it directly. Publicly showing how false positives are corrected will earn more technical trust than generic claims about reducing rework.
Competitors & gaps
- GreptileGoogle
- Greptile already supports custom rules, style guides, and repository context, with rules scoped by repository and file path. It also learns from developers’ PR comments, replies, and reactions. When a rule fires, it can comment in a review, and its MCP can return related comments. S4 That makes “learning rules from reviews” alone a weak differentiator. The opening here should narrow to three things: treat revised or reverted machine-generated patches as the primary evidence; replay candidate rules against historical patches to show both catches and false positives; then compile approved rules into the next generation task rather than merely flagging them after a PR is complete. Teams need to trace each rule back to its source changes and validate exceptions. If replay results are not more controllable than existing learning features, users have little reason to switch.
- GitHub Copilot Custom InstructionsGoogle
- GitHub Copilot code review already supports repository-level instructions, path-specific instruction files, and AGENTS.md for additional repository context. S3 Teams can directly document architectural constraints, testing requirements, and review standards, then give generation and review the same context. Its advantage is that no separate control plane is needed, and rules can live with the code version. The adjacent opening is in how rules are created and validated: maintainers still have to spot recurring feedback and manually turn it into precise instructions. This product could automatically connect comments to later revisions and reverts, then propose evidence-backed candidate rules. Before an instruction file is committed, it should also replay the rule against historical patches and list false-positive cases. If it ultimately only drafts an instruction file, Copilot’s built-in capabilities will quickly absorb its value.
How it makes money
Charge a monthly fee per active repository, including rule extraction, historical replay, and pre-generation checks. Start with fixed usage caps so early pricing does not depend on hard-to-explain model-call counts.
The case against
Incorrect attribution can promote a one-off review preference into a lasting constraint that repeatedly blocks valid changes. Reducing those false positives requires an evidence chain connecting comments, original patches, revised patches, and reverts. Tracking code moves and rewrites across commits adds indexing and semantic-matching costs. Private code, review text, and agent records also require strict permission isolation. Rules that are too broad create noise, while rules that are too narrow are hard to reuse. If maintainers still need to rewrite and debug every rule, the rework saved may not justify the maintenance burden.