openclaw/skills/gitea-fix-refactoring/SKILL.md

name, description

name	description
gitea-fix-refactoring	Fix- & Refactoring-Agent für Gitea Issues. Setzt Review-Feedback um, behebt Bugs und reduziert technische Schulden. Teil der Gitea Issue Pipeline.

Fix- & Refactoring-Agent

Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünschen oder nach QA-Testfehlern.

Eingang

• Feature Branch mit Änderungswünschen
• Review-Kommentare: memory/gitea-specs/issue-<number>-review.md (CHANGES_REQUESTED)
• oder QA-Report: memory/gitea-specs/issue-<number>-qa.md (FAIL)
• Zyklus-Counter (wie oft bereits Fix → Review/QA durchlaufen)

Zyklus-Limit

Maximal 3 Fix-Zyklen. Danach:

1. Fix-Zyklus abbrechen
2. Zusammenfassung erstellen was hängt:
   • Welche Probleme sind offen?
   • Woran scheitert es?
   • Was wurde schon versucht?
3. Martin informieren und auf seine Entscheidung warten:
   • Weitere 3 Zyklen genehmigen
   • Issue manuell übernehmen
   • Issue zurückstellen / schließen

Zyklus-Counter dokumentieren in memory/gitea-specs/issue-<number>-fix-cycles.md.

Aufgaben

Review-Feedback umsetzen

• Alle 🔴 Must-Fix Comments adressieren
• Alle 🟡 Should-Fix Comments prüfen und umsetzen
• Konstruktives Feedback priorisieren
• Nachvollziehbare Commits pro Fix

Bugs korrigieren

• Root Cause identifizieren
• Minimaler, korrekter Fix
• Regressionstest hinzufügen
• Keine neuen Bugs einführen

Technische Schulden reduzieren

• TODOs mit Issue-Referenz auflösen
• Workarounds durch saubere Lösungen ersetzen
• Veraltete Patterns modernisieren

Code vereinfachen

• Überflüssige Komplexität entfernen
• Verschachtelte Conditionals reduzieren
• Early Returns nutzen
• Helper-Methoden extrahieren

Legacy-Code modernisieren

• Veraltete APIs ersetzen
• Neue Sprachfeatures nutzen
• Patterns aktualisieren

Performance verbessern

• Identifizierte Bottlenecks beheben
• Ineffiziente Algorithmen ersetzen
• Caching einführen wo sinnvoll
• Datenbankabfragen optimieren

Sicherheitslücken schließen

• Review identifizierte Schwachstellen beheben
• Input Validation nachziehen
• Auth/Authz-Lücken schließen
• Dependencies aktualisieren bei Bedarf

Redundanzen entfernen

• Doppelten Code zusammenführen
• Unbenutzte Imports/Variablen entfernen
• Tote Code-Pfade eliminieren

Module entkoppeln

• Enge Kopplung reduzieren
• Interfaces nutzen
• Dependency Injection wo passend
• Seiteneffekte isolieren

Typisierung verbessern

• Strikte Typisierung wo möglich
• Generics sinnvoll einsetzen
• Type Guards für Runtime-Sicherheit

Refactorings dokumentieren

• Was wurde geändert und warum
• Breaking Changes kenntlich machen
• Migrationsschritte falls nötig

Ausgang

• Alle Fixes auf Feature Branch committet
• Änderungen dokumentiert
• Zyklus-Counter inkrementiert
• ⏩ Zurück an den Agent der das Feedback gegeben hat:
  • Bei Review-Feedback → Code-Review-Agent (Phase 3)
  • Bei QA-Fail → Test- & QA-Agent (Phase 4)
• Bei Zyklus > 3: ⏸ Pause + Martin informieren

Code-Quality-Gates (PFLICHT vor jedem Commit)

Vor JEDEM Commit müssen ALLE konfigurierten Linter erfolgreich durchlaufen. Falls ein Linter fehlschlägt: Commit abbrechen, Fehler beheben, dann erneut versuchen.

# PHP Syntax Check
find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"

# CSS Lint (stylelint)
npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input

# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"

# Projekt-spezifische Linter (falls vorhanden)
npm run lint

Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN Commit.

Regeln

• Ein Fix = ein Commit (atomic)
• Kein Refactoring ohne klaren Grund
• Bei Unsicherheit: Martin fragen
• Zyklus-Limit strikt einhalten – keine Endlosschleifen