greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d57e6f0418b9baddc1f6ed503c7617a3b697a811
openclaw/skills/gitea-dokumentation-closing/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

3.0 KiB
Raw Blame History

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: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.

Eingang

  • Validierungsbericht: ACCEPTED
  • Spezifikation: memory/gitea-specs/issue-<number>.md
  • Review, QA-Reports
  • Deployte und validierte Lösung

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-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 (Zeit/Commits/Reviews)
  • 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>)

Ausgang

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

Regeln

  • Kein Ticket ohne abschließenden Kommentar schließen
  • Dokumentation so, dass ein neuer Entwickler den Kontext versteht
  • Bei wichtigen Learnings: MEMORY.md updaten