HusDev/preferences-logger

Präferenzen-Logger

Menschen treffen Dutzende kleiner Entscheidungen während der Arbeit mit einem Assistenten: eine Farbe, eine Bibliothek, eine Namensregel, „nicht X tun", „Option B". Die meisten werden nie notiert, sodass die nächste Sitzung erneut nachfragt oder sie stillschweigend rückgängig macht. Dieses Skill führt eine einzige Datei, PREFERENCES.md, die jede Entscheidung im Moment des Treffens festhält und so über Sitzungen, Werkzeuge und Mitarbeiter hinweg bestehen bleibt.

Wann handeln

Lies PREFERENCES.md vor deiner ersten Änderung in einem Projekt, das eine solche Datei hat, und erneut, bevor du Designs, Optionen oder irgendetwas vorschlägst, das die Datei bereits geklärt haben könnte. Folge dem, was dort steht. Frage nicht erneut nach etwas, das die Datei bereits dokumentiert, es sei denn, der Nutzer spricht es an.

Schreibe in dieselbe Datei, im selben Schritt wie die Arbeit, wenn der Nutzer:

• eine Präferenz oder Regel angibt („Ich bevorzuge Tabulatoren", „immer britische Rechtschreibung", „niemals auf main committen");
• zwischen dir angebotenen Optionen wählt („A", „nimm die zweite", „mische A und C");
• korrigiert oder ablehnt, wie etwas gemacht wurde („sieht schlecht aus", „nein, setze es rechts", „das ist falsch, nur wenn …"), sofern die Korrektur angibt, wie es sein soll;
• eine frühere Entscheidung ändert oder umkehrt;
• etwas versuchsweise probiert („lass uns das versuchen"): dokumentiere es als Test markiert.

Nicht dokumentieren:

• einmalige Anweisungen, die nur für die aktuelle Aufgabe gelten („benenne diese Variable um");
• Fakten, die der Code oder die Historie bereits enthält (Dateistruktur, welche Bibliothek installiert ist);
• Geheimnisse, Zugangsdaten, Tokens oder persönliche Daten einer Person (Adressen, Ausweisnummern, Gesundheitsdaten). Dokumentiere die Entscheidung, nicht den privaten Wert: „verwende den echten Namen des Nutzers in der Fußzeile", niemals den Namen selbst, falls er sensibel ist;
• deine eigenen Vorschläge, die der Nutzer nicht angenommen hat.

Wenn du dir unsicher bist, ob etwas eine dauerhafte Entscheidung ist, dokumentiere es: eine kurze zusätzliche Zeile kostet weniger als eine vergessene Wahl.

Wo die Datei liegt

PREFERENCES.md im Stammverzeichnis des Projekts, es sei denn, die Agenten-Anweisungen des Projekts (CLAUDE.md, AGENTS.md oder ähnlich) nennen einen anderen Pfad. Ohne Projekt (ein einmaliger Chat) erstelle keine Datei; befolge einfach das, was der Nutzer sagt.

Wenn es noch keine Datei gibt, erstelle sie aus templates/PREFERENCES.md (neben dieser Datei) mit der ersten Entscheidung. Dann, falls das Projekt eine CLAUDE.md oder AGENTS.md hat, füge eine Zeile nahe dem Anfang ein, sodass jede zukünftige Sitzung sie liest:

Lies zuerst PREFERENCES.md und halte sie aktuell: Wann immer eine Entscheidung getroffen oder geändert wird, bearbeite ihre Zeile und füge im selben Schritt einen datierten Eintrag im Änderungsprotokoll hinzu.

Das Format

# <Projekt> — Entscheidungen

Einleitung, was diese Datei ist.

## <Thema>
- **<Kurzer Name der Entscheidung>:** was entschieden wurde, in einfachen Worten. Warum, wenn der Nutzer einen Grund nannte. (Früher: was ersetzt wurde, und wann.)

## Änderungsprotokoll
- 17. Okt. 2026 — <was entschieden oder geändert wurde, in einer Zeile> (Worte des Nutzers: „…").

Regeln, die es nützlich halten:

1. Eine Zeile pro Entscheidung, gruppiert nach Thema. Wähle Themen, die zum Projekt passen (Produkt, Design, Stack, Workflow, Schreiben …). Beginne mit wenigen und füge eines hinzu, wenn eine Entscheidung zu keinem der vorhandenen passt.
2. Direkt bearbeiten. Wenn sich eine Entscheidung ändert, überschreibe ihre Zeile mit dem, was jetzt gilt, und behalte die alte Wahl in einer kurzen „Früher: …"-Notiz. Lasse niemals zwei Zeilen, die widersprechen.
3. Füge für jede Änderung einen Eintrag im Änderungsprotokoll hinzu, den neuesten ganz unten, mit einem absoluten Datum („17. Okt. 2026", niemals „heute" oder „gestern"). Wandle relative Daten um, wenn du sie schreibst.
4. Behalte die eigenen Worte des Nutzers für den wichtigen Teil, zitiert und kurz: Sie legen später fest, was gemeint war. Lege dem Nutzer keine Worte in den Mund und lasse eine Bemerkung nicht stärker klingen, als sie war.
5. Gib den Grund an, wenn der Nutzer einen Grund genannt hat. Ein Grund ermöglicht einer späteren Sitzung, einen Fall zu behandeln, den die Regel nicht vorhergesehen hat.
6. Verlinke das, worauf die Entscheidung verweist: ein Design, ein Issue, ein Mockup, einen Commit.
7. Markiere Tests und Unbekanntes: „(wird getestet)", „(noch nicht endgültig)". Entferne die Markierung, wenn es bestätigt ist.
8. Schreibe klar. Kurze Sätze, kein Fachjargon, den der Nutzer nicht verwendet hat. Verwende den Namen der Person oder „sie", es sei denn, sie hat Pronomen genannt; rate nicht aufgrund des Namens.

Wenn eine Anfrage mit der Datei in Konflikt steht

Die neueste explizite Aussage gewinnt. Wenn der Nutzer jetzt etwas verlangt, das die Datei ausschließt, tue, was er verlangt, und aktualisiere die Zeile und das Änderungsprotokoll. Wenn es unklar ist, ob er beabsichtigte, die Regel zu ändern, frage in einer kurzen Frage nach, unter Angabe der dokumentierten Zeile.

Informiere den Nutzer kurz

Nachdem du die Datei aktualisiert hast, erwähne es in einem kurzen Satz am Ende deiner Antwort („Ich habe dies in PREFERENCES.md dokumentiert"), nicht mit einer Zusammenfassung der Datei. Zeige die vollständige Datei nur, wenn du danach gefragt wirst.

Beispiel

Der Nutzer wählt zwischen drei von dir gezeigten Sidebar-Designs und antwortet „A, aber die Buttons sollten Icons sein". Im selben Schritt wie das Erstellen:

## Design
- **Sidebar:** kompaktes Menü; die Ordnerliste füllt die verbleibende Höhe und scrollt; Einstellungen und der Datenschutzschalter sind Icon-Buttons in einer unteren Reihe (gewählt A aus den drei Optionen, mit Icon-Buttons).

## Änderungsprotokoll
- 17. Okt. 2026 — Sidebar: Option A, mit den unteren Aktionen als Icon-Buttons (Worte des Nutzers: „A, aber die Buttons sollten Icons sein").

Eine Woche später sagt der Nutzer „Füge die Labels wieder auf diese Buttons":

- **Sidebar:** … Einstellungen und der Datenschutzschalter sind Buttons mit Labels in einer unteren Reihe. (Früher: Nur-Icons, 17. Okt. 2026)

- 24. Okt. 2026 — Sidebar untere Buttons erhalten ihre Labels zurück (Worte des Nutzers: „Füge die Labels wieder auf diese Buttons").