[MartinForReal]

Two release-time footguns, one of which has already cost a release its assets.

release.yml is not idempotent

Publishing a release from the GitHub UI creates its tag, and that tag push is what starts this workflow. gh release create then fails on a release that already exists — and it fails after the build and attestation steps, so what survives is a published release with no main.js attached. That's the one shape of release that is useless to Obsidian: the plugin won't load.

The step now checks for the release and uploads onto it when it's there. --clobber also makes re-running a job that died partway through safe, rather than failing on whichever assets the first attempt managed to upload.

Verified by extracting the step's shell body straight out of the YAML and running it against a stub gh, in both states:

--- no release yet (view exits 1) ---
CALLED: gh release create 0.6.0 --title=0.6.0 --generate-notes main.js manifest.json styles.css
--- release already exists (view exits 0) ---
CALLED: gh release upload 0.6.0 main.js manifest.json styles.css --clobber

CONTRIBUTING.md

• main.js is a tracked artifact, not a build output git ignores. Obsidian loads the plugin from it and the release workflow attaches whatever the tag points at, so a PR that edits a .ts file without rebuilding reads as correct and ships nothing. Nothing in CI catches this — the build job builds from source and never compares against the committed artifact.
• The documented release recipe was wrong. It said npm version patch && git push --follow-tags, which tags whatever branch you're on. Every release since 0.3.0 has actually gone through a release/X.Y.Z PR with the tag on the merge commit (0.5.0 → 000c9c8, the merge of Release 0.5.0 #14). It now documents what the repo does, and says to let the workflow publish rather than creating the release by hand.

🤖 Generated with Claude Code