# Decision Doc

> Distill a working note in the Obsidian vault ($OBSIDIAN_VAULT) into a condensed, standalone "Entscheidungen & Anforderungen" summary document with executive summary, newest-first decision register, glossary, and open points. Use when user asks for a decisions and requirements summary ("Entscheidungen & Anforderungen"), wants to condense a feature working note into a decision document, or references an existing "… — Entscheidungen & Anforderungen.md" as template.

- Skill: `jo-bity/decision-doc` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jo-bity/decision-doc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jo-bity/decision-doc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Jo-bity (https://skillmd.com/u/jo-bity)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jo-bity/decision-doc

---


# Entscheidungen & Anforderungen — Zusammenfassungsdokument

Erzeuge aus einer Arbeitsnotiz (Sessions, Grilling-Ergebnisse, PRDs, Meeting-Protokolle) ein **eigenständig lesbares, kondensiertes** Entscheidungsdokument. Referenzbeispiele im Vault: `02_Entwicklung/KYC — Entscheidungen & Anforderungen.md`, `02_Entwicklung/Onboarding API — Entscheidungen & Anforderungen.md`.

## Ablage & Sprache

- Datei: `02_Entwicklung/<Thema> — Entscheidungen & Anforderungen.md` (em-dash, kein Bindestrich).
- Deutsch; Code-/API-/Zustandsbezeichner unübersetzt in Backticks.
- Wikilinks (`[[…]]`) zu Quell-Arbeitsnotiz und verwandten Notizen; Schwester-Dokumente gegenseitig verlinken.

## Struktur (in dieser Reihenfolge)

1. **Kopf:** Erste Zeile = Anker ins Tracking (Jira-Epic-Link oder Feature-Commitment-Pfad). Danach Blockquote mit **Zweck** (ein Satz: warum dieses Dokument eigenständig lesbar sein muss — z. B. aufgelöster ADR-Kontext, revidierter Entscheidungsverlauf), **Quellen** (Arbeitsnotiz(en) mit Session-Daten, Specs, PDFs) und **Erstellt von:** Claude — `#claude-generated`.
2. **Executive Summary:** 4–6 Bullets. Was ist das System / wer owned was; Scope-Grenze; **neueste Entscheidungen hervorgehoben** (mit Datum, nummeriert ①②③ wenn mehrere aus einer Session); wichtigste offene Punkte in einem Bullet.
3. **Worum es geht:** Kurzer Prosa-Absatz + genau **ein** Mermaid-Systemkontext-Diagramm. Kernverantwortung und Abgrenzungen ("kein genereller Proxy", "System of Record") hier, nicht erst im Register.
4. **Entscheidungs-Register — neueste zuerst:** Ein Eintrag pro Architektur-/Fachentscheidung, durchnummeriert (`E-n` bzw. `ADR-n`, wenn die Quelle bereits ADR-Nummern vergibt — dann deren Nummerierung übernehmen, da Tickets sie referenzieren). Überschriftenformat: `### E-n — <Titel> <Status>, <Datum>`. Statusmarker: ✅ entschieden · ⏳ offen/vertagt · 🏷️ ADR-Kandidat · Zusatz „revidiert/amendiert <Datum>" wenn zutreffend. Je Eintrag: Entscheidung (1–3 Sätze), knapper Kontext/Begründung, *Verworfen:* Alternativen mit Grund in einer Zeile.
5. **Fachlicher Kernabschnitt** (falls vorhanden): State Machine, Zustandsmodell, Vertragsübersicht o. ä. — als Tabelle; höchstens ein weiteres Diagramm, wenn die Tabelle nicht reicht. Danach "Kernregeln" als Bullets.
6. **Glossar (Kurzfassung):** Tabelle Begriff | Bedeutung. Nur Begriffe mit Verwechslungsgefahr; Anti-Begriffe inline ("Nicht: …" / "Nicht zu verwechseln mit …").
7. **Anforderungen im Überblick:** 5–8 nummerierte, prüfbare Anforderungen — Verdichtung, keine Wiederholung des Registers.
8. **Offene Punkte:** Bullets, je Punkt der Klärungsweg/Owner ("Klärung mit X", "vertagt bis Y"). Auch bewusste Nicht-Ziele hierhin.
9. **Verwandte Notizen:** Eine Zeile, `·`-separiert, mit Rollen-Klammer je Link.

## Kondensierungs-Regeln

- **Low-Level ausschließen:** Test-Framework/Executable-Spec-Details, Fixture-/Fake-Mechanik, Implementierungs-Checklisten, GAP-/Status-Listen, CI-Details. Stattdessen bei "Verwandte Notizen" auf die Arbeitsnotiz verweisen ("inkl. Test-Framework und GAP-Analyse"). Behalte Low-Level nur, wenn es eine Entscheidung *begründet* (z. B. eine Schema-Kollision als Grund für Namens-Präfixe) — dann ein Satz.
- **Überholtes auflösen, nicht wiederholen:** Verworfene Modelle/revidierte Ziele erscheinen nur als Kontext im ersetzenden Register-Eintrag ("revidiert das X vom <Datum>"), nie als eigener Abschnitt. Das Dokument liest sich als aktueller Stand.
- **Neuestes sichtbar:** Register neueste zuerst; jüngste Entscheidungen zusätzlich im Executive Summary.
- **Ein Fakt, ein Ort:** Was im Registereintrag steht, nicht in "Weitere Entscheidungen" doppeln; ein Abschnitt "Weitere Entscheidungen" nur, wenn es entscheidungsförmige Punkte unterhalb der Register-Schwelle gibt.
- Zielgröße: deutlich kürzer als die Quelle; als Richtwert ≤ die Hälfte der Quell-Arbeitsnotiz, ~150–200 Zeilen.

## Arbeitsweise

1. Quell-Arbeitsnotiz vollständig lesen; Session-/Datumsschichten identifizieren und was wodurch überholt wurde.
2. Existierende "… — Entscheidungen & Anforderungen"-Dokumente als Stilreferenz prüfen (mind. das KYC-Dokument).
3. Dokument schreiben; Auffälligkeiten/Widersprüche in der Quelle **nicht stillschweigend korrigieren**, sondern als markierten Hinweis (⚠️) oder offenen Punkt ausweisen.
4. Dem User kurz melden: welche Entscheidungen als Register-Einträge aufgenommen, was bewusst weggelassen, welche Widersprüche gefunden.