Strict Code Review
Review the current diff first. Inspect unchanged code only when it is necessary to establish the behavior of a changed path.
Prioritize:
- Correctness, regressions, state transitions, edge cases, concurrency, cleanup, compatibility, and performance.
- Security and privacy, especially plaintext persistence, sensitive logs, excessive permissions, clipboard data exposure, authentication reuse, and raw paths.
- Repository architecture, ownership, existing reusable modules, hard-coded values, dead code, and parallel old/new logic.
- Cross-platform behavior on macOS, Windows, Linux, iOS, Android, and HarmonyOS where the changed path applies.
- Missing or ineffective tests, including duplicated hand-written mocks where an established test helper exists.
For every finding:
- Cite the file and exact line.
- State the concrete trigger as input or state -> incorrect behavior.
- Explain why it matters and the smallest sound correction.
- Try to disprove the finding before retaining it.
Order findings by severity: blocking, important, optional. Do not report style preferences or speculative issues. If no real issue remains, say so clearly and note any residual verification gap.
End with one merge assessment: ready to merge, merge after fixes, redesign required, or insufficient evidence. Do not edit, commit, or push.
1---2name: review-strict3description: Perform a strict, evidence-based review of the current branch or working-tree changes without modifying files. Use when the user asks for a strict review, deep review, senior review, merge assessment, or explicitly invokes `$review-strict`.4---56# Strict Code Review78Review the current diff first. Inspect unchanged code only when it is necessary to establish the behavior of a changed path.910Prioritize:11121. Correctness, regressions, state transitions, edge cases, concurrency, cleanup, compatibility, and performance.132. Security and privacy, especially plaintext persistence, sensitive logs, excessive permissions, clipboard data exposure, authentication reuse, and raw paths.143. Repository architecture, ownership, existing reusable modules, hard-coded values, dead code, and parallel old/new logic.154. Cross-platform behavior on macOS, Windows, Linux, iOS, Android, and HarmonyOS where the changed path applies.165. Missing or ineffective tests, including duplicated hand-written mocks where an established test helper exists.1718For every finding:1920- Cite the file and exact line.21- State the concrete trigger as input or state -> incorrect behavior.22- Explain why it matters and the smallest sound correction.23- Try to disprove the finding before retaining it.2425Order findings by severity: blocking, important, optional. Do not report style preferences or speculative issues. If no real issue remains, say so clearly and note any residual verification gap.2627End with one merge assessment: ready to merge, merge after fixes, redesign required, or insufficient evidence. Do not edit, commit, or push.
uniclipboard