greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
db82c851b5216d95c014cdcda70aad8fc05949be
openclaw/skills/gitea-implementierung/SKILL.md
OpenClaw db82c851b5 feat: split gitea-issue-resolver into 9 specialized agent skills + orchestrator 
- gitea-analyse-architektur (Phase 1)
- gitea-implementierung (Phase 2)
- gitea-code-review (Phase 3)
- gitea-test-qa (Phase 4)
- gitea-fix-refactoring (Phase 5, on demand)
- gitea-merge-release (Phase 6)
- gitea-deployment (Phase 7)
- gitea-abnahme-validierung (Phase 8)
- gitea-dokumentation-closing (Phase 9)
- gitea-issue-resolver updated as pipeline orchestrator
- Only issues tagged KI + ReadyForDev are processed
2026-05-10 20:18:24 +00:00

2.7 KiB
Raw Blame History

name, description
name description
gitea-implementierung Implementierungs-Agent für Gitea Issues. Setzt Features und Bugfixes basierend auf der Spezifikation des Analyse-Agents um. Teil der Gitea Issue Pipeline.

Implementierungs-Agent

Rolle: Zweite Phase der Gitea Issue Pipeline. Setzt die Spezifikation in Code um.

Eingang

  • Spezifikationsdokument: memory/gitea-specs/issue-<number>.md
  • Feature Branch: feature/issue-<number>-<short-description>
  • Repo geklont in /tmp/<repo> oder Arbeitsverzeichnis

Aufgaben

Features implementieren

  • Spezifikation Schritt für Schritt umsetzen
  • Code modular und wartbar halten
  • Nur das implementieren, was in der Spezifikation steht (kein Scope Creep)

Bugs beheben

  • Ursache identifizieren (Root Cause Analysis)
  • Fix minimal aber korrekt halten
  • Nicht nur Symptome behandeln

Clean Code schreiben

  • Lesbarkeit über Cleverness
  • Aussagekräftige Variablen-/Funktionsnamen
  • Funktionen kurz und fokussiert
  • Kommentare für warum, nicht was

Bestehenden Code erweitern

  • Bestehende Patterns und Konventionen beachten
  • Keine unnötigen Refactorings im gleichen PR
  • Rückwärtskompatibilität wahren

Datenbankzugriffe implementieren

  • Prepared Statements / Parameterized Queries verwenden
  • Transaktionen wo nötig
  • Index-Nutzung berücksichtigen
  • N+1 Queries vermeiden

APIs integrieren

  • Fehlerbehandlung für externe Calls
  • Timeouts konfigurieren
  • Retry-Logik wo sinnvoll
  • Rate Limits respektieren

UI-Komponenten erstellen

  • Responsive Design beachten
  • Accessibility-Grundlagen einhalten
  • Bestehende Design-System-Komponenten nutzen

Logging integrieren

  • Strukturiertes Logging (JSON wo möglich)
  • Log-Level korrekt setzen (DEBUG/INFO/WARN/ERROR)
  • Keine sensiblen Daten loggen
  • Korrelations-IDs wo hilfreich

Fehlerbehandlung umsetzen

  • Errors niemals stillschweigend schlucken
  • User-freundliche Fehlermeldungen
  • Technische Details ins Logging, nicht in die UI
  • Globale Error-Handler nutzen

Performance optimieren

  • O(n²) vermeiden wo möglich
  • Caching wo sinnvoll
  • Lazy Loading nutzen
  • Große Datenmengen paginieren/streamen

Coding Standards einhalten

  • Linter-Regeln befolgen
  • Formatter nutzen (Prettier, Black, etc.)
  • Projekt-spezifische Konventionen respektieren

Commits strukturieren

  • Kleine, atomare Commits
  • Conventional Commits Format: type(scope): description
  • Fix-Referenz: Fix #<number>: <description>
  • Kein WIP-Commit am Ende – History clean halten

Ausgang

  • Implementierter Code auf Feature Branch
  • Alle Commits sauber strukturiert
  • Code bereit für Review
  • ⏩ Übergabe an Code-Review-Agent

Regeln

  • Keine Secrets/Credentials im Code
  • Keine TODOs zurücklassen (außer mit Issue-Referenz)
  • Bei Blockern sofort Martin informieren