Obsidian Save

Obsidian Save

Summarize the whole current conversation and save it into the user's Obsidian vault as one note per topic — if a prior session already saved a note on the same topic, update that same file (adding a dated log entry for what's new) rather than creating a new dated file. Then report the saved file's path back to the user.

Configuration (fixed — do not ask again)

• Vault path: /Users/isac/Documents/obsidian-docs
• Target folder (relative to vault): claude-conversations
• Full target directory: /Users/isac/Documents/obsidian-docs/claude-conversations
• Filename pattern: <topic-slug>.md — no date prefix. The filename is the topic's stable identity, not tied to which day it was written.
  • <topic-slug> = a short kebab-case slug (2-5 words) auto-derived from what the conversation is actually about. Do not ask the user for it — generate it yourself.
  • Date still matters, just not in the filename — it lives in frontmatter (created, updated) and in the dated log entries inside the file (see Steps below).
• After saving, always report the plain absolute local file path back to the user (not an obsidian:// URI).

Steps

1. Ensure the target folder exists. mkdir -p /Users/isac/Documents/obsidian-docs/claude-conversations

2. Capture the session ID. Run echo $CLAUDE_CODE_SESSION_ID to get the current Claude Code session's UUID. If the variable is somehow empty (e.g. running outside Claude Code's CLI), skip the session-ID-related frontmatter/lines below rather than writing a blank/invalid value — never block saving the note on this.

3. Find out if this topic already has a note. List the target folder (ls /Users/isac/Documents/obsidian-docs/claude-conversations) and check whether an existing file is about the same topic/project as the current conversation:

   • First check for an obvious filename match on the slug you'd naturally generate.
   • If nothing obviously matches by name, and there are only a few candidate files, skim their titles/first lines to judge whether any is a continuation of the same subject (e.g. the same project, same ongoing task) rather than a coincidentally similar-sounding but distinct topic. When genuinely unsure whether two topics are "the same," prefer treating them as separate rather than merging unrelated content into one file.
   • Found a match → that file's exact existing filename is your target; you are updating it (go to step 4a).
   • No match → you are creating a new note (go to step 4b).

4a. Updating an existing note. Read the full existing file first. Then:

• Update the frontmatter's updated: date to today; leave created: as it was.
• Add the current session's ID to a session_ids: frontmatter list (create this list from the old singular session_id field if the note predates that change; never drop a previously-recorded session ID).
• Rewrite the top-level ## Summary so it reflects the current overall state of the topic — not just today's slice. This section should always answer "what is this and where does it stand now," even if that means folding in or lightly rephrasing what was there before.
• Merge ## Key points and ## Action items / follow-ups sensibly: fold in what's new, remove/check off action items that this session resolved, don't duplicate points that already exist.
• Append a new dated entry under a ## Session Log section at the bottom (create this section if the note predates it) — see the template below. This is where day-specific decisions, updates, or narrower events belong, so the top-level sections above can stay a clean current-state summary instead of accumulating every day's blow-by-blow.
• Only add a Session Log entry when there's something distinct worth dating (a decision made, a change of direction, a concrete update) — a session that added nothing beyond what the updated Summary/Key points already cover doesn't need one.

4b. Creating a new note. Write a fresh file with this structure:

---
created: <yyyy-mm-dd>
updated: <yyyy-mm-dd>
tags: [claude-conversation]
session_ids: [<uuid from step 2>]
---

# <Human-readable title>

**Resume latest session:** `claude --resume <uuid from step 2>`

## Summary
<2-6 sentence overview of what this topic is and where it currently stands>

## Key points
- <bullet list of notable decisions, facts, findings, or steps taken>

## Action items / follow-ups
- <anything left open or for the user to do next — omit this section if none>

Keep it factual and grounded in what actually happened — do not invent details. A short conversation can skip straight to a brief Summary with no Key points section.

Session Log entry template (used in step 4a, and only needed in a fresh note if you already anticipate more sessions on this topic — otherwise add it later when the second session actually happens):

## Session Log

### <yyyy-mm-dd>
**Session:** `claude --resume <uuid>`
<1-4 sentences or bullets on what happened/changed in this specific session>

Newest entries go at the bottom, in chronological order (oldest first) — this reads like a changelog, not a stack.

5. Write the file to /Users/isac/Documents/obsidian-docs/claude-conversations/<topic-slug>.md.

6. Commit and push the vault. From /Users/isac/Documents/obsidian-docs:

   • Confirm it's a git repo first (git -C /Users/isac/Documents/obsidian-docs rev-parse --is-inside-work-tree). If it isn't (or the directory is missing), skip this step entirely — never block the save on this, and don't mention it unless something was actually attempted.
   • git -C /Users/isac/Documents/obsidian-docs add -A
   • git -C /Users/isac/Documents/obsidian-docs commit -m "<short message about the note that changed, e.g. 'Update esp32-matter-switch-firmware note'>". If there's nothing to commit (rare, since the write in step 5 always changes something), treat that as success, not an error.
   • git -C /Users/isac/Documents/obsidian-docs push. If this fails (no remote configured, no network, no credentials), do not fail the save — the note is already written and committed locally. Just note in step 7's report that the commit succeeded but the push failed, so the user knows to push manually later.

7. Report back to the user: confirm it was saved/updated and print the full absolute local file path on its own line so it's easy to spot, e.g.:

   Updated: /Users/isac/Documents/obsidian-docs/claude-conversations/esp32-matter-switch-firmware.md
   

   (Use "Saved" for a brand-new file, "Updated" for an existing one.) If a session ID was captured, also mention the resume command in the same reply. Mention the git commit/push outcome only if it's notable (e.g. push failed) — a clean commit+push doesn't need its own callout beyond confirming the save.

Notes

• This skill only writes files under the vault's claude-conversations folder — never touch other files in the vault.
• If the vault path itself doesn't exist (vault moved/renamed), stop and tell the user rather than creating a new vault directory structure elsewhere.
• The session ID is best-effort: it's only meaningful for resuming a Claude Code CLI session, so a note saved without one (env var unavailable) is still complete and valid — never block saving the note on this.
• Never overwrite/discard existing content when updating a note — read-then-merge, always. If genuinely unsure how to merge something without losing information, err on the side of keeping the old text and adding the new material alongside it rather than silently dropping either.
• The vault is backed by a private git remote (isacjoseph2006/obsidian-docs). The commit+push in step 6 covers whatever changed in the vault as a whole, not just this skill's own write — that's intentional, it's a general vault backup, not scoped to this note.