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

2.6 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: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Problem wirklich löst.

Eingang

  • Gemergter PR / Release-Tag
  • 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

  • Finaler Check des gemergten Stands
  • Keine Regressions in bestehenden Features
  • Keine offensichtlichen Fehler

Stakeholder-Feedback auswerten

  • Falls Martin bereits getestet hat: Feedback einarbeiten
  • Bei neuen Anforderungen: Neues Issue erstellen (kein Scope Creep)

Produktionsverhalten kontrollieren

  • Code-Stand auf main nach Merge prüfen
  • Build/CI-Status grün?
  • Keine Warnungen die übersehen wurden

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 (Phase 2)

Ausgang

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

Regeln

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