diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 0000000..be136ab --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,9 @@ +{ + "permissions": { + "allow": [ + "Skill(bump-version)", + "Skill(bump-version:*)", + "Bash(git branch *)" + ] + } +} diff --git a/.claude/settings.local.json b/.claude/settings.local.json new file mode 100644 index 0000000..6c79246 --- /dev/null +++ b/.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:*)" + ] + } +} diff --git a/.claude/skills/bump-version/SKILL.md b/.claude/skills/bump-version/SKILL.md new file mode 100644 index 0000000..638376a --- /dev/null +++ b/.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.