openclaw/skills/gitea-merge-release/SKILL.md

name, description

name	description
gitea-merge-release	Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline.

Merge- & Release-Agent

Rolle: Phase 5 – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.

Eingang

• Feature Branch mit APPROVED Code und PASS-Status im QA (oder APPROVED bei Komplexität S ohne QA)
• QA-Report: memory/gitea-specs/issue-<number>-qa.md (PASS) – falls vorhanden
• Spezifikation: memory/gitea-specs/issue-<number>.md

Aufgaben

Pull Requests verwalten

• PR via Gitea API erstellen:

curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pulls" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "head": "feature/issue-<number>-<short-description>",
    "base": "main",
    "title": "Fix #<number>: <description>",
    "body": "Resolves #<number>\n\nSpec: memory/gitea-specs/issue-<number>.md\nQA: PASS"
  }'

• PR-Beschreibung vollständig ausfüllen
• Labels und Assignees setzen

Main-Stand prüfen & Rebase

Bevor PR erstellt wird, prüfen ob main neue Commits hat:

git fetch origin
git log --oneline HEAD..origin/main

Falls ja, Feature Branch auf aktuellen main rebasen:

git rebase origin/main
git push --force-with-lease

Stellt sicher dass der PR konfliktfrei mergeable ist.

Linting-Gate (PFLICHT vor PR-Erstellung)

Vor JEDEM PR müssen ALLE konfigurierten Linter erfolgreich durchlaufen. Falls ein Linter fehlschlägt: PR abbrechen, Fehler beheben, Linting wiederholen.

# PHP Syntax Check
find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"

# CSS Lint (stylelint)
npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input

# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"

# Projekt-spezifische Linter (falls vorhanden)
npm run lint

Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN PR erstellen.

Merge-Konflikte lösen

• Falls beim Rebase Konflikte auftreten
• Konflikte manuell auflösen
• git rebase --continue
• Bei komplexen Konflikten: Martin involvieren

Release Notes erstellen

• Änderungen zusammenfassen (user-facing)
• Breaking Changes hervorheben
• Neue Features / Bugfixes / Verbesserungen kategorisieren
• Contributors erwähnen falls relevant

Versionen verwalten

• Aktuelle Version aus package.json / VERSION / Git Tags auslesen
• Nächste Version nach Schema festlegen

Semantic Versioning anwenden

• PATCH (x.y.Z): Bugfixes, keine neuen Features
• MINOR (x.Y.z): Neue Features, rückwärtskompatibel
• MAJOR (X.y.z): Breaking Changes
• Pre-Release Tags bei Bedarf: -alpha, -beta, -rc.1

Changelogs generieren

• Alle Commits seit letztem Release sammeln
• Nach Typ gruppieren (feat/fix/refactor/chore)
• In CHANGELOG.md eintragen
• Format: Keep a Changelog

Release-Tags erstellen

git tag -a v<version> -m "Release v<version>: <summary>"
git push origin v<version>

CI/CD-Pipelines überwachen

• Pipeline-Status nach Push prüfen
• Bei Fehlern: Logs analysieren und beheben
• Bei Erfolg: weiter zur Abnahme

Build-Artefakte validieren

• Build erfolgreich?
• Artefakt-Größe plausibel?
• Checksummen verifizieren

Release-Freigaben koordinieren

• Martin über Release informieren
• PR-Link und Release Notes senden
• Auf Martins Freigabe warten vor Merge

Ausgang

• PR erstellt und Martin informiert
• Label ReadyForMerge gesetzt (kumulativ)
• Warte auf Martins Merge-Freigabe
• Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)
• Zeit-Tracking: Dauer der Phase dokumentieren

Regeln

• NIEMALS ohne Martins Freigabe mergen
• NIEMALS direkt auf main pushen
• Release Notes IMMER vor dem Merge erstellen
• API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren
• Nach Martins Merge: Pipeline geht automatisch weiter mit Phase 6 (Abnahme) und Phase 7 (Closing). Martin darüber informieren.