developer-code-review-rules

Review pull requests by checking secret handling, injection boundaries, authentication and authorization, input contracts, and sensitive logging first. Report each confirmed issue with severity, file:line evidence, impact, and a fix sketch, and never reproduce any discovered secret value.

Start with recon: read the README, manifests, CI configuration, and existing docs to learn conventions and commands. Then route the audit across nine categories including correctness, security, performance, test risk, architecture, dependencies, and documentation, and present vetted findings in a prioritized table.

A complete finding includes a title with severity (P0-P3), precise file:line evidence, concrete impact, effort estimate (S/M/L), fix risk (LOW/MED/HIGH), confidence level, and a fix sketch. Low-confidence items become investigation tasks rather than asserted defects.

No. Blocking feedback must be tied to a concrete correctness or security failure with evidence. Style preferences, naming choices, and formatting nits should be labeled as non-blocking nits, and automated linters should handle them where possible.

Cite only the credential type and its file:line location, never reproduce the secret value itself. Recommend removing it from the codebase, rotating the credential, and loading it from protected configuration instead.

Do not use it as the primary guide for implementing approved refactors, writing PRDs, or product positioning and conversion copy work. It is scoped to code quality, test strategy, security hardening, and performance engineering review tasks.