greggy/openclaw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
535875df8cdd49ffbdd3a6121983aa2e29c89072
openclaw/skills/gitea-dokumentation-closing/SKILL.md
OpenClaw f94cfb41e6 feat: pipeline improvements + remove deployment phase 
- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval
- Max 3 fix cycles, then pause and ask Martin
- KI self-review disclaimer in Code Review
- Removed Phase 7 (Deployment) entirely
- Renumbered: 7 phases instead of 9
- Updated all skills with new phase numbers
2026-05-10 20:37:13 +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: 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>)

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