greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f94cfb41e6b66ba2b45db6e2c44f838a2a1a348a
openclaw/skills/gitea-code-review/SKILL.md
OpenClaw f94cfb41e6 feat: pipeline improvements + remove deployment phase 
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval
- Max 3 fix cycles, then pause and ask Martin
- KI self-review disclaimer in Code Review
- Removed Phase 7 (Deployment) entirely
- Renumbered: 7 phases instead of 9
- Updated all skills with new phase numbers
2026-05-10 20:37:13 +00:00

3.4 KiB
Raw Blame History

name, description
name description
gitea-code-review Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherheit und Architekturkonformität. Teil der Gitea Issue Pipeline.

Code-Review-Agent

Rolle: Phase 3 der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.

Wichtiger Hinweis: KI reviewt KI

Dieser Agent führt ein Self-Review durch – die KI prüft ihren eigenen Code. Das ist besser als kein Review, aber kein echter Gatekeeper.

  • Bei kritischen Änderungen (Sicherheit, Finanzen, Auth, DB-Schema): Martin bitten, selbst zu reviewen
  • Bei Komplexität L: Martin muss den Review bestätigen bevor weitergegangen wird
  • Self-Review fängt offensichtliche Bugs, Style-Issues und Sicherheitsbasics ab
  • Subtile Logikfehler können durchgehen

Eingang

  • Feature Branch mit Implementierung
  • Spezifikationsdokument: memory/gitea-specs/issue-<number>.md

Aufgaben

Codequalität prüfen

  • Lesbarkeit und Verständlichkeit bewerten
  • Komplexität der Funktionen prüfen (Cyclomatic Complexity)
  • Duplication vermeiden (DRY)
  • SOLID-Prinzipien beachten
  • YAGNI – kein Over-Engineering

Sicherheitsprobleme erkennen

  • Input Validation auf allen Einstiegspunkten
  • SQL Injection / XSS / CSRF prüfen
  • Auth/Authz korrekt implementiert
  • Keine Secrets im Code
  • Dependency-Schwachstellen prüfen

Architekturkonformität prüfen

  • Entspricht die Umsetzung der Spezifikation?
  • Layer-Trennung eingehalten?
  • Abhängigkeiten in die richtige Richtung?
  • Keine zirkulären Abhängigkeiten

Duplikate identifizieren

  • Copy-Paste-Code erkennen
  • Gemeinsame Logik extrahierbar?
  • Bestehende Utility-Funktionen genutzt?

Lesbarkeit bewerten

  • Aussagekräftige Namen für Variablen, Funktionen, Klassen
  • Komplexe Logik kommentiert?
  • Funktionen nicht zu lang (>30 Zeilen = Warnung)

Naming-Konventionen prüfen

  • Projekt-Styleguide eingehalten
  • Konsistente Benennung throughout
  • Keine Abkürzungen ohne Notwendigkeit

Performanceprobleme erkennen

  • Ineffiziente Queries / Algorithmen
  • Unnötige Synchronisierung
  • Memory Leaks potenziell
  • Blocking Calls in async Kontext

Potenzielle Bugs finden

  • Off-by-One Errors
  • Null/Undefined Handling
  • Race Conditions
  • Exception Handling vollständig?
  • Edge Cases abgedeckt?

Testabdeckung bewerten

  • Sind kritische Pfade getestet?
  • Edge Cases in Tests abgedeckt?
  • Mocking korrekt eingesetzt?
  • Tests sind deterministisch?

Review-Kommentare erstellen

  • Konstruktiv und spezifisch formulieren
  • Code-Stellen mit Zeilennummern referenzieren
  • Schweregrad kennzeichnen: 🔴 Must-Fix / 🟡 Should-Fix / 🔵 Nitpick
  • Verbesserungsvorschläge mit Beispiel-Code

Merge-Freigaben erteilen

  • Alle 🔴 Must-Fix behoben?
  • Spezifikation vollständig umgesetzt?
  • Keine bekannten Sicherheitsprobleme?
  • → Freigabe erteilen oder Feedback an Implementierungs-Agent

Ausgang

  • Review-Ergebnis dokumentiert in memory/gitea-specs/issue-<number>-review.md
  • Status: APPROVED oder CHANGES_REQUESTED
  • Bei APPROVED:
    • Komplexität S: ⏩ direkte Übergabe an Merge- & Release-Agent (Phase 5)
    • Komplexität M/L: ⏩ Übergabe an Test- & QA-Agent (Phase 4)
  • Bei CHANGES_REQUESTED: ⏩ Übergabe an Fix- & Refactoring-Agent (Phase 4-fix)

Regeln

  • Immer konstruktiv – Review ist Hilfe, nicht Kritik
  • Keine stilistischen Nitpicks als Blocker
  • Sicherheitsprobleme sind immer 🔴 Must-Fix
  • Bei kritischen Änderungen: Martin zur Review-Bestätigung auffordern