Aufgaben-Zusammenfassung
Jede abgeschlossene Aufgabe endet mit einer Zusammenfassung: das Letzte in der Antwort, nach allen Tool-Aufrufen. Sie teilt dem Leser in zehn Sekunden mit, was jetzt wahr ist, wie wir das wissen und was noch offen ist. Sie ist eine Zusammenfassung, kein Arbeitsprotokoll.
Falls das aktuelle Projekt eine eigene task-recap-Fähigkeit besitzt, folge stattdessen dieser: Sie enthält die projektspezifischen Prüfnamen und Konventionen.
Vorlage
### <Status> <Titel: was jetzt wahr ist, ≤ 8 Wörter>
<Einer oder zwei Sätze: das Ergebnis und warum es wichtig ist. Keine Prozessbeschreibung.>
**Änderungen**
- [`Datei.ext`](Pfad/zu/Datei.ext) — was geändert wurde, in wenigen Worten
- [`Andere.ext`](Pfad/zu/Andere.ext:42) — …
**Prüfungen** · `build ✓` · `tests 14/14 ✓` · `lint ✓`
**Nächstes** — <der eine offene Punkt, Entscheidung oder Folgeschritt>
Status-Glyphe
Genau eine Glyphe, nur in der Überschrift:
| Glyphe | Bedeutung |
|---|---|
| ✅ | Erledigt und verifiziert |
| ⚠️ | Erledigt, aber etwas ist unverifiziert oder eine Prüfung fehlgeschlagen |
| ⛔ | Blockiert: konnte nicht fertiggestellt werden (Grund in der Zusammenfassung nennen) |
| 🔎 | Untersuchung oder Frage beantwortet, kein Code geändert |
Abschnitte
- Titel — das Ergebnis, nicht die Tätigkeit: "Suchergebnisse behalten ihre Reihenfolge", nicht "Fehler in SearchService behoben".
- Zusammenfassung — ein oder zwei Sätze. Nenne zuerst den für den Benutzer sichtbaren Effekt, dann die Ursache oder den Ansatz, falls dieser nicht offensichtlich ist.
- Änderungen — ein Aufzählungspunkt pro Datei oder logischer Gruppe, höchstens 6; den Rest zusammenfassen ("+ 4 Übersetzungen in
Localizable.xcstrings"). Dateien sind Markdown-Links relativ zum Arbeitsverzeichnis, mit:Zeile, wenn eine bestimmte Stelle wichtig ist. Den Abschnitt weglassen, wenn nichts geändert wurde. - Prüfungen — eine Zeile mit Inline-Code-Badges, nur für das, was in dieser Aufgabe tatsächlich ausgeführt wurde, benannt nach den eigenen Werkzeugen des Projekts:
build ✓/build ✗,tests N/M ✓,ui ✓(UI- oder End-to-End-Tests),lint ✓,types ✓(Typprüfer),changelog ✓, plus jede Prüfung, die die Projektanweisungen erfordern (z. B. eine Übersetzungsprüfung).- Eine Prüfung, die zutrifft, aber nicht ausgeführt wurde, wird als
build –geschrieben und in Nächstes oder der Zusammenfassung genannt. Niemals mit ✓ markieren, was nicht ausgeführt wurde. - Die Zeile bei reinen Dokumentations- oder Untersuchungsaufgaben weglassen.
- Nächstes — eine Zeile: die Entscheidung, die auf den Benutzer wartet, der Folgeschritt oder der Git-Status (
uncommitted on main,PR open). Weglassen, wenn nichts ansteht.
Regeln
- Kurz: insgesamt 4–12 Zeilen. Wenn mehr nötig ist, ist die Änderungsliste zu detailliert; fasse sie zusammen.
- Ehrlich: ein fehlgeschlagener Test oder ein übersprungener Schritt wird klar mit ⚠️ angegeben, niemals versteckt.
- Keine Erzählung: kein "Ich habe zuerst … angesehen, dann …". Keine Wiederholung der Anfrage. Keine abschließenden Höflichkeitsfloskeln oder "lassen Sie mich wissen, ob …".
- Keine Codeblöcke, es sei denn, der Benutzer muss einen Befehl ausführen; dann ein
bash-Block mit einem Befehl, platziert nach Nächstes. - Nur einfaches Markdown: eine
###-Überschrift, fette Beschriftungen, Aufzählungspunkte, Inline-Code. Keine Tabellen, keine zusätzlichen Emojis, keine horizontalen Linien. - Schreibe in der Sprache, die der Benutzer verwendet hat; behalte Dateinamen, Code und Badge-Beschriftungen auf Englisch.
- Verweise auf PRs und Issues als vollständige Links (
[owner/repo#94](https://github.com/owner/repo/pull/94)), niemals bloß#94. - In der Claude-Desktop-App ist die Zusammenfassung die abschließende Nachricht, die nach dem
wrap_up-Aufruf geschrieben wird; sie wiederholt nicht die im nächsten-Schritt-Fenster angezeigte Frage.
Beispiele
Ein Feature:
### ✅ Profilbildschirm zeigt das Beitrittsdatum
Jedes Profil zeigt jetzt an, wann der Benutzer beigetreten ist, unter dem Namen, formatiert für die Locale des Benutzers.
**Änderungen**
- [`ProfileHeader.swift`](Sources/Profile/ProfileHeader.swift) — Beitrittsdatum-Label
- [`Localizable.xcstrings`](Sources/Profile/Resources/Localizable.xcstrings) — `Joined %@`-String
- [`CHANGELOG.md`](CHANGELOG.md) — Eintrag unter Unreleased
**Prüfungen** · `build ✓` · `tests 32/32 ✓` · `lint ✓`
**Nächstes** — uncommitted on `feature/profile-join-date`; bereit zum Öffnen des PRs.
Ein Teilergebnis:
### ⚠️ Upload-Fortschritt überlebt Hintergrundwechsel
Der Fortschritt wird jetzt von den vom Server bestätigten Bytes abgeleitet, nicht von einem lokalen Zähler, sodass er nach dem Suspendieren der App korrekt bleibt.
**Änderungen**
- [`UploadViewModel.swift`](Sources/Upload/UploadViewModel.swift:58) — Fortschritt von `acknowledgedBytes` gelesen
**Prüfungen** · `build ✓` · `tests 11/12 ✗` · `lint ✓`
**Nächstes** — `testPauseResume` erwartet immer noch den alten Zähler; aktualisieren oder altes Pausenverhalten beibehalten?
Eine Untersuchung:
### 🔎 Dashboard hakt, weil der Cache zu spät speichert
Das Dashboard liest den Cache, bevor der Hintergrundspeichervorgang abgeschlossen ist, also zeigt es die vorherigen Daten bis zum nächsten Refresh.
**Nächstes** — Fehlerbehebung durch Aktualisieren nach Abschluss des Speichervorgangs in `SyncService`; hier durchführen?