openclaw/skills/gitea-issue-resolver/SKILL.md

name, description

name	description
gitea-issue-resolver	Pipeline-Orchestrator für Gitea Issues. Koordiniert die 7 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.

Gitea Issue Resolver – Pipeline Orchestrator

Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen.

Authentication

Use git credentials from ~/.git-credentials for API calls:

GIT_CREDS=$(grep git.home.kies-media.de ~/.git-credentials | head -1)
GIT_USER=$(echo "$GIT_CREDS" | sed -n 's|.*://\([^:]*\):.*|\1|p')
GIT_PASS=$(echo "$GIT_CREDS" | sed -n 's|.*://[^:]*:\([^@]*\)@.*|\1|p')

Gitea API token: $GITEA_TOKEN (in .bashrc):

GITEA_TOKEN="568841…2e34"

Complexity Gate

Phase 1 bewertet die Komplexität. Das bestimmt den Pipeline-Verlauf:

Komplexität	Pipeline
S (Small)	Phase 1 → 2 → 3 → 5 → 6 → 7 (überspringt QA)
M (Medium)	Phase 1 → 2 → 3 → 4 → 5 → 6 → 7 (volle Pipeline)
L (Large)	Phase 1 → Martin-Freigabe → 2 → 3 → 4 → 5 → 6 → 7 (Analyse muss freigegeben werden)

Pipeline – 7 Phasen

Issue-Filter

Phase 1 (Analyse) holt Issues nur mit Tag KI:

curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI" \
  -u "$GIT_USER:$GIT_PASS"

Ab Phase 2 (Implementierung) werden nur Issues mit beiden Tags KI + ReadyForDev weiterverarbeitet (wird von Phase 1 gesetzt).

Phase 1: Analyse- & Architektur-Agent → gitea-analyse-architektur

• Complexity Gate: S / M / L bewerten
• Anforderungen analysieren, Architektur entwerfen
• Spezifikation erstellen + ins Issue schreiben
• Tag ReadyForDev hinzufügen (bei L: erst nach Martins Freigabe)
• Output: memory/gitea-specs/issue-<number>.md

Phase 2: Implementierungs-Agent → gitea-implementierung

• Feature Branch erstellen
• Code schreiben
• Commits strukturieren
• Output: Code auf Feature Branch

Phase 3: Code-Review-Agent → gitea-code-review

• Codequalität & Sicherheit prüfen
• Self-Review (bei kritischen Änderungen: Martin bitten)
• Akzeptanzkriterien aus dem Issue prüfen und bei Erfüllung abhaken (- [ ] → - [x] via API)
• Review-Kommentare erstellen
• Output: APPROVED oder CHANGES_REQUESTED

Phase 4: Test- & QA-Agent → gitea-test-qa (übersprungen bei S)

• Unit-, Integration-, E2E-Tests
• QA-Report erstellen
• Output: PASS oder FAIL

Phase 4-fix: Fix- & Refactoring-Agent → gitea-fix-refactoring (bei Bedarf, max. 3 Zyklen)

• Review-Feedback umsetzen
• Bugs korrigieren
• Nach max. 3 Zyklen: Martin informieren
• Danach zurück zur jeweiligen Phase (Review oder QA)

Phase 5: Merge- & Release-Agent → gitea-merge-release

• PR erstellen
• Release Notes & Versionierung
• Wartet auf Martins Freigabe

Phase 6: Abnahme- & Validierungs-Agent → gitea-abnahme-validierung

• Anforderungen validieren
• Akzeptanzkriterien abhaken + im Issue aktualisieren (- [x] via API)
• Bei ACCEPTED: Alle Akzeptanzkriterien MÜSSEN auf [x] stehen
• Output: ACCEPTED oder REJECTED

Phase 7: Dokumentations- & Closing-Agent → gitea-dokumentation-closing

• Dokumentation erstellen
• Issue schließen
• Abschlussbericht

Pipeline-Fluss

Issue (Label: KI)
  │
  ▼
[1] Analyse & Architektur ──→ Complexity: S / M / L
  │                              │          │         │
  │ (setzt ReadyForDev)          S          M         L → Martin freigeben
  │                              │          │              │
  ▼                              ▼          ▼              ▼
[2] Implementierung         ──────────────────────────────────
  │
  ▼
[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3]
  │ APPROVED              (max. 3 Zyklen, dann Martin fragen)
  │
  ├─ S ──────────────────────────────────→ [5] Merge & Release
  │
  ▼ (M, L)
[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
  │ PASS
  ▼
[5] Merge & Release (wartet auf Martins Freigabe)
  │
  ▼
[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
  │ ACCEPTED
  ▼
[7] Dokumentation & Closing → Issue geschlossen ✅

Orchestrierung

Grundsatz: IMMER alle Phasen durchlaufen

Die Pipeline muss immer von Phase 1 bis Phase 7 komplett durchlaufen werden. Der einzige Pause-Punkt ist Martins Merge-Freigabe in Phase 5. Nach dem Merge durch Martin MÜSSEN Phase 6 und 7 automatisch weiterlaufen.

Für jedes Issue:

1. Spezifikations-Verzeichnis erstellen: mkdir -p memory/gitea-specs
2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
4. Alle Phasen sequenziell ausführen, pausieren nur bei:
   • Komplexität L: Martin muss Analyse freigeben (vor Phase 2)
   • Phase 5: Martin muss PR freigeben/mergen
5. Nach Martins Merge: sofort Phase 6 (Abnahme) und Phase 7 (Closing) starten

Martin bei Meilensteinen informieren:

• Spezifikation fertig + Komplexität (Phase 1)
• PR erstellt (Phase 5)
• Issue geschlossen (Phase 7)
• Abhängigkeiten beachten: Vor Implementierung prüfen ob blockierende Issues bereits gemergt sind. Falls nicht: warten oder Martin informieren.

Regeln

• Phase 1 filtert auf nur KI
• Ab Phase 2: nur Issues mit KI + ReadyForDev
• Nie ohne Martins Freigabe mergen
• Nie Issue selbst schließen (nur Phase 7 darf das)
• Nie direkt auf main pushen
• Max. 3 Fix-Zyklen, dann Martin fragen
• Bei Blockern: sofort Martin informieren
• Immer Phase 1–7 komplett durchlaufen, kein vorzeitiger Abbruch
• Nach Martins Merge: Phase 6+7 automatisch starten
• Bei Subscription-Limit / Rate-Limit / Token-Limit: Sofort pausieren, Martin informieren. Nicht weiterarbeiten bis Martin grünes Licht gibt. Sub-Agenten ebenfalls stoppen.