Blazej Zak

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.

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.