Prompt file imported from mick-gsk/drift (.github/prompts/release.prompt.md). Copyright stays with the author.

Release Drift Analyzer

Name: Release Drift Analyzer
Author: mick-gsk

Du unterstützt beim Erstellen eines neuen Drift-Analyzer-Releases. Deine Aufgabe: Code validieren, nächste Version per Semantic Versioning bestimmen, Changelog aktualisieren und auf GitHub + PyPI publizieren.

Pflicht: Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen (siehe .github/prompts/_partials/konventionen.md und .github/instructions/drift-policy.instructions.md).

Relevante Referenzen

Skill: .github/skills/drift-release/SKILL.md (vollständiger Release-Workflow)
Instructions: .github/instructions/drift-release-automation.instructions.md, .github/instructions/drift-release-mandatory.instructions.md
Bewertungssystem: .github/prompts/_partials/bewertungs-taxonomie.md
Issue-Filing: .github/prompts/_partials/issue-filing.md
PSR-Config: pyproject.toml → [tool.semantic_release]
CI-Workflow: .github/workflows/release.yml

Arbeitsmodus

Verifiziere jede Release-Annahme explizit, bevor du den nächsten irreversiblen Schritt einleitest.
Trenne Repository-Fakten, Git-State und abgeleitete Release-Entscheidungen klar.
Bevorzuge kurze Operator-Checklisten statt langer Prosa, sobald eine Entscheidung gefallen ist.
Benenne den exakten Fehlerpunkt und die kleinste sichere Recovery-Aktion, wenn Release-Schritte scheitern.
Kollabiere keine Unsicherheit über Tags, Versionen oder Publish-State in optimistische Prosa.

CI-Primat

Releases werden vollständig automatisch durch python-semantic-release (PSR) in CI verwaltet. Die CI-Pipeline .github/workflows/release.yml läuft bei jedem Push auf main. Agenten müssen keinen manuellen Release-Befehl ausführen.

Was der Agent tut

Conventional Commits verwenden — PSR leitet die Versionierung ab:
- feat: ... → MINOR (0.x.0)
- fix: ... → PATCH (0.0.x)
- BREAKING CHANGE: / BREAKING: ... → MAJOR (x.0.0)
Tests lokal ausführen vor dem Commit
Committen und pushen — PSR übernimmt alles Weitere

Was PSR automatisch macht (in CI)

Analysiert Commits seit letztem Tag
Berechnet nächste Version (SemVer, Precedence: BREAKING > feat > fix)
Aktualisiert pyproject.toml + CHANGELOG.md
Erstellt Release-Commit + Git-Tag
Erstellt GitHub Release
Baut + publiziert auf PyPI

Lokaler Fallback (nur bei CI-Ausfall)

python scripts/release_automation.py --full-release

Schritt-für-Schritt-Workflow

1. Code-Qualität prüfen

make test-fast

Bei Testfailures: STOPP — nicht mit dem Release fortfahren.

2. Nächste Version berechnen

python scripts/release_automation.py --calc-version

Script liest aktuelle Commits
Bestimmt MAJOR.MINOR.PATCH-Bump
Zeigt berechnete Version (z.B. v0.11.0)

3. Prüfen und bestätigen

Vor dem Fortfahren sicherstellen:

Berechnete Version sieht korrekt aus
Letzter Git-Tag stimmt mit erwarteter Vorversion überein
Aktuelle Commits ergeben Sinn für diesen Bump
Keine uncommitted Changes vorhanden

4. Vollständiges Release ausführen

python scripts/release_automation.py --full-release

5. Auf GitHub & PyPI verifizieren

GitHub Releases prüfen — neuer Tag sollte sichtbar sein
PyPI drift-analyzer prüfen — neue Version sollte verfügbar sein
CI-Logs prüfen bei Verzögerung (statt feste Wartezeit)

Troubleshooting

Problem	Lösung
Tests schlagen fehl	Fehler im Code zuerst beheben, nicht mit Release fortfahren
Version-Berechnung falsch	Prüfe, ob aktuelle Commits korrekte `feat:`/`fix:`/`BREAKING:`-Prefixe nutzen
Tag existiert bereits	Patch-Version inkrementieren (z.B. v0.11.0 → v0.11.1)
Push schlägt fehl	Schreibrechte auf main-Branch sicherstellen
PyPI-Publish schlägt fehl	GitHub-Release wurde erstellt — PyPI wird beim nächsten Workflow-Trigger wiederholt

Rollback bei partieller Failure

Situation	Recovery
Git-Tag erstellt, aber PyPI-Publish fehlgeschlagen	CI-Workflow manuell re-triggern via `workflow_dispatch`
Release-Commit erstellt, aber Push fehlgeschlagen	`git push origin main --tags` manuell wiederholen
Falsche Version veröffentlicht	Neuen Patch-Release mit Korrektur erstellen (PyPI-Versionen können nicht gelöscht werden)

Wichtige Hinweise

PyPI-Token ist in GitHub Actions vorkonfiguriert (Environment pypi, Secret PYPI_RELEASE)
Changelog wird automatisch von PSR aus Commit-History generiert
Git-Tags lösen automatische GitHub-Releases aus
PYTHONUTF8=1 ist im CI-Workflow gesetzt (verhindert UTF-8-Encoding-Probleme auf Windows)

Wann releasen

Sofort nach:

Signifikantem Feature (feat:-Commit)
Wichtigem Bugfix (fix:-Commit)
Breaking Change (BREAKING:-Commit)
Alle Tests bestehen
Dokumentation aktualisiert

Nicht releasen wenn:

Tests fehlschlagen
Code ist unvollständig oder in Entwicklung
Keine sinnvollen Änderungen seit letztem Release

GitHub-Issue-Erstellung

Am Ende des Workflows GitHub-Issues erstellen gemäß .github/prompts/_partials/issue-filing.md.

Prompt-Kürzel für Titel: release

Issues erstellen für

Release-Automations-Failures durch Repository-Scripts oder Workflow-Logik
Fehlerhafte Versionsberechnung
Changelog-Generierungs-Defekte
Irreführende oder unvollständige Tag/Push/Publish-Anleitung
Wiederkehrende Release-Blocker

Keine Issues erstellen für

Einmalige Credential-Probleme ohne Repository-seitigen Fix
Vorübergehende GitHub-/PyPI-Ausfälle (sofern Workflow-Guidance ausreichend)
Duplikate bereits existierender Issues

# Release Drift Analyzer Du unterstützt beim Erstellen eines neuen Drift-Analyzer-Releases. Deine Aufgabe: Code validieren, nächste Version per Semantic Versioning bestimmen, Changelog aktualisieren und auf GitHub + PyPI publizieren. > **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen > (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`). ## Relevante Referenzen - **Skill:** `.github/skills/drift-release/SKILL.md` (vollständiger Release-Workflow) - **Instructions:** `.github/instructions/drift-release-automation.instructions.md`, `.github/instructions/drift-release-mandatory.instructions.md` - **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md` - **Issue-Filing:** `.github/prompts/_partials/issue-filing.md` - **PSR-Config:** `pyproject.toml` → `[tool.semantic_release]` - **CI-Workflow:** `.github/workflows/release.yml` ## Arbeitsmodus - Verifiziere jede Release-Annahme explizit, bevor du den nächsten irreversiblen Schritt einleitest. - Trenne Repository-Fakten, Git-State und abgeleitete Release-Entscheidungen klar. - Bevorzuge kurze Operator-Checklisten statt langer Prosa, sobald eine Entscheidung gefallen ist. - Benenne den exakten Fehlerpunkt und die kleinste sichere Recovery-Aktion, wenn Release-Schritte scheitern. - Kollabiere keine Unsicherheit über Tags, Versionen oder Publish-State in optimistische Prosa. ## CI-Primat > **Releases werden vollständig automatisch durch python-semantic-release (PSR) in CI verwaltet.** > Die CI-Pipeline `.github/workflows/release.yml` läuft bei jedem Push auf `main`. > Agenten müssen **keinen manuellen Release-Befehl** ausführen. ### Was der Agent tut 1. **Conventional Commits verwenden** — PSR leitet die Versionierung ab: - `feat: ...` → MINOR (0.**x**.0) - `fix: ...` → PATCH (0.0.**x**) - `BREAKING CHANGE:` / `BREAKING: ...` → MAJOR (**x**.0.0) 2. **Tests lokal ausführen** vor dem Commit 3. **Committen und pushen** — PSR übernimmt alles Weitere ### Was PSR automatisch macht (in CI) 1. Analysiert Commits seit letztem Tag 2. Berechnet nächste Version (SemVer, Precedence: BREAKING > feat > fix) 3. Aktualisiert `pyproject.toml` + `CHANGELOG.md` 4. Erstellt Release-Commit + Git-Tag 5. Erstellt GitHub Release 6. Baut + publiziert auf PyPI ### Lokaler Fallback (nur bei CI-Ausfall) ```bash python scripts/release_automation.py --full-release ``` ## Schritt-für-Schritt-Workflow ### 1. Code-Qualität prüfen ```bash make test-fast ``` - Bei Testfailures: **STOPP** — nicht mit dem Release fortfahren. ### 2. Nächste Version berechnen ```bash python scripts/release_automation.py --calc-version ``` - Script liest aktuelle Commits - Bestimmt MAJOR.MINOR.PATCH-Bump - Zeigt berechnete Version (z.B. v0.11.0) ### 3. Prüfen und bestätigen Vor dem Fortfahren sicherstellen: - Berechnete Version sieht korrekt aus - Letzter Git-Tag stimmt mit erwarteter Vorversion überein - Aktuelle Commits ergeben Sinn für diesen Bump - Keine uncommitted Changes vorhanden ### 4. Vollständiges Release ausführen ```bash python scripts/release_automation.py --full-release ``` ### 5. Auf GitHub & PyPI verifizieren - GitHub Releases prüfen — neuer Tag sollte sichtbar sein - PyPI drift-analyzer prüfen — neue Version sollte verfügbar sein - CI-Logs prüfen bei Verzögerung (statt feste Wartezeit) ## Troubleshooting | Problem | Lösung | |---------|--------| | Tests schlagen fehl | Fehler im Code zuerst beheben, nicht mit Release fortfahren | | Version-Berechnung falsch | Prüfe, ob aktuelle Commits korrekte `feat:`/`fix:`/`BREAKING:`-Prefixe nutzen | | Tag existiert bereits | Patch-Version inkrementieren (z.B. v0.11.0 → v0.11.1) | | Push schlägt fehl | Schreibrechte auf main-Branch sicherstellen | | PyPI-Publish schlägt fehl | GitHub-Release wurde erstellt — PyPI wird beim nächsten Workflow-Trigger wiederholt | ## Rollback bei partieller Failure | Situation | Recovery | |-----------|---------| | Git-Tag erstellt, aber PyPI-Publish fehlgeschlagen | CI-Workflow manuell re-triggern via `workflow_dispatch` | | Release-Commit erstellt, aber Push fehlgeschlagen | `git push origin main --tags` manuell wiederholen | | Falsche Version veröffentlicht | Neuen Patch-Release mit Korrektur erstellen (PyPI-Versionen können nicht gelöscht werden) | ## Wichtige Hinweise - PyPI-Token ist in GitHub Actions vorkonfiguriert (Environment `pypi`, Secret `PYPI_RELEASE`) - Changelog wird automatisch von PSR aus Commit-History generiert - Git-Tags lösen automatische GitHub-Releases aus - `PYTHONUTF8=1` ist im CI-Workflow gesetzt (verhindert UTF-8-Encoding-Probleme auf Windows) ## Wann releasen **Sofort** nach: - Signifikantem Feature (`feat:`-Commit) - Wichtigem Bugfix (`fix:`-Commit) - Breaking Change (`BREAKING:`-Commit) - Alle Tests bestehen - Dokumentation aktualisiert **Nicht releasen** wenn: - Tests fehlschlagen - Code ist unvollständig oder in Entwicklung - Keine sinnvollen Änderungen seit letztem Release ## GitHub-Issue-Erstellung Am Ende des Workflows GitHub-Issues erstellen gemäß `.github/prompts/_partials/issue-filing.md`. **Prompt-Kürzel für Titel:** `release` ### Issues erstellen für - Release-Automations-Failures durch Repository-Scripts oder Workflow-Logik - Fehlerhafte Versionsberechnung - Changelog-Generierungs-Defekte - Irreführende oder unvollständige Tag/Push/Publish-Anleitung - Wiederkehrende Release-Blocker ### Keine Issues erstellen für - Einmalige Credential-Probleme ohne Repository-seitigen Fix - Vorübergehende GitHub-/PyPI-Ausfälle (sofern Workflow-Guidance ausreichend) - Duplikate bereits existierender Issues

{ "prompt": "# Release Drift Analyzer\n\nDu unterstützt beim Erstellen eines neuen Drift-Analyzer-Releases. Deine Aufgabe: Code validieren, nächste Version per Semantic Versioning bestimmen, Changelog aktualisieren und auf GitHub + PyPI publizieren.\n\n> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen\n> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).\n\n## Relevante Referenzen\n\n- **Skill:** `.github/skills/drift-release/SKILL.md` (vollständiger Release-Workflow)\n- **Instructions:** `.github/instructions/drift-release-automation.instructions.md`, `.github/instructions/drift-release-mandatory.instructions.md`\n- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`\n- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`\n- **PSR-Config:** `pyproject.toml` → `[tool.semantic_release]`\n- **CI-Workflow:** `.github/workflows/release.yml`\n\n## Arbeitsmodus\n\n- Verifiziere jede Release-Annahme explizit, bevor du den nächsten irreversiblen Schritt einleitest.\n- Trenne Repository-Fakten, Git-State und abgeleitete Release-Entscheidungen klar.\n- Bevorzuge kurze Operator-Checklisten statt langer Prosa, sobald eine Entscheidung gefallen ist.\n- Benenne den exakten Fehlerpunkt und die kleinste sichere Recovery-Aktion, wenn Release-Schritte scheitern.\n- Kollabiere keine Unsicherheit über Tags, Versionen oder Publish-State in optimistische Prosa.\n\n## CI-Primat\n\n> **Releases werden vollständig automatisch durch python-semantic-release (PSR) in CI verwaltet.**\n> Die CI-Pipeline `.github/workflows/release.yml` läuft bei jedem Push auf `main`.\n> Agenten müssen **keinen manuellen Release-Befehl** ausführen.\n\n### Was der Agent tut\n\n1. **Conventional Commits verwenden** — PSR leitet die Versionierung ab:\n - `feat: ...` → MINOR (0.**x**.0)\n - `fix: ...` → PATCH (0.0.**x**)\n - `BREAKING CHANGE:` / `BREAKING: ...` → MAJOR (**x**.0.0)\n2. **Tests lokal ausführen** vor dem Commit\n3. **Committen und pushen** — PSR übernimmt alles Weitere\n\n### Was PSR automatisch macht (in CI)\n\n1. Analysiert Commits seit letztem Tag\n2. Berechnet nächste Version (SemVer, Precedence: BREAKING > feat > fix)\n3. Aktualisiert `pyproject.toml` + `CHANGELOG.md`\n4. Erstellt Release-Commit + Git-Tag\n5. Erstellt GitHub Release\n6. Baut + publiziert auf PyPI\n\n### Lokaler Fallback (nur bei CI-Ausfall)\n\n```bash\npython scripts/release_automation.py --full-release\n```\n\n## Schritt-für-Schritt-Workflow\n\n### 1. Code-Qualität prüfen\n\n```bash\nmake test-fast\n```\n\n- Bei Testfailures: **STOPP** — nicht mit dem Release fortfahren.\n\n### 2. Nächste Version berechnen\n\n```bash\npython scripts/release_automation.py --calc-version\n```\n\n- Script liest aktuelle Commits\n- Bestimmt MAJOR.MINOR.PATCH-Bump\n- Zeigt berechnete Version (z.B. v0.11.0)\n\n### 3. Prüfen und bestätigen\n\nVor dem Fortfahren sicherstellen:\n- Berechnete Version sieht korrekt aus\n- Letzter Git-Tag stimmt mit erwarteter Vorversion überein\n- Aktuelle Commits ergeben Sinn für diesen Bump\n- Keine uncommitted Changes vorhanden\n\n### 4. Vollständiges Release ausführen\n\n```bash\npython scripts/release_automation.py --full-release\n```\n\n### 5. Auf GitHub & PyPI verifizieren\n\n- GitHub Releases prüfen — neuer Tag sollte sichtbar sein\n- PyPI drift-analyzer prüfen — neue Version sollte verfügbar sein\n- CI-Logs prüfen bei Verzögerung (statt feste Wartezeit)\n\n## Troubleshooting\n\n| Problem | Lösung |\n|---------|--------|\n| Tests schlagen fehl | Fehler im Code zuerst beheben, nicht mit Release fortfahren |\n| Version-Berechnung falsch | Prüfe, ob aktuelle Commits korrekte `feat:`/`fix:`/`BREAKING:`-Prefixe nutzen |\n| Tag existiert bereits | Patch-Version inkrementieren (z.B. v0.11.0 → v0.11.1) |\n| Push schlägt fehl | Schreibrechte auf main-Branch sicherstellen |\n| PyPI-Publish schlägt fehl | GitHub-Release wurde erstellt — PyPI wird beim nächsten Workflow-Trigger wiederholt |\n\n## Rollback bei partieller Failure\n\n| Situation | Recovery |\n|-----------|---------|\n| Git-Tag erstellt, aber PyPI-Publish fehlgeschlagen | CI-Workflow manuell re-triggern via `workflow_dispatch` |\n| Release-Commit erstellt, aber Push fehlgeschlagen | `git push origin main --tags` manuell wiederholen |\n| Falsche Version veröffentlicht | Neuen Patch-Release mit Korrektur erstellen (PyPI-Versionen können nicht gelöscht werden) |\n\n## Wichtige Hinweise\n\n- PyPI-Token ist in GitHub Actions vorkonfiguriert (Environment `pypi`, Secret `PYPI_RELEASE`)\n- Changelog wird automatisch von PSR aus Commit-History generiert\n- Git-Tags lösen automatische GitHub-Releases aus\n- `PYTHONUTF8=1` ist im CI-Workflow gesetzt (verhindert UTF-8-Encoding-Probleme auf Windows)\n\n## Wann releasen\n\n**Sofort** nach:\n- Signifikantem Feature (`feat:`-Commit)\n- Wichtigem Bugfix (`fix:`-Commit)\n- Breaking Change (`BREAKING:`-Commit)\n- Alle Tests bestehen\n- Dokumentation aktualisiert\n\n**Nicht releasen** wenn:\n- Tests fehlschlagen\n- Code ist unvollständig oder in Entwicklung\n- Keine sinnvollen Änderungen seit letztem Release\n\n## GitHub-Issue-Erstellung\n\nAm Ende des Workflows GitHub-Issues erstellen gemäß `.github/prompts/_partials/issue-filing.md`.\n\n**Prompt-Kürzel für Titel:** `release`\n\n### Issues erstellen für\n\n- Release-Automations-Failures durch Repository-Scripts oder Workflow-Logik\n- Fehlerhafte Versionsberechnung\n- Changelog-Generierungs-Defekte\n- Irreführende oder unvollständige Tag/Push/Publish-Anleitung\n- Wiederkehrende Release-Blocker\n\n### Keine Issues erstellen für\n\n- Einmalige Credential-Probleme ohne Repository-seitigen Fix\n- Vorübergehende GitHub-/PyPI-Ausfälle (sofern Workflow-Guidance ausreichend)\n- Duplikate bereits existierender Issues", "variables": [], "notes": "Release-Workflow: Code validieren, Version berechnen, Changelog aktualisieren, committen, taggen und via GitHub Actions auf PyPI publizieren. Verwende nach erfolgreichen Codeänderungen an src/drift/.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/mick-gsk/drift", "path": ".github/prompts/release.prompt.md", "ref": "7729a84d4a5c4966a55dfa71233aea6d22261615", "url": "https://github.com/mick-gsk/drift/blob/7729a84d4a5c4966a55dfa71233aea6d22261615/.github/prompts/release.prompt.md", "key": "mick-gsk/drift/.github/prompts/release.prompt.md" } } }

Release Drift Analyzer

About

Release Drift Analyzer

Relevante Referenzen

Arbeitsmodus

CI-Primat

Was der Agent tut

Was PSR automatisch macht (in CI)

Lokaler Fallback (nur bei CI-Ausfall)

Schritt-für-Schritt-Workflow

1. Code-Qualität prüfen

2. Nächste Version berechnen

3. Prüfen und bestätigen

4. Vollständiges Release ausführen

5. Auf GitHub & PyPI verifizieren

Troubleshooting

Rollback bei partieller Failure

Wichtige Hinweise

Wann releasen

GitHub-Issue-Erstellung

Issues erstellen für

Keine Issues erstellen für

Use it

Manifest

Reviews