f94cfb41e6
- 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
101 lines
3.0 KiB
Markdown
101 lines
3.0 KiB
Markdown
---
|
||
name: gitea-dokumentation-closing
|
||
description: 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:
|
||
```bash
|
||
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
|