OpenShrike - agentic code reviewer

Hi Zain, yeah totally, that's the point - the rules live in your repo as markdown files so they are traceable, editable & tunable for the project. You can quick start though with ready made library of best practices to seed the rules for your repo.

Running this as a local self-review on the diff before it ever becomes a PR feels like the right place to catch boundary and best-practice issues. Can you define your own rules per repo?

Ohk I think this is genuinely useful specially the self hostable part because I personally use Code rabbit right now and I have no control over it plus I am on the mercy f them so I think it could be game changer for devs working on private projects

Thanks for your comment Thomas! I am glad that landed. Before you wire anything into CI, though, let me be straight about where the tool actually is: I'd hold off on CI for now. There's no GitHub Action yet - it's on the roadmap, but not shipped - and I don't want you to hit rough edges and conclude the idea doesn't work. Where I actually use it today is one step earlier: local self-review of an agent's work before I push. The agent writes the code, I run a scan locally, it catches the boundary/contract/best-practices stuff, I fix or push back, then it becomes a PR. So it's less "a gate in the pipeline" and more "a reviewer you run on the diff before anyone else sees it." Honestly that's the sweeter spot anyway - catch it before it's a PR, not after. Your questions still apply: - Gate vs. annotate: failing scans exit non-zero, so it's a hard signal by default; `shrike scan --no-ui` gives you the report without TUI - i've just pushed an update to make it less noisy. Annotate option should be an option for github action or CI integration feature. - Scoping: there's no separate path-config DSL - a check is a Markdown task handed to the agent, so you narrow it by editing the prose ("only the HTTP layer," "ignore generated code", "ignore everything outside {folder}/**"). Same reason you liked the criteria being diffable: the scope is too. Tradeoff is it's an instruction, not a hard glob filter. - On false-positive fatigue, which is the real killer: don't start with all 220 checks. Start with the baseline language policy of your project (~20 checks) and prune misfires by editing the Markdown or removing checks that don't apply to your repo. Running `shrike scan --scope full` will run the checks against whole repo - not just changes - and it will show you practices already violated so perhaps not applicable for the project - delete these from .openshrike/checks - Hint the tool burns quite a lot of tokens but since the checks are quite descriptive, the tool works well with smaller models like gpt-mini / haiku / qwen27B etc. Thanks again for the comment! Genuinely, try locally first. CI integration is coming.

The 'checks as version-controlled Markdown in the repo' choice is the part I like most — it makes the review criteria themselves diffable and reviewable, instead of opaque model judgment you can't audit. Two things I'd want to know before wiring it into CI: can a policy be scoped to specific paths (so a check only fires on the code it applies to), and on a 220-check set, is a failure blocking or annotation-only by default? False-positive fatigue is what kills these in practice, so the gate-vs-annotate knob matters a lot. Nice work — starring the repo.