release-process

A release checklist for publishing a version of an Obsidian plugin. Obsidian is a note-taking app that supports community plugins.

In plain words
What is it for?
Use it to run checks, update package and plugin versions, commit and tag changes, and prepare a GitHub release.
Why use it?
It prevents missed version updates, checks, changelog entries, tags, and release files when preparing a submission.

Cursor rule for Cursor

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/rygwdn/obsidian-mcp-plugin/release-process
Clone the repo
git clone --depth 1 https://github.com/rygwdn/obsidian-mcp-plugin

Made for: Cursor.

Per session 7 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 522 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00007 $0.00522
Opus 5 $0.00003 $0.00261
Sonnet 5 $0.00001 $0.00104
Haiku 4.5 $0.00001 $0.00052

Measured 2d ago against content hash f79e49bc9f5d, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

release-process scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/release-process.mdc · 66 lines

How it starts

The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Release Process

Follow these steps to properly release a new version of the MCP plugin for Obsidian submission:

Pre-Release Checklist

  • Ensure all tests pass: npm run check
  • Ensure all changes have been committed to the repository
  • Review the non-test diff since the last release
  • Update CHANGELOG.md with the new version:
    ## [x.y.z] - YYYY-MM-DD
    - feat: New feature description
    - fix: Bug fix description
    - refactor: Other changes
    

Version Bump

  • Update the version number in the package.json
  • Run the version bump script to update version references npm run version This script:
  • Run a final check: npm run check
  • Commit all the changes git commit -a -m 'release: prepare x.y.z release'

Tag and Push

git tag x.y.z
git push origin x.y.z

GitHub Release

After pushing the tag, GitHub Actions will:

  • Create a draft release with notes from the CHANGELOG
  • Build the plugin
  • Upload the required files as binary attachments to the release:
    • main.js
    • manifest.json
    • styles.css (if used by the plugin)

IMPORTANT: Obsidian Plugin Requirements

For Obsidian plugin directory submission, the release MUST have:

  1. The tag version (x.y.z) MUST exactly match the version in manifest.json
  2. The main.js, manifest.json, and styles.css (if applicable) files MUST be uploaded as binary attachments
  3. After review, the draft release must be published

Final Steps

  • Wait for GitHub workflows to complete:
    # Get the run IDs for the latest release
    gh run list -c $(git rev-parse x.y.z)
    # Wait for the run to complete
    gh run watch {CI run id}
    gh run watch {release run id}
    
  • View and publish the release:
    gh release view x.y.z --web
    
  • After publishing the release, verify that all required files are attached to the release

Read the full file on GitHub · 66 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 66 lines · 7 tokens per session scan A f79e49bc9f5d

Subscribe to this mod's changes

release-process is a cursor rule published in the GitHub repository rygwdn/obsidian-mcp-plugin (11 stars, last pushed 6mo ago), licensed MIT. It adds 7 tokens to every session and 522 once invoked, about $0.0000 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.