REVIEW RULES
Set a higher standard for every finding.
Use a clear review agreement: evidence, impact, a useful next step, and a human decision. These guidelines complement your existing checks.
Rule 1: Show a concrete failure path
A finding should identify the condition that triggers the issue, explain what the changed code does, and describe the observable effect. “This could be unsafe” is a starting question, not a complete review.
- Point to the relevant changed line or nearby context.
- Explain why an existing validation or authorization guard does not prevent the issue.
- Separate verified behavior from assumptions that still need checking.
Rule 2: Review the change in context
Check the pull request’s purpose and current revision. Consider intentional removals, expected errors, and boundaries enforced by callers. When context is missing, ask for it instead of inventing a requirement.
AntiCode’s hosted AI reviews use the selected diff. Do not assume they have read every file, your private specification, or all repository history.
Rule 3: Prioritize correctness before preference
Discuss security, incorrect results, broken behavior, and demonstrated performance regressions first. Keep formatting and naming debates in a separate convention checklist or formatter.
- Critical/high: investigate plausible severe impact promptly; validate before acting.
- Medium: assess affected users, conditions, and release scope.
- Low: useful refinements can be tracked without obscuring more consequential issues.
Rule 4: Keep sensitive values out of discussion
Do not reproduce live tokens, passwords, personal data, or customer records in comments and examples. If you find a real secret, follow your incident process and rotate it with the relevant provider. Deleting a line is not sufficient containment.
Rule 5: Test the proposed fix
A suggested change is advice. Verify the fix against the failure case, run the relevant existing tests, and check for a regression in neighboring behavior. Do not merge solely because the assistant returned no findings.
Rule 6: Record decisions without hiding evidence
Accept or dismiss findings with a reason in your team’s normal review conversation. Personal triage does not resolve another reviewer’s queue or change the source. Enterprise shared triage records team assignments and decisions separately, without claiming a fix was independently verified.
What AntiCode enforces today
The hosted service checks repository access, current revision identity, bounded inputs, complete AI output, and source references. Your saved severity threshold and excluded paths are personal display filters. They do not disable scanning or change a shared repository policy.
Repository administrators can configure supported review rules and path exclusions. Enterprise administrators can set shared remediation targets and scan-cadence indicators; these do not schedule scans or enforce merge gates. The following template is a human review agreement you can adopt; it is not an executable AntiCode configuration.
# Team review agreement
- Describe the user-visible intent of the change.
- Identify the trigger and impact of each suspected bug.
- Cite the current revision and relevant source location.
- Keep credentials and personal data out of examples.
- Test the fix and preserve human approval before merge.