openclaw/skills/gitea-dokumentation-closing/SKILL.md

name, description

name	description
gitea-dokumentation-closing	Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumentation, pflegt das Wiki und schließt Tickets ab. Teil der Gitea Issue Pipeline.

Dokumentations- & Closing-Agent

Rolle: Phase 7 – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.

Eingang

• Validierungsbericht: ACCEPTED
• Spezifikation: memory/gitea-specs/issue-<number>.md
• Review, QA-Reports
• Gemergter und validierter Code

Aufgaben

Technische Dokumentation erstellen

• Architektur-Entscheidungen festhalten
• Komponenten und deren Zusammenspiel beschreiben
• Konfigurationsoptionen dokumentieren
• Troubleshooting-Guide falls hilfreich
• Im Repo oder Wiki speichern

API-Dokumentation pflegen

• Neue/Geänderte Endpoints dokumentieren
• Request/Response-Beispiele
• Auth-Requirements
• Fehlercodes und -bedeutungen
• OpenAPI/Swagger falls verwendet

Architektur dokumentieren

• System Context Diagram aktualisieren
• Komponentendiagramm aktualisieren
• Datenfluss beschreiben
• ADRs (Architecture Decision Records) bei wichtigen Entscheidungen

Changelogs ergänzen

• Änderung in CHANGELOG.md eingetragen
• User-facing Beschreibung
• Link zum Issue/PR
• Breaking Changes hervorgehoben

Betriebsdokumentation schreiben

• Deploy-/Start-Prozess beschrieben
• Umgebungsvariablen dokumentiert
• Backup/Restore-Verfahren
• Monitoring & Alerting
• Known Operations (Runbook)

Known Issues dokumentieren

• Bekannte Einschränkungen auflisten
• Workarounds beschreiben
• Folge-Issues erstellen falls nötig

Tickets aktualisieren

• Issue-Status auf closed setzen via API:

curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"state": "closed"}'

• Abschließender Kommentar im Issue mit Zusammenfassung
• Labels aktualisieren
• Verknüpfte PRs referenzieren

Entscheidungsprotokolle erstellen

• Wichtige Entscheidungen während des Prozesses
• Warum wurde welche Option gewählt?
• Welche Alternativen gab es?
• ADR ablegen falls relevant

Wissensdatenbank pflegen

• Neue Erkenntnisse in memory/ speichern
• Lessons Learned festhalten
• Best Practices aktualisieren
• MEMORY.md bei relevanten Learnings updaten

Abschlussberichte generieren

• Zusammenfassung des gesamten Issue-Lebenszyklus
• Was wurde gemacht, warum, mit welchem Ergebnis
• Aufwand (Commits/Reviews/Zyklen)
• In memory/gitea-specs/issue-<number>-final.md

Tickets schließen

• Issue schließen (siehe oben)
• Feature Branch löschen (optional, nach Martins Präferenz)
• Temporäre Dateien aufräumen (/tmp/<repo>)

Spec-Dateien aufräumen

Nach Abschluss:

• -final.md bleibt als Dauer-Doku
• Temporäre Specs (-review.md, -qa.md, -validation.md) nach 30 Tagen löschen
• Bei Komplexität S: Nur -final.md erstellen, keine temporären Specs

Komplexität S: Vereinfachter Closing-Flow

Bei S-Issues (Typos, Config, kleine Fixes):

• Kurze Zusammenfassung als Issue-Kommentar
• Issue schließen
• -final.md mit Minimal-Info (was, warum, PR-Link)
• Keine umfangreiche Doku, kein Runbook, kein ADR

Ausgang

• Issue geschlossen
• Dokumentation erstellt und gepflegt
• Abschlussbericht: memory/gitea-specs/issue-<number>-final.md
• Martin final informiert über Abschluss (inkl. Gesamtzeit der Umsetzung)

Zeit-Tracking

Jede Phase dokumentiert ihre Dauer. Im Abschlussbericht (-final.md) und in der Benachrichtigung an Martin wird die Gesamtzeit aller Phasen ausgewiesen:

• Phase 1 (Analyse): Dauer
• Phase 2 (Implementierung): Dauer
• Phase 3 (Review): Dauer
• Phase 4 (QA, falls vorhanden): Dauer
• Phase 5 (Merge/PR): Dauer
• Phase 6 (Abnahme): Dauer
• Phase 7 (Closing): Dauer
• Gesamtzeit: Summe

Regeln

• Kein Ticket ohne abschließenden Kommentar schließen
• Dokumentation so, dass ein neuer Entwickler den Kontext versteht
• Bei wichtigen Learnings: MEMORY.md updaten
• Feature Branch nach Merge im Remote löschen
• Temporäre Spec-Dateien nach 30 Tagen aufräumen