feat(claude): bump-version Skill hinzugefügt

Neuer projektspezifischer Skill, der bei Commit-Anfragen automatisch
fragt ob die Version (pyproject.toml, SemVer) mit gebumpt werden soll,
und bei direkten Release-Anfragen Version + Commit + Git-Tag erstellt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/settings.json

@@ -0,0 +1,9 @@
+{
+  "permissions": {
+    "allow": [
+      "Skill(bump-version)",
+      "Skill(bump-version:*)",
+      "Bash(git branch *)"
+    ]
+  }
+}

.claude/settings.local.json

@@ -0,0 +1,21 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(git add:*)",
+      "Bash(git commit -m ':*)",
+      "Bash(bash C:/Users/vgraf/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/scripts/start-server.sh --project-dir /c/Users/vgraf/git/whisper-local)",
+      "Bash(bash \"C:/Users/vgraf/.claude/plugins/cache/claude-plugins-official/superpowers/5.0.7/skills/brainstorming/scripts/start-server.sh\" --project-dir /c/Users/vgraf/git/whisper-local)",
+      "Bash(git commit:*)",
+      "Bash(git check-ignore:*)",
+      "Bash(git worktree:*)",
+      "Bash(uv run:*)",
+      "Bash(uv lock:*)",
+      "Bash(python -c ':*)",
+      "Bash(python3)",
+      "Bash(git checkout:*)",
+      "Bash(git pull:*)",
+      "WebSearch",
+      "Bash(git tag:*)"
+    ]
+  }
+}

.claude/skills/bump-version/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: bump-version
+description: >
+  Versionsverwaltung für whisper-local: aktualisiert die Version in pyproject.toml nach SemVer,
+  erstellt einen Git-Commit und setzt ein Git-Tag. IMMER aktivieren wenn der Nutzer einen
+  Git-Commit erstellen möchte — dann zuerst fragen ob die Version mit gebumpt werden soll,
+  bevor der Commit gemacht wird. Auch direkt aktivieren wenn der Nutzer die Version erhöhen,
+  ein Release erstellen oder einen neuen Stand taggen möchte.
+---
+
+# Version Bump für whisper-local
+
+## Modus A — Commit-Anfrage (Normalfall)
+
+Wenn der Nutzer einen Git-Commit erstellen möchte, **bevor** du den Commit machst:
+
+Frage einmal kurz:
+> „Soll ich die Version in `pyproject.toml` mit aktualisieren? (aktuell: X.Y.Z) — patch / minor / major / nein"
+
+- Antwortet er mit patch / minor / major: führe zuerst den **Versions-Bump** durch (Schritte 1–5 unten), dann committe **alle** vorgesehenen Änderungen zusammen in einem einzigen Commit (nicht zwei separate Commits).
+- Antwortet er mit nein oder macht keine Angabe: Commit wie gewohnt, kein Versions-Bump.
+
+## Modus B — Direkter Versions-Bump
+
+Wenn der Nutzer explizit die Version erhöhen will (z.B. „bump patch", „minor release", „Version auf 2.0.0"):
+Führe direkt Schritte 1–6 aus, ohne vorher zu fragen.
+
+---
+
+## Ablauf Versions-Bump
+
+### 1. Aktuelle Version ermitteln
+
+Lies `pyproject.toml` und extrahiere die `version`-Zeile im `[project]`-Block.
+Format: `MAJOR.MINOR.PATCH` (z.B. `1.2.0`).
+
+### 2. Neue Version berechnen
+
+| Nutzerintention | Regel | Beispiel |
+|---|---|---|
+| `patch` / Bugfix / klein | PATCH +1 | `1.2.0` → `1.2.1` |
+| `minor` / Feature / neu | MINOR +1, PATCH=0 | `1.2.0` → `1.3.0` |
+| `major` / Breaking / groß | MAJOR +1, MINOR=0, PATCH=0 | `1.2.0` → `2.0.0` |
+
+Wenn der Nutzer eine konkrete Zielversion nennt (z.B. „auf 2.0.0"), verwende diese direkt.
+
+### 3. pyproject.toml aktualisieren
+
+Ersetze exakt die Zeile `version = "ALTE_VERSION"` durch `version = "NEUE_VERSION"`.
+Ändere nichts anderes in der Datei.
+
+### 4. Git-Commit erstellen
+
+**Modus A:** Stage `pyproject.toml` zusammen mit allen anderen vorgesehenen Änderungen.
+Der Commit-Titel bleibt die vom Nutzer gewünschte Beschreibung — füge am Ende hinzu: `(bump NEUE_VERSION)`.
+
+**Modus B:** Stage nur `pyproject.toml`, Commit-Nachricht:
+```
+chore: bump version to NEUE_VERSION
+```
+
+### 5. Git-Tag setzen
+
+```
+git tag -a vNEUE_VERSION -m "Version NEUE_VERSION"
+```
+
+### 6. Bestätigung ausgeben (nur Modus B)
+
+```
+Version: 1.2.0 → 1.3.0
+Commit: chore: bump version to 1.3.0
+Tag: v1.3.0
+
+Zum Pushen: git push && git push --tags
+```
+
+## Hinweise
+
+- Stelle die Versions-Frage nur einmal — wenn der Nutzer nicht antwortet oder „nein" sagt, nicht erneut fragen.
+- Wenn unklar ist, welche SemVer-Komponente gemeint ist, frage einmal kurz nach.
+- Im Modus A keinen separaten Versions-Commit erstellen — alles in einen Commit.