# Obsidian Plugin Release Notes > Ensure Synch Obsidian plugin release notes are checked and updated once per pull request, or before committing directly to main, when changes affect apps/obsidian-plugin, root Obsidian release metadata, or the Obsidian plugin release workflow. Use when this capability is needed. - Skill: `tomevault-io/obsidian-plugin-release-notes` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/obsidian-plugin-release-notes` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/obsidian-plugin-release-notes/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/obsidian-plugin-release-notes --- # Obsidian Plugin Release Notes ## Overview Use this skill in the Synch repository before publishing git work that may affect the Obsidian plugin release. The goal is to keep a single cumulative `apps/obsidian-plugin/release-notes/next.md` update accurate for each PR, or accurate before commits land directly on `main`. ## Workflow 1. Determine whether the pending work affects the Obsidian plugin: - Check `git status --short`. - Check staged/uncommitted changes with `git diff --name-only` and `git diff --cached --name-only`. - When preparing a PR, also compare against the base branch with `git diff --name-only origin/main...HEAD` when available. - Treat these paths as plugin-release relevant: `apps/obsidian-plugin/**`, root `manifest.json`, root `versions.json`, and `.github/workflows/release-obsidian-plugin.yml`. 2. If no plugin-release relevant files changed, state that release notes are not required and continue the requested git or PR task. 3. If plugin-release relevant files changed, decide whether release notes are already covered for the current publishing unit. - For direct commits to `main`, inspect `apps/obsidian-plugin/release-notes/next.md` before committing. - For PR work, treat the whole PR as one publishing unit. Inspect the PR diff first; if `apps/obsidian-plugin/release-notes/next.md` is already changed in `origin/main...HEAD` and covers the plugin-facing changes in the PR, do not create another release-note update for additional commits in the same PR. - If the PR already has an adequate release-note update, state that release notes are already covered for this PR and continue the requested git or PR task. 4. If release notes are required and not already covered, inspect `apps/obsidian-plugin/release-notes/next.md` before committing directly to `main` or before opening/updating the PR. - If the file does not exist, create it using the current repository release-note format. - If it contains only a placeholder or does not mention the current plugin-facing changes, update it. - Preserve existing human-written entries and append or refine instead of replacing them wholesale. 5. When writing missing notes, summarize user-facing changes only. - Prefer headings such as `## Added`, `## Changed`, and `## Fixed`. - Mention Obsidian-visible behavior, release workflow changes, and vault safety fixes. - Avoid internal implementation details, test-only changes, and noisy file-by-file descriptions. - Preserve end-to-end encryption guarantees: do not imply that plaintext vault contents, keys, or decrypted data are uploaded or exposed. 6. Use the latest release as the historical baseline when the note needs a full refresh. - Prefer the latest GitHub release or latest tag if already known locally. - If uncertain, fetch tags or query GitHub before claiming what is latest. - Compare plugin paths from the latest release to `HEAD` and condense the result into release-note bullets. 7. Include the release notes file in the commit or PR when it was changed. - Before `git commit` on `main`, make sure `apps/obsidian-plugin/release-notes/next.md` is staged if relevant. - Before creating or updating a PR, make sure the PR diff includes one release-note update or explicitly explain why no note is needed. - During follow-up commits on an existing PR, do not add or require another release-note commit when the existing PR-level note already covers the user-facing changes. ## Current Release-Note Format Use this shape for `apps/obsidian-plugin/release-notes/next.md`: ```markdown # Next Obsidian plugin release ## Added - ... ## Changed - ... ## Fixed - ... ``` Omit empty sections only when the existing file already uses a simpler structure. Keep bullets concise and written for plugin users. --- > Source: [hjinco/synch](https://github.com/hjinco/synch) — distributed by [TomeVault](https://tomevault.io).