Capability Doc
Maintain one living note per capability — the Arbeitsdokument, e.g. 02_Entwicklung/KYC/KYC — Arbeitsdokument.md — that states the current functionality and architecture — precise, not verbose. Everything for a capability lives in its folder 02_Entwicklung/<Capability>/ (Arbeitsdokument, Archiv, snapshots, ADR/). Decisions and their history live as ADR files (see the adr-log skill); this note carries only their consequences.
Update mode (default)
- Read the Arbeitsdokument, its ADR folder
02_Entwicklung/<Capability>/ADR/, and identify which ADRs/amendments are newer than the note's Stand: date.
- For each new/amended decision, determine its impact on the note. Where the impact is unambiguous, state your intended edit and proceed; where it genuinely changes understanding (behavior, boundaries, contracts), interview the user — one question at a time, with a recommended answer. Explore codebase/vault before asking anything it can answer.
- Rework by replacement: find every statement the decision invalidates and replace it. Never append dated entries, never keep both old and new ("bisher X, jetzt Y"), never narrate the change. The note must read as current truth with no archaeology required. Superseded content that is worth keeping goes to the Archiv note, not into a "legacy" section.
- Update the
Stand: DD.MM.YYYY line in the header.
The only sections allowed to carry non-current content are Offene Punkte (open questions, deliberate deferrals) — and even those get removed when resolved, not struck through.
Conversion mode (first run on a legacy working note)
When the note is still a dated append-only working note:
- Create the capability folder
02_Entwicklung/<Capability>/ and move the entire dated history verbatim into <Capability> — Archiv.md inside it, headed by a short blockquote: what this archive is, conversion date, link back to [[<Capability> — Arbeitsdokument]]. Preserve existing attribution lines; don't restamp them. Move existing snapshots ("… — Entscheidungen & Anforderungen …") into the folder too.
- Rebuild the note as
<Capability> — Arbeitsdokument.md in the capability folder from the net current state of that history plus any "Entscheidungen & Anforderungen" doc and the ADR files, per CAPABILITY-FORMAT.md. Resolve superseded statements — only the latest state survives. Renaming the note breaks [[<Capability>]] wikilinks vault-wide when done outside Obsidian — rewrite them all to [[<Capability> — Arbeitsdokument]] (grep the whole vault).
- Contradictions between sources are not silently resolved: flag them with ⚠️ under Offene Punkte or ask.
Content rules
- Structure per CAPABILITY-FORMAT.md: fixed split into Fachliche Anforderungen (business) and Technische Anforderungen (technical).
- No ADRs in here. Where the why of a statement matters, link the ADR inline (
[[KYC ADR-002 — …]]); never restate its context/alternatives.
- Wikilinks by filename: ADR files and the Archiv are linked by name (
[[KYC ADR-002 — …]], [[KYC — Archiv]]); only folder links need the path form ([[02_Entwicklung/<Capability>/ADR/|ADR-Ordner <Capability>]]).
- One fact, one place. Precise over complete — target roughly 150–250 lines; push detail into linked notes (Archiv, KYC-Process-style design docs) rather than growing this one.
- Vault conventions: German prose, code/API/state identifiers untranslated in backticks;
[[wikilink]] related notes; Mermaid liberally — at least one diagram for any flow, architecture or lifecycle (flowchart for components, sequenceDiagram for cross-service calls, stateDiagram-v2 for lifecycles), 3–8 nodes each, labelled edges, real names from the code. This note is a living document: attribution sits once in the header (gepflegt von Claude (skill: capability-doc) #claude-generated #skill/capability-doc), not per edit.
Closing
Confirm: which statements were replaced (one line each: old → new), what moved to the Archiv, the new Stand: date, and any ⚠️ contradictions left open.
1---2name: capability-doc3description: Interview the user about how the newest decisions (ADRs) change the current functionality and architecture of a capability, then rework the capability's living note in the Obsidian vault ($OBSIDIAN_VAULT) by replacing outdated statements in place — current-state only, no ADR prose, split into fachliche and technische Anforderungen. Use when the user wants to update a capability note (like KYC or Onboarding API) after new decisions, or to convert a dated append-only working note into a living capability doc.4---56# Capability Doc78Maintain one **living note per capability** — the *Arbeitsdokument*, e.g. `02_Entwicklung/KYC/KYC — Arbeitsdokument.md` — that states the *current* functionality and architecture — precise, not verbose. Everything for a capability lives in its folder `02_Entwicklung/<Capability>/` (Arbeitsdokument, Archiv, snapshots, `ADR/`). Decisions and their history live as ADR files (see the `adr-log` skill); this note carries only their **consequences**.910## Update mode (default)11121. Read the Arbeitsdokument, its ADR folder `02_Entwicklung/<Capability>/ADR/`, and identify which ADRs/amendments are newer than the note's `Stand:` date.132. For each new/amended decision, determine its impact on the note. Where the impact is unambiguous, state your intended edit and proceed; where it genuinely changes understanding (behavior, boundaries, contracts), interview the user — one question at a time, with a recommended answer. Explore codebase/vault before asking anything it can answer.143. **Rework by replacement:** find every statement the decision invalidates and replace it. Never append dated entries, never keep both old and new ("bisher X, jetzt Y"), never narrate the change. The note must read as current truth with no archaeology required. Superseded content that is worth keeping goes to the Archiv note, not into a "legacy" section.154. Update the `Stand: DD.MM.YYYY` line in the header.1617The only sections allowed to carry non-current content are **Offene Punkte** (open questions, deliberate deferrals) — and even those get *removed* when resolved, not struck through.1819## Conversion mode (first run on a legacy working note)2021When the note is still a dated append-only working note:22231. Create the capability folder `02_Entwicklung/<Capability>/` and move the entire dated history **verbatim** into `<Capability> — Archiv.md` inside it, headed by a short blockquote: what this archive is, conversion date, link back to `[[<Capability> — Arbeitsdokument]]`. Preserve existing attribution lines; don't restamp them. Move existing snapshots ("… — Entscheidungen & Anforderungen …") into the folder too.242. Rebuild the note as `<Capability> — Arbeitsdokument.md` in the capability folder from the *net current state* of that history plus any "Entscheidungen & Anforderungen" doc and the ADR files, per [CAPABILITY-FORMAT.md](./CAPABILITY-FORMAT.md). Resolve superseded statements — only the latest state survives. **Renaming the note breaks `[[<Capability>]]` wikilinks vault-wide when done outside Obsidian — rewrite them all to `[[<Capability> — Arbeitsdokument]]` (grep the whole vault).**253. Contradictions between sources are **not silently resolved**: flag them with ⚠️ under Offene Punkte or ask.2627## Content rules2829- **Structure** per [CAPABILITY-FORMAT.md](./CAPABILITY-FORMAT.md): fixed split into *Fachliche Anforderungen* (business) and *Technische Anforderungen* (technical).30- **No ADRs in here.** Where the *why* of a statement matters, link the ADR inline (`[[KYC ADR-002 — …]]`); never restate its context/alternatives.31- **Wikilinks by filename:** ADR files and the Archiv are linked by name (`[[KYC ADR-002 — …]]`, `[[KYC — Archiv]]`); only folder links need the path form (`[[02_Entwicklung/<Capability>/ADR/|ADR-Ordner <Capability>]]`).32- **One fact, one place.** Precise over complete — target roughly 150–250 lines; push detail into linked notes (Archiv, KYC-Process-style design docs) rather than growing this one.33- Vault conventions: German prose, code/API/state identifiers untranslated in backticks; `[[wikilink]]` related notes; **Mermaid liberally** — at least one diagram for any flow, architecture or lifecycle (`flowchart` for components, `sequenceDiagram` for cross-service calls, `stateDiagram-v2` for lifecycles), 3–8 nodes each, labelled edges, real names from the code. This note is a **living document**: attribution sits once in the header (`gepflegt von Claude (skill: capability-doc)` `#claude-generated #skill/capability-doc`), not per edit.3435## Closing3637Confirm: which statements were replaced (one line each: old → new), what moved to the Archiv, the new `Stand:` date, and any ⚠️ contradictions left open.
Jo-bity