decision-logger
von alirezarezvanidecision-logger ist ein Decision Support Skill für genehmigte Board-Entscheidungen. Er trennt Rohtranskripte von einem Layer 2-Entscheidungsindex, verfolgt Verantwortliche, Fristen, verworfene Optionen und Follow-ups und enthält einen Python-Tracker für Zusammenfassungen, überfällige Einträge, Konflikte, Owner-Filter und Suche.
Dieser Skill erreicht 80/100 Punkte und ist damit ein solider Kandidat für Verzeichnisnutzer, die strukturierte Board-Entscheidungshistorien und die Prüfung von Action Items benötigen. Er bietet mehr Agenten-Nutzen als ein generischer Prompt, weil er klare Trigger, ein dauerhaftes Format für genehmigte Entscheidungen und ein Reporting-Skript mitbringt. Am einfachsten ist die Einführung jedoch innerhalb des umgebenden C-Level Advisor-Workflows.
- Klare Auslösebedingungen in der Beschreibung: nach Board-Meetings, bei der Prüfung genehmigter Entscheidungen oder bei der Kontrolle überfälliger Aufgaben.
- Es gibt operative Substanz: SKILL.md definiert ein zweistufiges Modell für rohe und genehmigte Entscheidungsspeicher, Commands, Keywords und Anwendungsfälle.
- Enthält ausführbare Unterstützung über scripts/decision_tracker.py sowie eine Vorlage für Entscheidungseinträge mit Feldregeln für konsistente Layer 2-Einträge.
- Am Skill-Pfad gibt es keinen Installationsbefehl und kein README. Nutzer müssen die Installation daher aus der Struktur des größeren Repository ableiten.
- Der Workflow wirkt auf das C-Level Advisor-/Board-Meeting-Ökosystem und Slash-Commands wie /cs:decisions und /cs:review zugeschnitten, was den eigenständigen Nutzen einschränken kann.
Überblick über den decision-logger skill
Was decision-logger leistet
decision-logger ist ein Decision Support skill, der Ergebnisse aus Board-Meetings in ein dauerhaftes, zweistufiges Entscheidungsarchiv überführt. Layer 1 bewahrt den rohen Meeting-Kontext auf; Layer 2 enthält ausschließlich freigegebene Entscheidungen, Verantwortliche, Fristen, verworfene Optionen und Follow-up-Punkte. Der praktische Nutzen: Künftige KI-gestützte Meetings sollen sich auf bestätigte Entscheidungen stützen, nicht auf offene Diskussionen oder halluzinierten Konsens.
Besonders geeignet für Board- und Executive-Workflows
Der decision-logger skill eignet sich besonders für Gründer, Chiefs of Staff, Board-Operatoren und KI-Agenten, die wiederkehrende Executive-Meetings unterstützen. Er passt zu Workflows, in denen Entscheidungen über mehrere Meetings hinweg Bestand haben, später durchsuchbar sein und klar von Diskussionsnotizen getrennt bleiben müssen. Besonders nützlich ist er, wenn ein Prozess im Stil von board-meeting mit der Freigabe durch den Founder endet und anschließend ein sauberer, nachvollziehbarer Datensatz gebraucht wird.
Wichtigstes Unterscheidungsmerkmal: nur freigegebener Speicher
Die stärkste Designentscheidung ist die Trennung zwischen Rohtranskripten und dem freigegebenen Layer-2-Index. Spätere Reviews lesen die freigegebene Ebene, nicht jedes Argument aus dem Meeting. So wird verhindert, dass früher verworfene Ideen wieder auftauchen, als wären sie weiterhin realistische Optionen. Das Template enthält außerdem DO_NOT_RESURFACE, Felder für Supersession, Review-Daten und Owner-Tracking. Dadurch ist es deutlich operativer als ein generischer Prompt zum „Meeting-Notizen zusammenfassen“.
Was vor der Installation zu prüfen ist
Bevor du decision-logger einführst, solltest du sicherstellen, dass dein Team bereit ist, einen lokalen Entscheidungsindex unter ~/.claude/decisions/approved/decisions.md zu pflegen. Der mitgelieferte Python-Helper liest diese Datei und kann überfällige Punkte, Konflikte, owner-spezifische Actions und Keyword-Suchen ausgeben. Wenn euer Prozess freigegebene Entscheidungen nicht klar von Diskussionsnotizen trennt, müsst ihr möglicherweise zuerst euren Meeting-Workflow anpassen.
So verwendest du den decision-logger skill
decision-logger installieren und zuerst diese Dateien prüfen
Installiere den Skill aus dem Repository-Pfad:
npx skills add alirezarezvani/claude-skills --skill decision-logger
Lies nach der Installation diese Dateien in der folgenden Reihenfolge:
SKILL.md— erklärt das zweistufige Speichermodell, die Absicht der Slash-Commands und die erwarteten Speicherorte.templates/decision-entry.md— zeigt das exakte Format für einen Layer-2-Eintrag.scripts/decision_tracker.py— stellt Reporting-Befehle für Zusammenfassungen, überfällige Punkte, Konflikte, Owner-Filter und Suche bereit.
Das Skript verwendet nur die Python-Standardbibliothek. Abgesehen von einer verfügbaren Python-Installation ist also kein Dependency-Setup nötig.
Welche Inputs der Skill für gute Ergebnisse braucht
Für eine starke Nutzung von decision-logger solltest du dem Agenten mehr geben als eine grobe Meeting-Zusammenfassung. Liefere den Agendapunkt, die final freigegebene Entscheidung, den verantwortlichen Owner, Due Date, Review Date, Begründung, abgelehnte Alternativen und mögliche Founder-Overrides. Das Template erwartet eine Entscheidung pro Eintrag; gebündelte Ergebnisse sollten daher in getrennte Datensätze aufgeteilt werden.
Schwacher Input: „Logge, dass wir über Pricing gesprochen und beschlossen haben, etwas zu testen.“
Besserer Input: „Logge die freigegebene Entscheidung aus dem Board-Meeting vom 2026-03-05: Wechsel von Flat Pricing zu einem dreistufigen Pilotmodell für Neukunden. Owner: CRO. Deadline: 2026-04-15. Review: 2026-05-01. Rationale: verbessert den Expansion Path und begrenzt gleichzeitig das Migrationsrisiko. Rejected: sofortige Migration aller Bestandskunden, weil die Support-Last zu hoch ist. Raw transcript path: ~/.claude/decisions/raw/2026-03-05-pricing.md.“
Praktischer Ablauf nach einem Meeting
Nutze decision-logger nach der Freigabe, nicht während einer offenen Debatte. Ein belastbarer Workflow sieht so aus:
- Speichere oder referenziere das Rohtranskript in Layer 1.
- Bitte den Agenten, ausschließlich founder-approved Outcomes zu extrahieren.
- Erstelle mit
templates/decision-entry.mdeinen Layer-2-Eintrag. - Markiere verworfene Optionen mit Gründen und
DO_NOT_RESURFACE. - Führe das Tracker-Skript aus, um Zusammenfassungen, überfällige Actions oder Konflikte zu prüfen.
Nützliche Befehle aus dem Repository sind:
python scripts/decision_tracker.py --demopython scripts/decision_tracker.py --summarypython scripts/decision_tracker.py --overduepython scripts/decision_tracker.py --conflictspython scripts/decision_tracker.py --owner "CTO"python scripts/decision_tracker.py --search "pricing"python scripts/decision_tracker.py --due-within 7
Prompt-Muster für bessere Einträge
Eine gute Anweisung sollte einen Entscheidungseintrag verlangen, keine erzählende Zusammenfassung. Zum Beispiel:
„Use the decision-logger skill to create a Layer 2 approved decision entry. Include one clear decision statement, one accountable owner, deadline, review date, rationale, rejected proposals with DO_NOT_RESURFACE, action items, supersedes fields if applicable, and the raw transcript path. Do not include unapproved discussion points.“
Diese Rahmung reduziert Mehrdeutigkeit und hält Layer 2 sauber genug, damit spätere Decision Support Workflows darauf aufbauen können.
FAQ zum decision-logger skill
Ist decision-logger nur für Board-Meetings gedacht?
Er ist auf Entscheidungswissen für Boards und C-Level ausgerichtet, kann aber auch für Investment Committees, Leadership Staff Meetings, Product Councils oder Governance Reviews funktionieren. Entscheidend ist, dass Entscheidungen formell freigegeben werden und Follow-up benötigen. Weniger nützlich ist er für Brainstorming-Sessions, in denen keine finale Entscheidung getroffen wird.
Warum ist das besser, als KI einfach Meeting Minutes zusammenfassen zu lassen?
Eine normale Zusammenfassung vermischt häufig Diskussionen, Empfehlungen, Einwände und Entscheidungen. decision-logger erzwingt Struktur: freigegebene Entscheidung, Owner, Deadline, Rationale, verworfene Optionen, Action Items, Supersession und Link zum Rohtranskript. Genau diese Struktur ermöglicht später Reviews, Overdue Checks und Konflikterkennung.
Benötigt der decision-logger skill eine Datenbank?
Nein. Die Repository-Hinweise sprechen für markdown-basierten Speicher und ein Python-Skript auf Basis der Standardbibliothek. Der zentrale Layer-2-Index wird unter ~/.claude/decisions/approved/decisions.md erwartet; für Legacy-Zwecke wird über --file ein weiterer Dateipfad unterstützt. Das macht den Ansatz leichtgewichtig. Teams, die Multi-User-Berechtigungen, Dashboards oder Audit Logs benötigen, brauchen jedoch möglicherweise zusätzliche Tools.
Wann sollte ich decision-logger nicht verwenden?
Nutze ihn nicht als Ablageort für jede Meeting-Notiz. Er passt auch schlecht, wenn sich Entscheidungen ständig ohne Owner oder Daten ändern oder wenn eure Organisation nicht klar benennen kann, was tatsächlich freigegeben wurde. In solchen Fällen ist ein Meeting-Notes-Skill oder eine Projektmanagement-Integration oft sinnvoller, bevor ihr Decision Memory ergänzt.
So verbesserst du den decision-logger skill
Bessere decision-logger Ergebnisse durch klarere Freigaben
Der wichtigste Qualitätsfaktor ist Freigabeklarheit. Prüfe vor dem Loggen: Was genau wurde entschieden? Wer ist verantwortlich? Bis wann? Was wurde ausdrücklich verworfen? Was sollen zukünftige Agenten nicht wieder aufbringen? Wenn eine dieser Angaben fehlt, stelle lieber eine Rückfrage, statt einen vagen Eintrag zu erstellen.
Häufige Fehlerquellen vermeiden
Achte auf Einträge, die mehrere Entscheidungen in einem Absatz enthalten, geteilte Verantwortung ohne eindeutig accountable Person, Deadlines wie „bald“, Begründungen, die nur die Entscheidung wiederholen, oder abgelehnte Ideen ohne Gründe. Das schwächt spätere Suche und Reviews. Die Feldregeln des Templates solltest du als Constraints behandeln, nicht als unverbindliche Vorschläge.
Nach dem ersten generierten Eintrag iterieren
Nachdem der Agent einen Eintrag entworfen hat, prüfe ihn wie einen operativen Datensatz. Verdichte die Entscheidung auf einen Satz, wandle Namen oder Rollen in einen einzigen Owner um, ersetze relative Datumsangaben durch YYYY-MM-DD und stelle sicher, dass Action Items überprüfbar sind. Führe anschließend --summary, --overdue oder --conflicts aus, um zu prüfen, ob der Eintrag im Tracker sauber funktioniert.
Den Skill an dein Operating Model anpassen
Teams können decision-logger verbessern, indem sie konsistente Agenda-Tags, Board-Committee-Labels, Risk Level, Decision Type oder Links zu Project Tickets ergänzen. Halte Erweiterungen kompatibel mit dem Markdown-Index und füge keine Felder hinzu, die später niemand pflegt. Ziel ist nicht mehr Dokumentation um ihrer selbst willen, sondern sauberer Decision Support für das nächste Meeting.