Wir stellen vor: PR-Level-Regeln
Reviewen Sie den PR, nicht nur den Code

Wir freuen uns, PR-Level-Regeln vorzustellen — eine neue Kategorie von Regeln, die den gesamten Pull Request analysieren, nicht nur einzelne Dateien. Mit zwei neuen speziellen Tags, pr-level und git-history, können Sie jetzt die PR-Konventionen Ihres Teams automatisch durchsetzen.

Was ist neu

Traditionelles KI-Code-Review analysiert Dateien einzeln und prüft auf Bugs, Sicherheitsprobleme und Muster. Aber einige der wichtigsten Aspekte eines guten PRs sind in keiner einzelnen Datei zu finden:

Jetzt kann diffray all das überprüfen — automatisch, bei jedem PR.

Zwei neue Tags: pr-level und git-history

Wir haben zwei spezielle Tags hinzugefügt, die ändern, wie der KI-Agent Regeln verarbeitet:

Beispiel-Regeln, die Sie heute nutzen können

1. PR-Beschreibung muss das „Warum" erklären

Das häufigste Problem mit PRs: Sie listen auf, was geändert wurde, aber nicht warum. Reviewer können das Diff sehen — sie brauchen Kontext.

- id: pr_description_explain_why
  agent: general
  title: PR description should explain motivation
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Check if PR description explains the business reason
    - Verify it answers "Why is this change necessary?"
    - Look for context about the problem being solved
  tags:
    - pr-level
    - quality

2. Conventional Commit Messages

Setzen Sie konsistentes Commit-Format für automatisierte Changelogs und semantische Versionierung durch:

- id: commit_message_format
  agent: general
  title: Commit messages should follow conventional format
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Use git log --oneline to check recent commits
    - Verify commits follow type(scope): description format
    - Check for clear messages (not "fix stuff", "WIP")
  examples:
    bad: |
      fix stuff
      WIP
      update code
    good: |
      feat(auth): add OAuth2 login with Google
      fix(api): handle null response from payment service
  tags:
    - git-history
    - automation

3. Breaking Changes müssen dokumentiert sein

Nichts zerstört Vertrauen schneller als undokumentierte Breaking Changes, die in Produktion landen:

- id: breaking_changes_documented
  agent: general
  title: Breaking changes must be clearly documented
  importance: 9
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Check if changes modify public APIs or remove features
    - If breaking, verify commit messages include BREAKING CHANGE
    - Check for migration guide in PR description
  tags:
    - pr-level
    - git-history
    - breaking-changes

4. Single Responsibility PRs

PRs, die Features, Bug-Fixes und Refactoring mischen, sind unmöglich gut zu reviewen:

- id: pr_single_responsibility
  agent: general
  title: PR mixes unrelated changes
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Review changed files to identify distinct areas of change
    - Check if changes span multiple unrelated features
    - Flag if PR touches auth AND payment AND styling
  tags:
    - pr-level
    - quality

5. Ticket-Referenzen erforderlich

Für Nachverfolgbarkeit und Release Notes sollte jeder PR auf ein Issue verlinken:

- id: pr_ticket_reference
  agent: general
  title: PR should reference an issue or ticket
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Check commits for ticket references (PROJ-123, #123, ENG-456)
    - Look for issue URLs in commit messages
    - Only flag if NO commits have any ticket reference
  tags:
    - pr-level
    - git-history
    - traceability

Wie es unter der Haube funktioniert

Der general-Agent wurde mit speziellen Anweisungen für die Handhabung dieser Tags aktualisiert:

Regeln mit always_run: true werden bei jedem PR ausgeführt, unabhängig davon, welche Dateien geändert wurden. Das macht sie perfekt für PR-Level-Prüfungen, die nicht von bestimmten Dateimustern abhängen.

Erste Schritte

PR-Level-Regeln zu Ihrem Projekt hinzuzufügen ist einfach:

Wir haben Beispiel-Regeln in unserem project-specific-rules Repository veröffentlicht, die Sie kopieren und anpassen können.

Warum das wichtig ist

Gute PRs sind mehr als nur funktionierender Code. Sie sind Dokumentation für zukünftige Entwickler. Sie sind Audit-Trails für Compliance. Sie sind der Unterschied zwischen „was ist hier passiert?" und „ah, ich verstehe."

PR-Level-Regeln verwandeln Stammwissen in automatisierte Durchsetzung. Anstatt zu hoffen, dass jeder daran denkt, Tickets zu verlinken, Breaking Changes zu dokumentieren und aussagekräftige Beschreibungen zu schreiben — bekommen Sie konsistentes Feedback bei jedem PR.