openclaw/skills/gitea-implementierung/SKILL.md

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
• Repo geklont in /tmp/<repo> oder Arbeitsverzeichnis
• Issue hat Label KI + ReadyForDev

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

Feature Branch erstellen

• Immer vom aktuellen main Branch starten:

git checkout main && git pull
git checkout -b feature/issue-<number>-<short-description>

• Branch-Naming: feature/issue-<number>-<short-description>
• Repo klonen falls nötig: git clone https://git.home.kies-media.de/<owner>/<repo>.git /tmp/<repo>

Main-Branch Rebase

Bevor mit der Implementierung begonnen wird, prüfen ob sich main geändert hat:

git fetch origin
git log --oneline HEAD..origin/main

Falls main neue Commits hat:

git rebase origin/main

Bei Konflikten: Auflösen, dann git rebase --continue. Bei komplexen Konflikten Martin informieren.

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

Code-Quality-Gates (PFLICHT vor jedem Commit)

Schritt 1: Projekt-Linting (PFLICHT – Abbruch bei Fehlern)

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      # oder: npx eslint .
python -m flake8 .

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

Schritt 2: Dependency-Audit

npm audit --audit-level=moderate  # Node.js
pip audit                        # Python

Bei Critical/High Vulnerabilities: nicht committen, Martin informieren.

Schritt 3: Formatter ausführen

npm run format    # oder: npx prettier --write .

Schritt 4: Build prüfen (falls vorhanden)

npm run build

Build muss erfolgreich sein.

Diese Schritte sind Pflicht – kein Commit und kein PR ohne erfolgreichen Durchlauf. Ausnahme: Wenn das Projekt keine entsprechenden Tools konfiguriert hat, Martin informieren.

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
• Label Implementing gesetzt (kumulativ)
• ⏩ Ü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
• API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren