Pr Review

Cursor-Regel mit festem Kriterienkatalog für konsistente, automatisierte PR-Reviews.

Original-Beschreibung der Autoren: Cursor rules for focused PR reviews with severity ranking, file and line citations, and separate review angles for security, performance, tests, and architecture.

Die Regel

---
description: "Cursor rules for focused PR reviews with severity ranking, file and line citations, and separate review angles for security, performance, tests, and architecture."
globs: **/*
alwaysApply: false
---
# PR Review — focused review prompts for Cursor

When the user asks you to review a pull request, set of changes, or "this PR", run the appropriate review angle from the four below. Pick based on the user's emphasis ("security", "perf", "tests", "arch"). If unspecified, ask which angle, or default to security.

Output discipline (applies to all angles):

- Cite file path and line number for each finding.
- Rank findings by severity: blocker, important, nit.
- Be specific. "This looks risky" is not a finding; "src/auth.ts:42 — JWT secret read from request body, see line 41" is.
- If the diff doesn't give you enough context to be sure, say so explicitly and ask for the surrounding file.
- End with a verdict on its own line: `Safe to merge | needs changes | reject`.

---

## Angle 1: SECURITY

You are reviewing the PR for security defects. Focus, in order of priority:

1. **Auth/authz** — new endpoints or branches missing auth checks, role assumptions, IDOR
2. **Input validation** — untrusted input flowing into queries, shell, file paths, deserialization, eval
3. **Injection** — SQL, NoSQL, command, prompt injection, template injection
4. **Secrets** — hardcoded keys/tokens, secrets in logs, secrets in client-bundled code, .env committed
5. **Output encoding** — XSS via unescaped templating, HTML in user content, JSONP-style leaks
6. **Crypto/randomness** — Math.random for tokens, MD5/SHA1, missing IVs, custom-rolled crypto
7. **Data exposure** — PII in logs, overshared API responses, missing redaction

Skip nice-to-haves. Stick to defects.

---

## Angle 2: PERFORMANCE

You are reviewing for performance regressions. Focus:

1. **N+1 patterns** — loops doing DB/network calls per item without batching
2. **Hot-path allocations** — new objects/arrays/maps inside loops, regexes recompiled per call
3. **Unbounded work** — pagination missing, results sets unconstrained, recursion without depth cap
4. **Bad async** — sequential awaits where Promise.all is correct, missing concurrency limits
5. **Cache misuse** — cache keys that don't include the right variables, cache TTLs absent or pathological
6. **Algorithm complexity** — O(n^2) hidden in `.some` over `.map`, sort inside loops

Quote the specific line, name the complexity or the bad pattern, suggest the fix.

---

## Angle 3: TESTS

You are reviewing the test coverage on this PR. Focus:

1. **Tests for new code paths** — every new branch should have at least one test
2. **Edge cases** — empty input, null/undefined, boundary values, errors thrown by deps
3. **Assertion strength** — assertions that pass with the wrong value, snapshot-only tests, tests that only check the happy path
4. **Mocking discipline** — mocks that don't fail when the real interface changes, over-mocking
5. **Determinism** — date/time/random/network not stubbed, leading to flakes
6. **Test names** — names that don't describe behavior

A test that exists is not the same as a test that catches regressions. Read the assertions, not the test name.

---

## Angle 4: ARCHITECTURE

You are reviewing the *shape* of the change. Pull back from line-level concerns:

1. **Boundary drift** — where did the seam between layers move? Did UI start reaching into DB? Did domain types start importing transport types?
2. **Premature abstraction** — interfaces, factories, or config layers with only one implementation. These are debt.
3. **Coupling** — utilities now importing from feature modules, shared mutable state being introduced
4. **Scalability** — if this code path goes 10x, what breaks first?
5. **Reversibility** — if this turns out wrong in a month, how hard is the rollback? One-way doors should be called out.
6. **Naming** — types/functions named for the implementation (`UserManagerImplV2`) rather than the role (`UserDirectory`).

End with: `Architecturally sound | needs trim | re-think before merging`.

---

Pair these prompts with full file context for best results. If the user has only pasted a diff and not the surrounding file, ask for the full file — diffs alone routinely miss bugs that live two lines outside the change. The companion CLI [prpack](https://github.com/Lucas2944/prpack) automates this.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Regel gibt der KI einen festen Kriterienkatalog an die Hand, nach dem Pull Requests bewertet werden – etwa Codequalität, Testabdeckung oder Konsistenz mit bestehenden Konventionen. Dadurch werden automatisierte Reviews vergleichbarer und weniger willkürlich, weil nicht jedes Mal neu entschieden wird, worauf zu achten ist. Nützlich für Teams, die KI-gestützte Reviews als erste Prüfstufe vor dem menschlichen Review einsetzen wollen, um offensichtliche Probleme früh abzufangen. Ersetzt kein menschliches Review bei komplexen fachlichen Entscheidungen, sorgt aber für gleichbleibende Mindeststandards bei jedem PR.

Praxis-Tipp

Lassen Sie die KI vor dem eigentlichen menschlichen Review kurz „Review diesen PR nach den Standardkriterien“ laufen, um Stil- und Konsistenzfehler früh abzufangen.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …