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

name, description

name	description
gitea-issue-resolver	Pipeline-Orchestrator für Gitea Issues. Koordiniert die 9 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 9 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"

Pipeline – 9 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

• Anforderungen analysieren
• Architektur entwerfen
• Spezifikation erstellen
• 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
• Review-Kommentare erstellen
• Output: APPROVED oder CHANGES_REQUESTED

Phase 4: Test- & QA-Agent → gitea-test-qa

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

Phase 5: Fix- & Refactoring-Agent → gitea-fix-refactoring (bei Bedarf)

• Review-Feedback umsetzen
• Bugs korrigieren
• Danach zurück zur jeweiligen Phase (Review oder QA)

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

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

Phase 7: Deployment-Agent → gitea-deployment

• Anwendungen deployen
• Health Checks
• Bei Problemen: Rollback

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

• Anforderungen validieren
• Akzeptanzkriterien abhaken
• Output: ACCEPTED oder REJECTED

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

• Dokumentation erstellen
• Issue schließen
• Abschlussbericht

Pipeline-Fluss

Issue (KI + ReadyForDev)
  │
  ▼
[1] Analyse & Architektur
  │
  ▼
[2] Implementierung
  │
  ▼
[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
  │ APPROVED
  ▼
[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
  │ PASS
  ▼
[6] Merge & Release ( wartet auf Martins Freigabe )
  │
  ▼
[7] Deployment
  │
  ▼
[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
  │ ACCEPTED
  ▼
[9] Dokumentation & Closing → Issue geschlossen ✅

Orchestrierung

Für jedes Issue:

1. Spezifikations-Verzeichnis erstellen: mkdir -p memory/gitea-specs
2. Phasen sequenziell durchlaufen
3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
4. Martin bei wichtigen Meilensteinen informieren:
   • Spezifikation fertig (Phase 1)
   • PR erstellt (Phase 6)
   • Deployment erfolgreich (Phase 7)
   • Issue geschlossen (Phase 9)

Regeln

• Nur Issues mit Tags KI + ReadyForDev
• Nie ohne Martins Freigabe mergen
• Nie Issue selbst schließen (nur Phase 9 darf das)
• Nie direkt auf main pushen
• Bei Blockern: sofort Martin informieren