ADHD-PR-Beschreibung
Standard-PR-Body-Format für dieses Repository. Reviewende sollen die Beschreibung auf einen Blick erfassen. Der Diff ist bereits auf GitHub – wiederhole keine Dateiverschiebungen.
Agenten: Lade dieses Skill immer beim Verfassen oder Umschreiben einer Nakama-PR-Beschreibung (auch via ce-commit-push-pr). Die Form kommt von hier; sammle dennoch echte Fakten aus dem Diff (Ergebnis, Risiko, was du verifiziert hast).
Form (erforderlich)
## Zusammenfassung
<eine Zeile: wer tut was → Ergebnis. Kein Fachjargon-Nebel, es sei denn, die Änderung ist Fachjargon.>
**Vorher:** <eine Zeile – altes Verhalten oder Kosten>
**Nachher:** <eine Zeile – neues Verhalten; benenne die Schlüsselfunktion/den Pfad, falls es das Risiko hilft>
Warum sicher:
1. <Grund>
2. <Grund>
3. <Grund> <!-- max. 2–3 Punkte; Punkt 3 weglassen, wenn nichts zu sagen -->
Nur erneut hinzufügen / nachfassen wenn <ein Restrisiko oder Rollback-Trigger>.
## Testplan
- [x] <bereits ausgeführter Befehl> (<N> bestanden)
- [ ] <eine manuelle Prüfung, die ein Mensch in <2 Min> durchführen kann>
Optional nach dem Testplan (beibehalten, wenn der Workflow Compound-Engineering-Badges erwartet):
---
[](https://github.com/EveryInc/compound-engineering-plugin)
Regeln
- Lead = Ergebnis. Erster Satz der Zusammenfassung beschreibt die neue Welt, nicht „Dieser PR entfernt …“.
- Vorher/Nachher = zwei Zeilen. Fette Labels. Keine Absätze drumherum.
- Warum sicher = nummeriert, ≤3. Maximal 5 Aufzählungspunkte insgesamt im Body; wenn mehr, nur die entscheidungsrelevanten behalten.
- Ein Restrisiko. Nenne den Fall, der dich zum Rückgängigmachen bewegen würde. Weglassen, wenn es wirklich keinen gibt.
- Kein Diff-Tourismus. Führe keine Dateien, Zeilenanzahlen als Erzählung oder „auch Exports aufgeräumt“ auf, es sei denn, das ist das Risiko.
- Testplan = ausführbar. Bevorzuge angehakte Befehle mit Durchlaufzahlen; eine nicht angehakte manuelle Prüfung.
- Titel bleibt konventionell.
type(scope): imperativ– kurz. Der Body trägt diese Form; der Titel braucht weder Emojis noch Aufsätze. - Anwenden mit
gh. Schreibe Body in eine temporäre Datei;gh pr edit <n> --body-file …odergh pr create --body-file …. Niemals--body "$(cat …)".
Goldenes Beispiel
Diese Dichte erreichen:
## Zusammenfassung
Organisationsspeicher-Vorschlag genehmigen → Punkt wird in `MEMORY.md` übernommen. Kein LLM-Aufruf.
**Vorher:** deterministischer Merge, dann optionale Modell-Neuschreibung der gesamten Datei.
**Nachher:** nur deterministischer Merge (`applyApprovedOrgMemoryBullet`).
Warum sicher:
1. Deduplizierung + Überschreibung leben bereits in dieser Funktion
2. LLM-Pfad ist bereits fehlgeschlagen und auf das deterministische Ergebnis zurückgefallen
3. −230 Zeilen, gleiches Genehmigungs-Ergebnis
Nur erneut hinzufügen eines LLM-Rewrites, wenn widersprüchliche Punkte die Genehmigung überleben.
## Testplan
- [x] `bun test packages/agent/src` (80 bestanden)
- [x] `bun test apps/server/src/services/org-memory-service.test.ts` (15 bestanden)
- [ ] Einen ausstehenden Vorschlag genehmigen (angeheftet + letztes Log) – Punkt landet wie zuvor
Anti-Patterns
| Nicht | Sondern |
|---|---|
| Mehrere Absätze in der Zusammenfassung | Eine Ergebniszeile + Vorher/Nachher + Warum sicher |
| „Dieser PR zielt darauf ab …“ / „Um … zu …“ | Beginne mit dem Verb oder der Benutzeraktion |
Verschachtelte ### unter Zusammenfassung | Nur flaches ## Zusammenfassung + ## Testplan |
| Wiederholung jeder gelöschten Datei | Nur Restrisiko |
| Vages „Tests bestanden“ | Exakter Befehl + Durchlaufzahl |
Workflow
- Lies den PR-Diff / die Commits (
gh pr view,git diff base...HEAD) - Bestimme: Ergebnis, Vorher, Nachher, ≤3 Warum-sicher, ein Restrisiko
- Fülle die Vorlage – streiche jeden Satz, den der Diff bereits beweist
- Wende via
--body-filean - Antworte mit der PR-URL (plus „sag Bescheid, wenn du den Titel gestrafft haben willst“ nur falls nützlich)