Obsidian Note

Style: Focus on conciseness in your output. Stay brief, but never sacrifice semantics (meaning) for conciseness.

Obsidian Note Skill

Write into the user's Obsidian vault at $OBSIDIAN_VAULT/. This skill produces two note shapes — pick the one that matches the request:

If unsure: a polished deliverable that stands alone → standalone document; an accumulating log of ongoing work → dated progress entry.

Vault conventions

Follow the shared vault conventions in references/obsidian-conventions.md — folders, no frontmatter, note identity, attribution (use skill name obsidian-note), [[wikilink]] cross-referencing, language, Mermaid, and the closing confirmation.

Both shapes default to 02_Entwicklung/. For a standalone document, use 99_Resources/ for durable reference material, or 03_Projekte/ when it clearly belongs to a specific project.

Shape A — Standalone document

A polished note written once that stands on its own (not appended). Attribution goes into the blockquote header, not a dated line.

Step 1: Plan the document

From the topic in $ARGUMENTS, determine:

• What areas of the codebase need to be researched
• What sections the document should contain
• The target vault folder (default 02_Entwicklung/)
• The filename — human-readable Title Case, spaces allowed, German where appropriate, ending in .md

Step 2: Research the codebase

Launch one or more Explore agents in parallel, each targeting a specific service, bounded context, or concern area.

• Be thorough: read actual code, not just file names
• Look at domain models, APIs, connectors, configuration, and tests
• Collect concrete details: field names, class names, file paths, data flows
• Do NOT write generic content — every claim must be grounded in codebase findings

Wait for all research agents to complete before proceeding.

Step 3: Write the document

Create $OBSIDIAN_VAULT/<folder>/<Document Title>.md (default folder 02_Entwicklung/) with this structure:

# <Document Title>

> **Author:** $NOTE_AUTHOR
> **Generated by:** Claude (skill: obsidian-note) — #claude-generated #skill/obsidian-note
> **Date:** <today's date in YYYY-MM-DD format — available in context>
> **Status:** Draft — for review and alignment
> **Scope:** <list of services/bounded contexts covered>

---

## Table of Contents

1. [Section 1](#1-section-1)
2. [Section 2](#2-section-2)
...

---

## 1. Section 1

<content>

---

## 2. Section 2

<content>

Quality requirements:

• Professional tone — no emojis, no filler
• Numbered sections with clear headings
• Tables for comparisons, field mappings, side-by-side analysis
• Code blocks for technical details (Java classes, YAML configs, JSON payloads)
• ASCII diagrams for data flows, architecture, component relationships
• Concrete file paths when referencing specific code
• Actionable content — analysis and recommendations where appropriate, not just description
• [[Note Name]] links to related vault notes where relevant

Step 4: Summarize

Tell the user the vault path, the sections covered, and any areas that warrant further investigation.

Shape B — Dated progress entry

Durable work notes that accumulate over time under one note per work item, newest entry first. Find or create that note per the shared conventions, then:

Step 1: Ground the content in the actual work

Progress notes must reflect what was actually done or found — not generic description.

• If you did the work in this session, summarize the real changes: concrete file paths, class names, fields, endpoints, config keys, decisions, and open questions.
• If documenting an investigation, cite the specific code you read (service/path/File.java), the data flow you traced, and the conclusion.
• Prefer the same concrete, bullet-driven style as existing notes over prose paragraphs.

Step 2: Write the dated entry

Insert the entry at the top of the note — directly below the header lines (Jira/Miro links), above the previously newest entry — using a date heading (today is available in context), with a --- separator between it and the older entries. Choose the language to match the work: German for partner/business/process topics (consistent with the vault), English when the content is purely code/technical detail and reads more naturally that way. Match whatever language the rest of the note already uses when adding to an existing note.

Template (adapt headings to the content; omit sections that don't apply):

## 2026-06-04

*Von Claude generiert (skill: obsidian-note)* #claude-generated #skill/obsidian-note

**Status:** In Arbeit | Erledigt | Blockiert

### Was gemacht wurde
- <concrete change / finding, with file path or class name>
- <decision taken and the reasoning>

### Ergebnis
- <outcome, e.g. tests passing, endpoint now returns X, behaviour confirmed>

### Offen / ToDo
- [ ] <next step or open question>

---

Rules for the entry (see shared conventions for attribution, [[wikilink]] referencing, Mermaid):

• No emojis, no filler. Concise and factual.
• Use - [ ] checkboxes for open items so they're trackable in Obsidian.
• Use code blocks for snippets (Java, YAML, JSON) and tables for field mappings / comparisons.
• Place any Mermaid diagram next to the prose it illustrates, inside the relevant ### subsection.

Step 3: Confirm

Tell the user the note path, whether you created the note or added an entry, a one-line summary of what was recorded, and which related notes you linked. Surface any open ToDos you added.

Quick reference