How do I install the Adr Log skill?

Run npx skillmds@latest add jo-bity/adr-log in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Adr Log safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Adr Log?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Adr Log free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Adr Log?

Jo-bity (@jo-bity) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Adr Log by jo-bity — Agent Skill

Name: Adr Log
Rating: 4.2 (5 reviews)
Author: Jo-bity

Adr Log

Interview the user about the newest decisions on a capability and persist each qualifying decision as a decision record (ADR file) in the Obsidian vault ($OBSIDIAN_VAULT) under 02_Entwicklung/<Capability>/ADR/, linked to the capability's Arbeitsdokument. Decision records are append-only — amendments are appended, original rationale is never rewritten. Use when the user wants to record recent decisions as decision records, after a grilling session produced decisions worth persisting, or when converting documented decisions from a working note into decision record files.

Jo-bity Updated Sep 22, 2026

File contents

Decision Record Log

Capture the newest decisions on a capability as individual decision records in the vault. These are called decision records, not architecture decision records — the ADR prefix in file and folder names is kept purely so existing links and Jira references keep resolving. This skill is the decision register; the current-state consequences belong in the capability's Arbeitsdokument (see the capability-doc skill). Everything for a capability lives in one folder: 02_Entwicklung/<Capability>/ (Arbeitsdokument, Archiv, snapshots, ADR/).

Interview mode (default)

Interview the user about what was decided since the last recorded decision record. One question at a time, with your recommended answer for each. If a question can be answered by exploring the codebase, the vault, or a referenced Jira ticket/comment, explore instead of asking.

Identify the capability (e.g. KYC, Onboarding API) and read its ADR folder 02_Entwicklung/<Capability>/ADR/ plus the Arbeitsdokument (<Capability> — Arbeitsdokument.md) to know the last recorded state.
Ask what's new: decisions from sessions, team meetings, Jira comments, Slack threads. Chase each one down until it is precise enough to record — decision, why, rejected alternatives.
For each candidate, apply the decision record bar (see ADR-FORMAT.md). Below the bar → it belongs in the Arbeitsdokument, not here. Say so and move on.
Persist each qualifying decision as it is resolved, not batched at the end.
Distinguish new decision (new file) from change to an existing decision (append an amendment to the existing decision record — see append-only rules).

Extraction mode (conversion)

When decisions are already documented (working-note history, an "Entscheidungen & Anforderungen" doc with a decision register, Jira), extract them into decision record files without interviewing. Interview only where sources are ambiguous or contradictory. Adopt pre-existing ADR numbers when tickets or docs already reference them (e.g. "ADR-5 Option B") — those references must keep resolving.

Append-only rules

New decision → new file, next free number.
Revised/amended decision → append an ## Amendment DD.MM.YYYY — <Titel> section to the existing decision record and update its status line. Never rewrite the original decision or context — the history of the decision is the point.
Fully replaced decision → new decision record; mark the old one superseded by [[<neue ADR>]]. Deleted/withdrawn → status ❌ verworfen with one line why; never delete the file.

File format & wiring

Follow ADR-FORMAT.md for location, naming, numbering, and template. Every decision record links to the capability's Arbeitsdokument [[<Capability> — Arbeitsdokument]] (and Jira where known); add a link to the ADR folder from the Arbeitsdokument's header if missing. Vault conventions: German prose, code/API/state identifiers untranslated in backticks; [[wikilink]] every related note rather than leaving the record isolated; attribution once in the header block (*Von Claude generiert (skill: adr-log)* #claude-generated #skill/adr-log) — decision records are a standalone document, so no per-edit attribution. Never add attribution to the human's own notes, and never strip it from an entry that has it.

Closing

Confirm to the user: which decision records were created/amended (numbers + titles), which candidates were rejected as below the bar, and offer to run capability-doc to fold the consequences into the Arbeitsdokument.

---name: adr-logdescription: Interview the user about the newest decisions on a capability and persist each qualifying decision as a decision record (ADR file) in the Obsidian vault ($OBSIDIAN_VAULT) under 02_Entwicklung/<Capability>/ADR/, linked to the capability's Arbeitsdokument. Decision records are append-only — amendments are appended, original rationale is never rewritten. Use when the user wants to record recent decisions as decision records, after a grilling session produced decisions worth persisting, or when converting documented decisions from a working note into decision record files.---# Decision Record LogCapture the **newest decisions** on a capability as individual decision records in the vault. These are called **decision records**, not architecture decision records — the `ADR` prefix in file and folder names is kept purely so existing links and Jira references keep resolving. This skill is the decision *register*; the current-state consequences belong in the capability's Arbeitsdokument (see the `capability-doc` skill). Everything for a capability lives in one folder: `02_Entwicklung/<Capability>/` (Arbeitsdokument, Archiv, snapshots, `ADR/`).## Interview mode (default)Interview the user about what was decided since the last recorded decision record. One question at a time, with your recommended answer for each. If a question can be answered by exploring the codebase, the vault, or a referenced Jira ticket/comment, explore instead of asking.1. Identify the capability (e.g. KYC, Onboarding API) and read its ADR folder `02_Entwicklung/<Capability>/ADR/` plus the Arbeitsdokument (`<Capability> — Arbeitsdokument.md`) to know the last recorded state.2. Ask what's new: decisions from sessions, team meetings, Jira comments, Slack threads. Chase each one down until it is precise enough to record — decision, why, rejected alternatives.3. For each candidate, apply the decision record bar (see [ADR-FORMAT.md](./ADR-FORMAT.md)). Below the bar → it belongs in the Arbeitsdokument, not here. Say so and move on.4. Persist each qualifying decision **as it is resolved**, not batched at the end.5. Distinguish **new decision** (new file) from **change to an existing decision** (append an amendment to the existing decision record — see append-only rules).## Extraction mode (conversion)When decisions are already documented (working-note history, an "Entscheidungen & Anforderungen" doc with a decision register, Jira), extract them into decision record files without interviewing. Interview only where sources are ambiguous or contradictory. **Adopt pre-existing ADR numbers** when tickets or docs already reference them (e.g. "ADR-5 Option B") — those references must keep resolving.## Append-only rules- New decision → new file, next free number.- Revised/amended decision → append an `## Amendment DD.MM.YYYY — <Titel>` section to the **existing** decision record and update its status line. Never rewrite the original decision or context — the history of the decision is the point.- Fully replaced decision → new decision record; mark the old one `superseded by [[<neue ADR>]]`. Deleted/withdrawn → status `❌ verworfen` with one line why; never delete the file.## File format & wiringFollow [ADR-FORMAT.md](./ADR-FORMAT.md) for location, naming, numbering, and template. Every decision record links to the capability's Arbeitsdokument `[[<Capability> — Arbeitsdokument]]` (and Jira where known); add a link to the ADR folder from the Arbeitsdokument's header if missing. Vault conventions: German prose, code/API/state identifiers untranslated in backticks; `[[wikilink]]` every related note rather than leaving the record isolated; attribution once in the header block (`*Von Claude generiert (skill: adr-log)* #claude-generated #skill/adr-log`) — decision records are a **standalone** document, so no per-edit attribution. Never add attribution to the human's own notes, and never strip it from an entry that has it.## ClosingConfirm to the user: which decision records were created/amended (numbers + titles), which candidates were rejected as below the bar, and offer to run `capability-doc` to fold the consequences into the Arbeitsdokument.

Frequently asked questions