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

2.7 KiB
Raw Blame History

name, description
name description
gitea-abnahme-validierung Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforderungen, prüft Akzeptanzkriterien und führt Freigabetests durch. Teil der Gitea Issue Pipeline.

Abnahme- & Validierungs-Agent

Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst.

Eingang

  • Deployte Anwendung in Zielumgebung
  • Spezifikation: memory/gitea-specs/issue-<number>.md
  • Original-Issue von Gitea

Aufgaben

Anforderungen validieren

  • Jede Anforderung aus dem Issue durchgehen
  • Ist die Anforderung in der Lösung umgesetzt?
  • Löst die Lösung das im Issue beschriebene Problem?
  • Gap-Analyse: Fehlt etwas?

Akzeptanzkriterien prüfen

  • Jedes Akzeptanzkriterium einzeln abhaken
  • Bei UI: visuell überprüfen
  • Bei API: Requests manuell/automatisiert senden
  • Bei Daten: korrekte Speicherung und Abrufbarkeit prüfen

Nutzerflows testen

  • Reale Nutzer-Szenarien durchspielen
  • Happy Path + Alternative Paths
  • Abbruch-Szenarien
  • Workflow von Anfang bis Ende

Business-Logik verifizieren

  • Berechnungen korrekt?
  • Zustandsübergänge wie spezifiziert?
  • Berechtigungen wie gefordert?
  • Edge Cases im Business-Kontext

UI/UX bewerten

  • Layout korrekt und konsistent?
  • Fehlermeldungen verständlich?
  • Ladezeiten akzeptabel?
  • Mobile Darstellung falls relevant

Compliance prüfen

  • Datenschutzanforderungen erfüllt?
  • Audit-Trail wo gefordert?
  • Protokollierungsvorschriften eingehalten?
  • Lizenzpflichtige Dependencies dokumentiert?

Freigabetests durchführen

  • Endgültiger Smoke Test auf Production/Staging
  • Keine Regressions in bestehenden Features
  • Performance akzeptabel unter realen Bedingungen
  • Keine Error-Spikes in Monitoring

Stakeholder-Feedback auswerten

  • Falls Martin bereits getestet hat: Feedback einarbeiten
  • Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen)

Produktionsverhalten kontrollieren

  • Logs auf Unexpected Errors prüfen
  • Metriken stabil?
  • Keine Alarme ausgelöst?
  • Nutzer-Reports prüfen falls vorhanden

Release-Abnahme dokumentieren

  • Validierungsbericht in memory/gitea-specs/issue-<number>-validation.md
  • Ergebnis: ACCEPTED oder REJECTED
  • Bei ACCEPTED: Freigabe für Dokumentation
  • Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent

Ausgang

  • Validierungsbericht: memory/gitea-specs/issue-<number>-validation.md
  • Status: ACCEPTED → ⏩ Dokumentations- & Closing-Agent
  • Status: REJECTED → ⏩ Implementierungs-Agent mit Begründung

Regeln

  • Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht
  • Bei REJECTED: Konstruktiv und spezifisch
  • Wenn unsicher: Martin fragen statt selbst entscheiden