# Requirements Snapshot

> Create a dated, standalone "Entscheidungen & Anforderungen" snapshot for a capability from its living capability note and its ADR folder in the Obsidian vault ($OBSIDIAN_VAULT) — executive summary, decision register resolved from the ADR files (newest first), requirements, open points. Use when the user asks for a requirements snapshot or "Entscheidungen & Anforderungen" for a capability managed with adr-log + capability-doc; for legacy working notes without an ADR folder, the older decision-doc skill applies instead.

- Skill: `jo-bity/requirements-snapshot` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jo-bity/requirements-snapshot`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jo-bity/requirements-snapshot/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/requirements-snapshot

---


# Requirements Snapshot — Entscheidungen & Anforderungen

Produce a **dated, immutable snapshot** that a ticket reader can consume standalone — especially with **resolved ADR context**, since Jira tickets reference ADRs only by number. Reference examples: `02_Entwicklung/KYC/KYC — Entscheidungen & Anforderungen (17.07.2026).md`, `02_Entwicklung/Onboarding API/Onboarding API — Entscheidungen & Anforderungen (17.07.2026).md`.

## Sources

Everything sits in the capability folder `02_Entwicklung/<Capability>/`:

1. The Arbeitsdokument `<Capability> — Arbeitsdokument.md` (current state, fachlich/technisch)
2. All ADRs in `ADR/` including amendments and statuses
3. `<Capability> — Archiv.md` only when a register entry needs context neither of the above carries

Read all ADRs in full — the register is *resolved from the ADR files*, not from memory of the sessions.

## Ablage & Sprache

- Datei: `02_Entwicklung/<Capability>/<Thema> — Entscheidungen & Anforderungen (DD.MM.YYYY).md` — im Capability-Ordner, Datum im Namen, em-dash. Snapshots sind **unveränderlich**: neuer Stand = neue Datei mit neuem Datum; die neue verlinkt die Vorgängerin unter "Verwandte Notizen", ersetzt sie aber nicht.
- Update the `Snapshot:` link in the Arbeitsdokument's header to point at the newest snapshot.
- Deutsch; Code-/API-/Zustandsbezeichner unübersetzt in Backticks. Wikilinks zum Arbeitsdokument (`[[<Capability> — Arbeitsdokument]]`), ADR-Ordner (`[[02_Entwicklung/<Capability>/ADR/|ADR-Ordner <Capability>]]`) und verwandten Notizen.

## Struktur (in dieser Reihenfolge)

1. **Kopf:** Erste Zeile = Anker ins Tracking (Jira-Epic / Feature-Commitment). Danach Blockquote mit **Zweck** (ein Satz), **Quellen** (Arbeitsdokument, ADR-Ordner, ggf. Archiv/Specs), **Stand:** DD.MM.YYYY und **Erstellt von:** Claude (skill: requirements-snapshot) — `#claude-generated #skill/requirements-snapshot`.
2. **Executive Summary:** 4–6 Bullets — was das System ist / wer owned was; Scope-Grenze; **neueste Entscheidungen hervorgehoben** (mit Datum); wichtigste offene Punkte in einem Bullet.
3. **Worum es geht:** kurzer Prosa-Absatz + genau **ein** Mermaid-Systemkontext-Diagramm (aus der Capability-Note übernehmen/verdichten).
4. **Entscheidungs-Register — neueste zuerst:** ein Eintrag pro ADR, **mit der ADR-Nummerierung der Dateien** (Tickets referenzieren sie). Überschrift: `### ADR-n — <Titel> <Status>, <Datum>`; Statusmarker wie im ADR (✅ / ⏳ / ❌ / „amendiert DD.MM.YYYY"). Je Eintrag: Entscheidung (1–3 Sätze), knapper Kontext, *Verworfen:* Alternativen in einer Zeile, Wikilink auf die ADR-Datei. Amendments in den Eintrag auflösen — der Eintrag liest sich als aktueller Stand, mit „amendiert"-Vermerk.
5. **Fachlicher Kernabschnitt** (falls vorhanden): State Machine / Vertragsübersicht als Tabelle; danach „Kernregeln" als Bullets. Aus dem Fachlich-Teil des Arbeitsdokuments verdichten.
6. **Glossar (Kurzfassung):** Tabelle Begriff | Bedeutung; nur Verwechslungsgefahr, Anti-Begriffe inline.
7. **Anforderungen im Überblick:** 5–8 nummerierte, prüfbare Anforderungen — Verdichtung, keine Register-Wiederholung.
8. **Offene Punkte:** aus Arbeitsdokument + offenen ADRs; je Punkt Klärungsweg/Owner.
9. **Verwandte Notizen:** eine Zeile, `·`-separiert, Rollen-Klammer je Link — inkl. Vorgänger-Snapshot.

## Kondensierungs-Regeln

- Zielgröße ~150–200 Zeilen; deutlich kürzer als Arbeitsdokument + ADRs zusammen.
- **Ein Fakt, ein Ort:** Registereintrag nicht in den Anforderungen doppeln.
- Low-Level (Test-Mechanik, Implementierungs-Checklisten, CI) raus; behalten nur, wenn es eine Entscheidung *begründet* — dann ein Satz.
- Widersprüche zwischen Arbeitsdokument und ADRs **nicht stillschweigend korrigieren** — als ⚠️-Hinweis oder offenen Punkt ausweisen.

## Closing

Dem User melden: Dateiname, welche ADRs ins Register aufgenommen (Nummern), was bewusst weggelassen, welche Widersprüche gefunden, und dass der `Snapshot:`-Link im Arbeitsdokument aktualisiert wurde.