# Capability Doc

> 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.

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

---


# 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)

1. Read the Arbeitsdokument, its ADR folder `02_Entwicklung/<Capability>/ADR/`, and identify which ADRs/amendments are newer than the note's `Stand:` date.
2. 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.
3. **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.
4. 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:

1. 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.
2. 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).**
3. Contradictions between sources are **not silently resolved**: flag them with ⚠️ under Offene Punkte or ask.

## Content rules

- **Structure** per [CAPABILITY-FORMAT.md](./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.