# Obsidian Note > Write a document or work note into the Obsidian vault ($OBSIDIAN_VAULT) — either a polished standalone document grounded in codebase research, or a dated progress/work note (newest entry first). Use when the user wants to produce technical documentation, an architecture analysis or investigation report, OR to write up what was done, log findings, record decisions, or document the outcome of an investigation/implementation. - Skill: `jo-bity/obsidian-note` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add jo-bity/obsidian-note` - Raw SKILL.md: https://api.skillmd.com/api/skills/jo-bity/obsidian-note/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: Jo-bity (https://skillmd.com/u/jo-bity) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/jo-bity/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: | Shape | When to use | Identity | |-------|-------------|----------| | **Standalone document** | A complete, one-shot piece of technical documentation, architecture analysis, or investigation report | Written once, stands on its own | | **Dated progress entry** | Recording what was investigated / decided / implemented, and what's still open | One note per work item, grown over time as dated entries (newest at the top) | 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`](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//.md` (default folder `02_Entwicklung/`) with this structure: ```markdown # > **Author:** $NOTE_AUTHOR > **Generated by:** Claude (skill: obsidian-note) — #claude-generated #skill/obsidian-note > **Date:** > **Status:** Draft — for review and alignment > **Scope:** --- ## Table of Contents 1. [Section 1](#1-section-1) 2. [Section 2](#2-section-2) ... --- ## 1. Section 1 --- ## 2. Section 2 ``` 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): ```markdown ## 2026-06-04 *Von Claude generiert (skill: obsidian-note)* #claude-generated #skill/obsidian-note **Status:** In Arbeit | Erledigt | Blockiert ### Was gemacht wurde - - ### Ergebnis - ### Offen / ToDo - [ ] --- ``` 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 | Decision | Standalone document | Dated progress entry | |----------|---------------------|----------------------| | Folder | `02_Entwicklung/` (`99_Resources/` reference, `03_Projekte/` project) | `02_Entwicklung/` | | Frontmatter | None — blockquote header instead | None | | Structure | Polished, written once | One note per work item; `## YYYY-MM-DD` entries inserted at the top (newest first) | | Filename | Human-readable Title Case, German where appropriate, `.md` | Per work item; first lines carry Jira / Miro link(s) when known | | Language | Match the topic | Match the work (German for business/process, English for code) | | Attribution | `Generated by: Claude (skill: obsidian-note) — #claude-generated #skill/obsidian-note` in header | `*Von Claude generiert (skill: obsidian-note)* #claude-generated #skill/obsidian-note` under each dated heading | | Linking | `[[Note Name]]` to related notes (required — see shared conventions) | `[[Note Name]]` to related notes (required — see shared conventions) | | Diagrams | ASCII / Mermaid where they clarify | Add Mermaid liberally — ≥1 for any flow/architecture/relationship |