baratihd/skills

Treatment-Backend-Release-Notes

Erstelle eine genaue, überprüfbare englische Release-Notes anhand tatsächlicher Repository-Evidenz, wenn ein Quellbranch in einen Zielbranch (insbesondere stage oder production) überführt wird. Nach dem Schreiben der Release-Notes erstelle eine separate persische Überschriften-Zusammenfassung nur im Gespräch. Hänge die persische Zusammenfassung niemals in die Release-Notes oder eine andere Projektdatei an, bette sie dort ein oder schreibe sie dort hinein.

Agentenübergreifender Ausführungsvertrag

• Diese Fertigkeit ist zwischen Codex, OpenCode und Claude Code portabel; es ist kein anbieterspezifisches Werkzeug erforderlich. Lies diese SKILL.md und die verlinkten references/-Dateien, wenn sie aufgerufen wird.
• Eine kanonische Kopie wird unter .agents/skills/treatment-backend-release-note/ gespeichert; .claude/skills/ und .opencode/skills/ verweisen bei Verwendung des gebündelten Installers auf dieselbe Kopie. Halte keine abweichenden Kopien vor.
• Falls Werkzeuge oder Berechtigungen nicht verfügbar sind, melde die Einschränkung genau; erfinde keine Git-Evidenz oder Release-Status.
• Akzeptiere Aufrufe in natürlicher Sprache oder $treatment-backend-release-note in Codex, /treatment-backend-release-note in Claude Code und unterstützten OpenCode-Konfigurationen. Alle Aufrufe folgen genau demselben Arbeitsablauf und derselben Ausgaberichtlinie.

Eingaben und Umfang

• Erforderlich: source_branch, target_branch (Standardziel nur, wenn der Benutzer explizit eine Projektkonvention festlegt; ansonsten danach fragen, wenn es wirklich nicht verfügbar ist).
• Optional: Release-Version, Deployment-Zeitfenster, Ticket-Referenzen, Ausgabedateiname (gespeichert unter docs/releases/), Deployment-Methode, Verantwortlicher.
• Erkenne Remotes und validiere Refs, den Arbeitsverzeichniszustand und das Repository-Root, bevor Änderungen gesammelt werden. Wechsle keine Branches, führe keine Pull-, Fetch-, Commit-, Merge-, Tag-, Deployment-Aktionen durch und ändere keinen Anwendungscode ohne explizite Autorisierung.
• Falls Quelle/Ziel nicht angegeben sind, versuche, sie aus dem eindeutigen Kontext abzuleiten (z.B. Benutzer sagt "Release develop nach stage"); ansonsten frage nach. Gehe niemals stillschweigend davon aus, dass der aktuell ausgecheckte Branch der Quellbranch ist.
• Beide Refs können lokale Branches oder Remote-Tracking-Branches sein; gib genau an, welche aufgelösten Refs und Commit-Hashes analysiert wurden.
• Interpretiere den Bericht als Änderungen, die durch die Quelle ins Ziel eingeführt werden, nicht als alles, was jemals auf dem Quellbranch committet wurde.

Arbeitsablauf

1. Preflight- und Git-Evidenz

Führe vom Repository-Root aus diese Befehle aus (passe Ref-Namen sicher an; interpoliere keine nicht vertrauenswürdigen Shell-Argumente):

git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevante-pfade>

target..source identifiziert Commits, die vom Ziel aus nicht erreichbar sind. target...source in git diff vergleicht die Merge-Basis mit der Quelle und nähert sich damit den durch den Quellbranch vorgeschlagenen Änderungen an. Diese können für divergierende Branches, Cherry-Picks oder Rebases nicht dem exakten resultierenden Merge-Diff entsprechen. Untersuche bei einem vorgeschlagenen Release beide Perspektiven (Commits und Diff), identifiziere Anomalien und verwende bei Bedarf nur mit Autorisierung einen wegwerfbaren Worktree/temporären Merge. Gib kein endgültiges Merge-Ergebnis aus einem unverifizierten Drei-Punkte-Diff an. Bevorzuge für ein bereits abgeschlossenes Release, falls verfügbar, den aufgezeichneten Merge-Commit, Tag, die deployte SHA oder die tatsächlichen Vorher-/Nachher-Deployment-Refs.

Überprüfe relevante Quelldateien, Migrationen, Konfiguration, API-Schemas, Serializer, Berechtigungen, Hintergrundaufgaben, Integrationen, Tests und Deployment-Manifeste; verlasse dich nicht ausschließlich auf Commit-Betreffzeilen. Schließe generierte/Rauschdateien gegebenenfalls aus der Erzählung aus, verstecke aber keine wirkungsvollen generierten Migrationen oder Lockfile-Änderungen. Achte auf Änderungen mit geschäftlichen Auswirkungen, die mehrere Commits umfassen. Gruppiere nach Geschäftsfähigkeiten anstatt jede geänderte Datei aufzulisten. Verknüpfe Code mit Tickets/PRs, wenn dies nachweisbar ist.

2. Klassifiziere Änderungen und Auswirkungen

Trenne und beschreibe:

1. Geschäftsänderungen — neue oder geänderte Arbeitsabläufe, Berechtigungsregeln, Deckung, Ausgaben-/Anspruchsverarbeitung, Berichterstattung, Benachrichtigungen und beobachtbares Verhalten. Schreibe nur, wenn durch Code, Tests oder vom Benutzer bereitgestellten Produktkontext gestützt; kennzeichne Inferenzen oder fehlende Bestätigung deutlich.
2. Technische Änderungen — APIs, Django-Modelle/Migrationen, Jobs/Celery, Datenbank/Indizes, externe Integrationen, Einstellungen, Sicherheit/Berechtigungen, Zuverlässigkeit, Leistung, Beobachtbarkeit, CI/CD und Refactoring.
3. Kompatibilität und Konsumenten — REST-Endpunkte/Methoden, Anfrage/Antwort-Felder, Statuscodes, Authentifizierung, Web-/Mobil-Clients, interne Aufrufer, Worker, Drittsysteme, DB und Events. Gib Breaking change: Ja / Nein / Unbekannt mit Belegen an. Unterscheide API-Kompatibilität von Deployment-/Datenkompatibilität. Erkläre erforderliche Konsumentenaktionen und die Ausrollreihenfolge, wenn relevant.
4. Validierung und Nachverfolgbarkeit — exakte Quell-/Ziel-Refs + SHAs, Basis-SHA, erwähnenswerte Commits, Ticket-/PR-Links (wenn gefunden), Tests und deren tatsächlich beobachteten Status, Migrationspläne, Genehmiger/Status (falls angegeben). Belege keinen Test als bestanden, ohne ihn ausgeführt oder zuverlässige Testergebnisse erhalten zu haben.
5. Rückgängigmachen / Rollback — beschreibe zielgerechte Schritte und Voraussetzungen, mit getrennter Behandlung für Anwendungs-Rollback, umkehrbare Schema-Migrationen, nicht umkehrbare Datenmigrationen, wiederholbare Jobs, Nachrichten, Idempotenz und Auswirkungen auf Dritte. Unterscheide immer zwischen einem Git-Revert und einem operativen Rollback. Belege niemals, dass ein Rollback sicher ist, ohne Migrationen und Seiteneffekte zu prüfen.

Überprüfe die vollständige Checkliste in references/review-checklist.md.

3. Erstelle und speichere die englischen Release-Notes

Folge references/release-note-template.md. Verwende Englisch für alle Inhalte, die in der Release-Notes-Datei gespeichert werden, einschließlich Überschriften. Halte sie prägnant, aber informativ und sowohl für technische als auch für geschäftliche Überprüfungen geeignet. Verwende "Nicht verifiziert", "Unbekannt" oder "Erfordert Bestätigung" anstatt Details zu erfinden.

Das kanonische Projektausgabeverzeichnis ist docs/releases/. Speichere jede Release-Notes dort; erstelle kein release-notes/-Verzeichnis auf der Wurzelebene. Die Standardausgabe ist docs/releases/YYYY-MM-DD-<source>-to-<target>.md, wobei Schrägstriche in Branchnamen durch Bindestriche ersetzt werden. Halte einen explizit angeforderten Dateinamen ein, behalte ihn aber unter docs/releases/. Vermeide das Überschreiben einer vorhandenen Release-Notes. Falls das Ziel existiert, wähle einen eindeutigen Dateinamen oder suche explizite Zustimmung zum Ersetzen. Verwende nur das Datum der Generierung als Dokumentationsdatum, nicht ein erfundenes Deployment-Datum. Die Release-Notes sind ein vorgeschlagenes Release, bis das Deployment verifiziert ist.

Lies die Datei nach dem Speichern zurück und validiere: Branch-Richtung und Commit-Identitäten, geschäftliche/technische Änderungen, Kompatibilität, Verifizierung, Nachverfolgbarkeit, Rollback und das Fehlen einer persischen Zusammenfassung. Stage oder committe die Release-Notes nicht automatisch, es sei denn, dies wird angefordert. Melde den gespeicherten relativen Pfad.

4. Nur-Chat-persische Zusammenfassung (obligatorisch)

Nur nach erfolgreichem Speichern und Validieren präsentiere eine kurze Überschriften-Zusammenfassung auf Persisch in der endgültigen Agentenantwort. Konzentriere dich auf geschäftslesbare Ergebnisse, bedeutende Risiken, erforderliche Konsumenten-/Deployment-Aktionen und Bereitschaft/Unbekanntes. Normalerweise 3–7 kurze Aufzählungspunkte, ohne Details der niedrigen Implementierungsebene, es sei denn, es ist notwendig. Beispielformat:

خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...

Füge nur Aussagen ein, die während der Überprüfung festgestellt wurden. Speichere diese Zusammenfassung in keiner Datei, keinem Log, keiner Commit-Nachricht oder keinem Anhang der Release-Notes. Falls das Schreiben fehlschlägt, behaupte nicht, dass die Release-Notes registriert wurden; erkläre das Hindernis und gib, falls hilfreich, eine provisorische Zusammenfassung, die deutlich als provisorisch gekennzeichnet ist.

Qualitätskriterien

• Basieren Sie jede Änderung und Behauptung auf dem untersuchten Diff, Tests, der Git-Historie oder explizit bereitgestelltem Release-Kontext; unterscheiden Sie verifizierte Fakten von Schlussfolgerungen.
• Gib keine Geheimnisse, Token, Passwörter, private Kundendaten oder rohe Anmeldeinformationen aus, die in Diffs gefunden wurden. Schwärze Beispiele.
• Setze committed Code nicht mit deployter Funktionalität gleich, und setze einen nicht ausgeführten Test nicht mit einem bestandenen Test gleich.
• Wenn ein Branch nicht zusammenhängende Änderungen enthält, dokumentiere den Umfang und das Risiko, anstatt wichtige Änderungen stillschweigend auszulassen.
• Verwende explizit Keine identifiziert nur nach Prüfung; ansonsten verwende Unbekannt / Nicht verifiziert.
• Führe niemals Migrationen durch, manipuliere Produktionsdaten oder führe ein Rollback als Teil der Dokumentation durch.