Files
xsl-validator/.claude/skills/version-bump/SKILL.md
T
info 712bd8917e version-bump Skill: Git-Tag nach Commit setzen
Der Skill setzt jetzt nach einem erfolgreichen Commit mit Versionserhöhung
automatisch einen passenden annotated Git-Tag (z.B. v1.7.1).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-30 16:38:57 +02:00

3.6 KiB

name, description
name description
version-bump Versionsverwaltung für DocuMentor-Commits. Verwende diesen Skill IMMER wenn der Benutzer einen Git-Commit erstellen möchte, 'commit' erwähnt, oder nach /commit fragt. Der Skill fragt vor dem Commit, ob die Programmversion aktualisiert werden soll, und aktualisiert alle versionsbezogenen Dateien einheitlich.

Version Bump Skill

Dieser Skill stellt sicher, dass bei jedem Commit die Programmversion bewusst behandelt wird. Bevor der eigentliche Commit erstellt wird, wird der Benutzer gefragt, ob und wie die Version angepasst werden soll.

Warum das wichtig ist

DocuMentor speichert die Version an mehreren Stellen gleichzeitig (pyproject.toml, Installer-Dateien, Lizenz-Footer). Wenn diese aus dem Takt geraten, entstehen inkonsistente Builds. Dieser Skill verhindert das, indem er alle Stellen auf einmal aktualisiert.

Ablauf

Schritt 1: Benutzer fragen

Bevor du den Commit erstellst, frage den Benutzer mit dem AskUserQuestion-Tool:

Frage: "Soll die Programmversion aktualisiert werden?"

Optionen:

  • Patch (X.Y.Z+1) — Bugfix, kleine Änderung
  • Minor (X.Y+1.0) — Neues Feature, Erweiterung
  • Major (X+1.0.0) — Breaking Change, großer Meilenstein
  • Nein, Version beibehalten — Keine Versionsänderung

Zeige dabei die aktuelle Version aus pyproject.toml in der Frage an.

Schritt 2: Version aktualisieren (falls gewünscht)

Wenn der Benutzer eine Versionserhöhung wählt:

  1. pyproject.toml — über uv version --bump aktualisieren (niemals direkt bearbeiten):

    uv version --bump patch   # für Patch
    uv version --bump minor   # für Minor
    uv version --bump major   # für Major
    

    Nach dem Befehl die neue Version aus pyproject.toml auslesen — sie ist die Single Source of Truth.

  2. DocuMentor.wxs — WiX Installer (z. B. Zeile mit Version=):

    Version="X.Y.Z"
    
  3. installer.iss — Inno Setup (z. B. Zeile mit #define MyAppVersion):

    #define MyAppVersion "X.Y.Z"
    
  4. THIRD_PARTY_LICENSES.txt — Lizenz-Footer (letzte Zeile):

    Erstellt für: DocuMentor vX.Y.Z
    

Führe zuerst uv version --bump aus, lese danach die neue Version aus pyproject.toml, und aktualisiere dann die übrigen drei Dateien auf diesen Wert.

Schritt 3: Commit erstellen

Nachdem die Versionsdateien aktualisiert wurden (oder der Benutzer "Nein" gewählt hat), erstelle den Commit ganz normal nach den üblichen Commit-Konventionen. Falls die Version geändert wurde, füge die geänderten Versionsdateien zum Commit hinzu.

Schritt 4: Git-Tag setzen (nur bei Versionserhöhung)

Wenn der Benutzer eine Versionserhöhung gewählt hat und der Commit erfolgreich war, setze einen annotated Git-Tag mit der neuen Version:

git tag -a "vX.Y.Z" -m "Version X.Y.Z"

Wobei X.Y.Z die neue Version aus pyproject.toml ist. Das Tag-Format ist immer v + Versionsnummer (z.B. v1.7.1).

Informiere den Benutzer danach kurz: „Tag vX.Y.Z gesetzt. Mit git push origin vX.Y.Z kannst du ihn pushen."

Wenn der Benutzer "Nein" gewählt hat, wird kein Tag gesetzt.

Wichtige Hinweise

  • pyproject.toml niemals direkt bearbeiten — immer uv version --bump verwenden
  • Die Version in pyproject.toml ist die Single Source of Truth; nach dem Bump dort auslesen
  • create_version_info.py liest automatisch aus pyproject.toml — diese Datei muss nicht manuell angepasst werden
  • uv.lock wird durch uv sync automatisch aktualisiert — nicht manuell ändern
  • Wenn der Benutzer "Nein" wählt, einfach normal mit dem Commit fortfahren