elysiajs-mcp: Skill for OpenCode

Release

This project releases via the Release GitHub Actions workflow (.github/workflows/release.yml), which publishes to npm with provenance when a GitHub Release is published. So "doing a release" means: prepare version + changelog locally, then create a GitHub Release — never run npm publish locally.

Pre-requisites that must already exist (if missing, stop and tell the user):

• a git repo with a main branch and a remote called origin
• gh CLI authenticated (gh auth status)
• the NPM_TOKEN repo secret set in GitHub (you cannot verify this locally; just remind the user once)

Flow

Work through these steps in order. Use the bash tool for git/gh, the edit/write tools for package.json / CHANGELOG.md, and bun for local verification (typecheck / test / build).

1. Sanity-check the working copy

• git rev-parse --abbrev-ref HEAD → expect main. If not, ask the user whether to proceed.
• git status --porcelain → must be empty. If not, ask the user to commit or stash first; do not commit unrelated changes as part of the release.
• bun run check && bun test && bun run build → must pass (runs oxlint, oxfmt format check, and typecheck). Stop and report if it fails.

2. Determine the previous version and the commit range

git describe --tags --abbrev=0

• If a tag is returned, that is PREV_TAG and the range is $PREV_TAG..HEAD.
• If the command errors (no tags yet — first release), use the whole history (git log with no range).

These examples use POSIX-shell syntax; if the local shell is PowerShell (this project's default platform is Windows), translate accordingly — e.g. redirect stderr with 2>$null instead of 2>/dev/null, and don't rely on || true (use try/catch or check $?).

3. Collect commits and infer the bump

# with a previous tag:
git log $PREV_TAG..HEAD --pretty=format:"%h%x09%s"
# first release (no prior tag):
git log --pretty=format:"%h%x09%s"