Problem to Fix
The review agent always forces a CRITICAL finding when the pull request touches sensitive areas (authentication, payments, secrets handling, production configuration, destructive operations). This is the right default, but some projects either have no such concerns (e.g. documentation-only repos, tooling repos) or want a stricter or different set of triggers (e.g. add "database migrations" to the list).
Why it Matters
A blanket always-on rule is correct for most projects but creates friction for projects where it doesn't apply, and it under-serves projects that want a customized trigger list. Making it configurable lets each project tune the gate without editing the generated review-agent prompt directly.
General Approach
Add a per-project configuration knob in the project's settings file that controls (a) whether the "force CRITICAL on sensitive areas" rule applies at all and (b) the list of sensitive area categories the reviewer should watch for. Default to the current always-on behavior with the current category list so existing projects are unaffected. The reviewer prompt template would render the rule conditionally based on the configured value.
Complexity
Verification / QA effort: moderate
Touches the config schema, the reviewer prompt template, and the generated reviewer prompt. Needs verification across all four adapters that the rule is rendered correctly when on, off, or customized.
Acceptance Criteria
- A project can disable the "force CRITICAL on sensitive areas" rule via configuration.
- A project can customize the list of sensitive area categories.
- The default configuration matches the current always-on behavior with the same category list.
- The configuration is documented in the setup skill or its equivalent.
Parent story
Follow-up to #170 — deferred during the implementation of tiered review outcomes to keep #170 focused. Original proposal in PR discussion preferred always-on for now; this ticket captures the eventual configurability work.
Problem to Fix
The review agent always forces a CRITICAL finding when the pull request touches sensitive areas (authentication, payments, secrets handling, production configuration, destructive operations). This is the right default, but some projects either have no such concerns (e.g. documentation-only repos, tooling repos) or want a stricter or different set of triggers (e.g. add "database migrations" to the list).
Why it Matters
A blanket always-on rule is correct for most projects but creates friction for projects where it doesn't apply, and it under-serves projects that want a customized trigger list. Making it configurable lets each project tune the gate without editing the generated review-agent prompt directly.
General Approach
Add a per-project configuration knob in the project's settings file that controls (a) whether the "force CRITICAL on sensitive areas" rule applies at all and (b) the list of sensitive area categories the reviewer should watch for. Default to the current always-on behavior with the current category list so existing projects are unaffected. The reviewer prompt template would render the rule conditionally based on the configured value.
Complexity
Verification / QA effort: moderate
Touches the config schema, the reviewer prompt template, and the generated reviewer prompt. Needs verification across all four adapters that the rule is rendered correctly when on, off, or customized.
Acceptance Criteria
Parent story
Follow-up to #170 — deferred during the implementation of tiered review outcomes to keep #170 focused. Original proposal in PR discussion preferred always-on for now; this ticket captures the eventual configurability work.