principle-code-review

High-signal code review comments target correctness, security, design integrity, and test gaps while filtering out linter-owned nitpicks. You must provide concrete failure scenarios and use observation-based language to ensure feedback remains actionable and avoids speculative issues.

A real finding during a pull request review identifies a genuine issue across correctness, security, design integrity, or tests. It requires a named failure scenario and avoids formatting nitpicks or speculative feedback without concrete evidence of a potential failure.

Assess code correctness across edge cases and trust boundaries by applying a four-axis review lens. This requires defining concrete failure scenarios, establishing confidence thresholds based on severity, and filtering out speculative issues that lack evidence of actual failure.

Frame security auditing findings using observation-based language that reduces blame and improves clarity. Adjust how aggressively you comment based on severity and likelihood, requiring concrete failure scenarios to justify surfacing the security finding.

You should not surface a code review finding if it is a formatting or style nitpick, or if it is a speculative issue lacking a concrete failure scenario. Drop findings that do not meet confidence thresholds based on severity and likelihood.

Yes, principle-code-review evaluates test coverage and design integrity by applying a four-axis lens to code diffs. It assesses whether tests cover edge cases and whether the design maintains structural integrity while filtering out low-value feedback.