Release

Release-Skill

Ein dünner, repository-bewusster Release-Assistent. Beim ersten Durchlauf analysiert er das Projekt und CI, leitet Release-Regeln ab, speichert sie in .omc/RELEASE_RULE.md für die zukünftige Verwendung und führt Sie dann anhand dieser Regeln durch einen Release.

Verwendung

/oh-my-claudecode:release [version]

• version ist optional. Falls nicht angegeben, fragt der Skill nach. Akzeptiert patch, minor, major oder eine explizite Semver-Version wie 2.4.0.
• Fügen Sie --refresh hinzu, um eine erneute Analyse des Repositorys zu erzwingen, auch wenn bereits eine zwischengespeicherte Regeldatei existiert.

Ausführungsablauf

Schritt 0 – Release-Regeln laden oder erstellen

Prüfen, ob .omc/RELEASE_RULE.md existiert.

Existiert die Datei NICHT (oder wurde --refresh übergeben): Führen Sie die vollständige Repo-Analyse unten durch und schreiben Sie die Datei.

Existiert die Datei: Lesen Sie die Datei. Führen Sie dann eine schnelle Delta-Prüfung durch – durchsuchen Sie .github/workflows/ (oder entsprechende CI-Verzeichnisse: .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml) nach Änderungen, die neuer sind als der last-analyzed-Timestamp in der Regeldatei. Falls relevante Workflow-Dateien geändert wurden, führen Sie die Analyse für diese Abschnitte erneut durch und aktualisieren Sie die Datei. Berichten Sie, was sich geändert hat.

---

Schritt 1 – Repo-Analyse (erster Durchlauf oder --refresh)

Prüfen Sie das Repository und beantworten Sie die folgenden Fragen. Schreiben Sie die Antworten in .omc/RELEASE_RULE.md.

1a. Versionsquellen

• Suchen Sie alle Dateien, die einen Versionsstring enthalten, der mit der aktuellen Version in package.json / pyproject.toml / Cargo.toml / build.gradle / VERSION-Datei / etc. übereinstimmt.
• Listen Sie jede Datei sowie das Feld oder Regex-Muster auf, das zum Auffinden der Version verwendet wird.
• Erkennen Sie, ob es ein Release-Automatisierungsskript gibt (z.B. scripts/release.*, Makefile release-Target, bump2version, release-it, semantic-release, changesets, goreleaser).

1b. Registry / Distribution

• npm (package.json mit publishConfig oder npm publish in CI), PyPI (pyproject.toml + twine/flit), Cargo (Cargo.toml), Docker (Dockerfile + Push-Schritt), GitHub Packages, andere.
• Gibt es einen CI-Schritt, der bei einem Tag-Push automatisch veröffentlicht? Welche Workflow-Datei und welcher Job?

1c. Release-Trigger

• Identifizieren Sie, was den Release startet: Tag-Push (v*), manueller Dispatch (workflow_dispatch), Merge nach main/master, ein Release-Branch-Merge, ein Commit-Nachrichten-Muster.

1d. Test-Gate

• Identifizieren Sie den Testbefehl und wo er in CI ausgeführt wird.
• Müssen Tests vor der Veröffentlichung bestanden werden? Notieren Sie etwaige Umgehungsflags.

1e. Release-Notes / Changelog

• Existiert eine CHANGELOG.md oder CHANGELOG.rst?
• Welche Konvention wird verwendet: Keep a Changelog, Conventional Commits, GitHub auto-generiert, keine?
• Gibt es eine Release-Body-Datei (z.B. .github/release-body.md), die vor dem Tag committet wurde?

1f. Erstbenutzer-Prüfung

• Existiert ein Release-Workflow in .github/workflows/ (oder entsprechend)? Falls nicht, markieren und anbieten, ein Gerüst zu erstellen.
• Gibt es einen .gitignore-Eintrag, der Build-Artefakte vom Commit ausschließt? Falls nicht, markieren.
• Werden Git-Tags verwendet? Führen Sie git tag --list aus, um dies zu überprüfen. Falls keine Tags existieren, markieren und bewährte Vorgehensweise erklären.

---

Schritt 2 – .omc/RELEASE_RULE.md schreiben

Erstellen oder überschreiben Sie die Datei mit dieser Struktur:

# Release-Regeln
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->

## Versionsquellen
<!-- Liste der Dateien + Muster -->

## Release-Trigger
<!-- Was den Release auslöst -->

## Test-Gate
<!-- Befehl + CI-Job-Name -->

## Registry / Distribution
<!-- npm, PyPI, Docker, etc. + CI-Job, der veröffentlicht -->

## Release-Notes-Strategie
<!-- Konvention + Dateien -->

## CI-Workflow-Dateien
<!-- Pfade zu relevanten Workflow-Dateien -->

## Lücken bei der Ersteinrichtung
<!-- Fehlende Teile während der Analyse gefunden, oder "keine" -->

---

Schritt 3 – Version bestimmen

Wenn der Benutzer ein Versionsargument angegeben hat, verwenden Sie es. Andernfalls:

1. Zeigen Sie die aktuelle Version (aus der primären Versionsdatei) an.
2. Zeigen Sie, was patch, minor und major ergeben würden.
3. Fragen Sie den Benutzer, welche verwendet werden soll.

Validieren Sie, dass die gewählte Version ein gültiger Semver-String ist.

---

Schritt 4 – Pre-Release-Checkliste

Präsentieren Sie eine aus den Release-Regeln abgeleitete Checkliste. Mindestens:

• Alle für diesen Release vorgesehenen Änderungen sind committet und gepusht
• CI ist auf dem Ziel-Branch grün
• Tests laufen lokal erfolgreich (führen Sie den Test-Gate-Befehl aus)
• Versionsanpassung auf alle Versionsquellen-Dateien angewendet
• Release-Notes / Changelog vorbereitet (siehe Schritt 5)

Fragen Sie den Benutzer, ob er fortfahren möchte, oder führen Sie jeden Schritt aus, wenn er "los geht's" sagt.

---

Schritt 5 – Anleitung für Release-Notes

Helfen Sie dem Benutzer, gute Release-Notes zu schreiben. Wenden Sie die im Repository verwendete Konvention an. Standard-Anleitung, wenn keine Konvention erkannt wird:

Was eine gute Release-Notiz ausmacht:

• Beginnen Sie mit was sich für die Benutzer geändert hat, nicht mit internen Implementierungsdetails.
• Gruppieren Sie nach Typ: Neue Funktionen, Fehlerbehebungen, Brechende Änderungen, Veraltetes, Internes / Aufgaben.
• Für jeden Punkt: ein Satz, Link zum PR oder Issue, Autor bei externen nennen.
• Brechende Änderungen zuerst und müssen einen Migrationspfad enthalten.
• Lassen Sie Änderungen weg, die Benutzer nie sehen (Refactorings, CI-Anpassungen, reine Teständerungen), es sei denn, sie beeinträchtigen die Reproduzierbarkeit des Builds.

Beispiel-Eintragsformat:

### Fehlerbehebungen
- Sitzungsabbruch bei Token-Ablauf behoben (#123) — @contributor

Wenn das Repository Conventional Commits verwendet, generieren Sie einen Entwurf des Changelogs aus git log <prev-tag>..HEAD --no-merges --format="%s" gruppiert nach Commit-Typ. Zeigen Sie ihn dem Benutzer und lassen Sie ihn bearbeiten.

---

Schritt 6 – Release ausführen

Gehen Sie anhand der ermittelten Regeln wie folgt vor:

1. Version erhöhen – auf jede Versionsquellen-Datei anwenden.
2. Tests ausführen – den Test-Gate-Befehl ausführen.
3. Commit – git add <Versionsdateien> CHANGELOG.md und Commit mit chore(release): bump version to vX.Y.Z.
4. Taggen – git tag -a vX.Y.Z -m "vX.Y.Z" (annotierte Tags werden bevorzugt gegenüber leichten Tags).
5. Pushen – git push origin <branch> && git push origin vX.Y.Z.
6. CI übernimmt – wenn der Release-Trigger ein Tag-Push ist, erinnern Sie den Benutzer daran, dass der CI den Rest übernimmt (Veröffentlichung, GitHub-Release-Erstellung). Zeigen Sie die erwartete CI-Workflow-Datei.
7. Manuelles Veröffentlichen – wenn keine CI-Automatisierung existiert, listen Sie den manuellen Veröffentlichungsbefehl auf (z.B. npm publish --access public, twine upload dist/*).

---

Schritt 7 – Vorschläge zur Ersteinrichtung

Wenn in Schritt 1f Lücken gefunden wurden, bieten Sie konkrete Hilfe an:

Kein Release-Workflow:

Ihr Repository hat keinen Release-CI-Workflow. Ein GitHub Actions-Workflow, der bei einem v*-Tag-Push ausgelöst wird, ist die häufigste bewährte Vorgehensweise. Er kann:

• Tests ausführen
• Auf npm/PyPI/etc. veröffentlichen
• Ein GitHub-Release mit Ihren Release-Notes erstellen

Soll ich ein .github/workflows/release.yml für Ihren Stack gerüsten?

Keine Git-Tags:

Dies scheint der erste Release zu sein. Git-Tags ermöglichen GitHub, npm und anderen Tools, Ihre Versionshistorie zu verstehen. Wir erstellen Ihren ersten Tag in Schritt 6.

Build-Artefakte nicht gitignoriert:

Build-Artefakte sind in der Git-Historie vorhanden oder nicht gitignoriert. Dies bläht die Repository-Größe auf und erzeugt Merge-Konflikte. Soll ich sie zur .gitignore hinzufügen?

---

Schritt 8 – Verifizieren

Nach dem Push:

• CI-Status prüfen: gh run list --workflow=<Release-Workflow> --limit=3 (falls gh verfügbar).
• Registry (npm, PyPI) nach einigen Minuten auf die neue Version prüfen.
• Bestätigen, dass ein GitHub-Release erstellt wurde: gh release view vX.Y.Z.

Erfolg melden oder etwaige Fehler markieren.

---

Hinweise

• Dieser Skill kodiert keine projektspezifischen Versionsdateien oder Befehle fest. Alles wird aus der Repo-Inspektion abgeleitet.
• .omc/RELEASE_RULE.md ist ein lokaler Cache. Committen Sie ihn in Ihr Repo, wenn Sie die abgeleiteten Regeln mit Ihrem Team teilen möchten, oder fügen Sie ihn zur .gitignore hinzu, wenn Sie ihn lieber lokal behalten möchten.
• Bei komplexen Monorepos oder Multi-Package-Workspaces erkennt der Skill Workspace-Muster (npm workspaces, pnpm workspaces, Cargo workspace) und passt sich entsprechend an.