A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install TriliumNext/Trilium cutting-a-release --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/cutting-a-release .claude/skills/cutting-a-release && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .claude/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-releaseType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install TriliumNext/Trilium cutting-a-release --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/cutting-a-release .agents/skills/cutting-a-release && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .agents/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install TriliumNext/Trilium cutting-a-release --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/cutting-a-release .cursor/skills/cutting-a-release && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .cursor/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/TriliumNext/Trilium.git --path .claude/skills/cutting-a-release--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install TriliumNext/Trilium cutting-a-release --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/cutting-a-release .gemini/skills/cutting-a-release && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .gemini/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install TriliumNext/Trilium cutting-a-releaseInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/cutting-a-release .github/skills/cutting-a-release && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .github/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add TriliumNext/Trilium --skill cutting-a-release -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install TriliumNext/Trilium cutting-a-release --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/TriliumNext/Trilium.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/cutting-a-release .opencode/skills/cutting-a-release && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "cutting-a-release" agent skill from https://github.com/TriliumNext/Trilium/tree/main/.claude/skills/cutting-a-release into .opencode/skills/cutting-a-release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "cutting-a-release", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
cutting-a-releaseA skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.
Cutting A Release is an agent skill from TriliumNext/Trilium. Use when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run. Covers the ordered bump recipe (edit root package.json → chore:update-version → commit → v-prefixed tag → push), which of the TWO divergent version scripts to use (update-version for releases vs update-nightly-version for CI nightlies), why the CI version-consistency gate validates only 5 of the 9 files update-version writes, the exact docs/Release Notes/Release…
Its SKILL.md is about 3.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including scripts and reference files (for example `references/ci-pipeline.md`).
It sits in Development, covering Changelog and release notes and Monorepo tooling. It works with GitHub and npm. The repository describes itself as: Build your personal knowledge base with Trilium Notes. The licence is AGPL-3.0.
5 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit 96bed2f. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Ships 1 file in scripts/ (TypeScript), which the agent can run.
Shell commands in SKILL.md call:
gitghpnpmnpxFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use git, gh, pnpm and npx, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names these keys or tokens, usually read from environment variables:
GITHUB_TOKENFrom names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Cutting A Release loads about 3.2k tokens when it runs, and up to ~4.6k if it reads all its reference files. Until then it costs about 230 tokens; SKILL.md has 1,415 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
The full file from TriliumNext/Trilium at commit 96bed2f, republished under its AGPL-3.0 licence (© TriliumNext). 1,415 words, ~3,154 tokens.
.claude/skills/cutting-a-release/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.Releases are a tag push, not a button. Pushing a v* tag to main triggers .github/workflows/release.yml, which builds every artifact and creates the GitHub release. Get the version bump and the release-notes file right before you tag, because three of the failure modes below pass CI and ship anyway.
package.json only, then propagate. Root is the single source of truth. pnpm chore:update-version (scripts/update-version.ts:27-46) reads root, writes 8 other package.jsons and regenerates the Flathub metainfo's <releases> from git for-each-ref. Hand-editing the children desyncs the tree.update-version, not update-nightly-version. The nightly one (scripts/update-nightly-version.ts) writes a different set of files and appends a -test-YYMMDD-HHMMSS suffix; it's CI-only. Running it for a release poisons the version. (§ The two scripts)scripts/check-version-consistency.ts validates only 5 files; update-version writes 8 package.jsons plus the metainfo. The 4 gaps (standalone, edit-docs, pdfjs-viewer, trilium-core) can be wrong and still ship. Run the bundled pre-flight, which checks all 9 plus the metainfo entry.docs/Release Notes/Release Notes/v<X.Y.Z>.md — note Release Notes/Release Notes/ twice, and the v prefix in the filename. The publish step ENOENTs without it (release.yml:155).v-prefixed. release.yml triggers only on push: tags: v* (release.yml:3-5). A bare 0.103.0 tag runs nothing, silently.Don't hand-roll a version checker — run the bundled pre-flight, a superset of the CI gate:
npx tsx .claude/skills/cutting-a-release/scripts/preflight-release-check.mts v0.103.0It asserts all 9 package.jsons match, that the metainfo <release> is the version being tagged, that the release-notes file exists at the doubled path, and warns on the rc/beta labeling footgun (trap below). Run it right before pushing the tag.
| # | Step | Command / file | Gotcha |
|---|---|---|---|
| 1 | Write release notes | create docs/Release Notes/Release Notes/v<X.Y.Z>.md | filename = tag incl. v; publish hard-fails without it (release.yml:155) |
| 2 | Bump ROOT only | edit package.json version | do NOT hand-edit the other package.jsons |
| 3 | Propagate | pnpm chore:update-version | rewrites 8 package.jsons from root, and regenerates the metainfo <releases> Flathub displays; never the reverse |
| 4 | Pre-flight | npx tsx .claude/skills/cutting-a-release/scripts/preflight-release-check.mts v<X.Y.Z> | catches the 4 files CI never checks, a stale metainfo <release> + a missing notes file |
| 5 | Commit | chore(release): prepare for v<X.Y.Z> | stage every changed package.json, the metainfo + the new release-notes md |
| 6 | Tag (v-prefixed) | git tag v<X.Y.Z> | release.yml only fires on v* |
| 7 | Push commit + tag | git push && git push --tags | |
| 8 | Watch CI, then download + smoke-test the GitHub release | — | see references/ci-pipeline.md to map a red job |
The upstream doc (docs/Developer Guide/Developer Guide/Building/Releasing a new version.md, 9 steps) is the same recipe but wrong on step 4: it tells you to run pnpm i "to update the package lock" and calls it package-lock.json. A version-only bump does not change pnpm-lock.yaml (see footgun below), and the lockfile is pnpm-lock.yaml. Skip that step unless you also changed a real dependency.
scripts/update-version.ts | scripts/update-nightly-version.ts | |
|---|---|---|
| npm script | chore:update-version (package.json:38) | chore:ci-update-nightly-version (package.json:34) |
| Use for | releases — manual, this skill | CI nightlies only |
| Invoked by | you | nightly.yml:75, main-docker.yml:163 |
| Reads root version? | yes (update-version.ts:28) | yes, then mutates it |
| Writes root? | no | yes (update-nightly-version.ts:47) |
| Files written | 9: apps server/client/standalone/desktop/edit-docs + packages commons/pdfjs-viewer/trilium-core, + the Flathub metainfo (update-version.ts:31,35,44) | 6: root + apps server/client/standalone/desktop + pdfjs-viewer (update-nightly-version.ts:50,55) |
| Version shape | root version, verbatim | strips -beta, appends -test-YYMMDD-HHMMSS (update-nightly-version.ts:19-24) |
The two sets diverge in both directions: update-version touches edit-docs/commons/trilium-core (nightly doesn't); nightly touches root (update-version doesn't). Run the wrong one and the tree desyncs — e.g. running nightly during a release stamps 0.103.0-test-260613-... into root and leaves commons/trilium-core untouched.
scripts/check-version-consistency.ts:5-11 validates exactly:
package.json, apps/server, apps/client, apps/desktop, packages/commons(stripping a leading v from the tag arg, lines 20-22). But update-version writes 9, so apps/standalone, apps/edit-docs, packages/pdfjs-viewer, packages/trilium-core and the Flathub metainfo are written but never validated. A stale version in any of those passes the sanity-check job (release.yml:30-31) and ships.
This isn't theoretical — real release-prep commits touched different file subsets because update-version only produces a git diff for files that were previously stale: v0.103.0 (44f5be88b7) changed 7 package.jsons including pdfjs-viewer; v0.102.1 (8ac9daa5d3) changed 6, no pdfjs-viewer. The CI gate would not have caught a wrong value in the un-checked four either time. The bundled pre-flight checks all 9, and the metainfo <release> the gate has never known about — use it instead of trusting the gate.
release.yml job publish_release (uses softprops/action-gh-release@v3.0.0, lines 151-161):
Field (release.yml) | Value | Hard-fail / footgun |
|---|---|---|
body_path (155) | docs/Release Notes/Release Notes/${{ github.ref_name }}.md | doubled folder + v prefix; ENOENT if missing |
make_latest (159) | ${{ !contains(github.ref, 'rc') }} | pure substring on the full ref refs/tags/... |
prerelease (160) | ${{ contains(github.ref, 'rc') }} | only rc is special-cased |
token (161) | ${{ secrets.RELEASE_PAT }} | not GITHUB_TOKEN — needs PAT to open the Releases discussion |
discussion_category_name (158) | Releases | with discussions: write (release.yml:8) |
fail_on_unmatched_files (156) | true | fails if no upload/*.* artifacts (an upstream build job failed) |
The labeling footgun: because only the literal substring rc flips prerelease, a -beta (or -alpha/-dev) tag does NOT match — it publishes with make_latest=true and prerelease=false, i.e. marked the latest stable release. If you want a pre-release that isn't the latest, the tag must contain rc (e.g. v0.103.0-rc.1). The pre-flight warns on this.
workspace:* (resolve to link:, no version recorded — grep 0.103.0 pnpm-lock.yaml = 0 hits), and the release-prep commits above never touched pnpm-lock.yaml. CI installs --frozen-lockfile before any bump (nightly.yml:71 then bump at :75; release.yml:28). --frozen-lockfile only fails if the release also changes a real dependency. The upstream doc's "run pnpm i" step is precautionary and misnames the file.v-prefixed — release.yml:3-5 triggers only on v*. A bare 0.103.0 tag does nothing.RELEASE_PAT, not GITHUB_TOKEN — release.yml:161. Confirmed the only PAT in the release flow; winget (downstream) uses a separate WINGET_PAT (release-winget.yml:19).release.yml has no Flathub job; release-flathub.yml runs on release: published (prereleases skipped) and opens a pull request against flathub/org.triliumnotes.Trilium that someone still has to merge. gh workflow run "Release to Flathub" -f ref=v<X.Y.Z> re-runs it by hand. Needs the FLATHUB_PAT secret. See the packaging-for-flathub skill.update-version propagate from root, or they desync silently past the 5-file gate.update-version is idempotent but partial in the diff — it rewrites all 8 unconditionally; only the previously-stale ones show up in git status. "Only 6 files changed" is normal and not a sign you missed one. The metainfo is the exception: its <releases> is derived, not accumulated — the newest 5 vX.Y.Z tags, dated by creatordate, with the version being prepared dated today until its own tag supplies the date. A re-run after tagging therefore settles on the tag date, and a checkout without tags fails the script rather than truncating the list.nightly.yml on a branchDispatching the nightly workflow on a branch (gh workflow run "Nightly Release" --ref <branch>)
is the only way to exercise real packaging on CI runners without merging. That is safe now: every
publish step is gated on github.ref == 'refs/heads/main' (nightly.yml:103 desktop,
nightly.yml:144 mobile), and any other ref — a workflow_dispatch on a branch, a
renovate/electron-forge* push, a PR — uploads its desktop, mobile APK and server outputs as
workflow artifacts instead (nightly.yml:115,154).
The main ref is written as a literal string on purpose: the schedule event payload is minimal,
so deriving the default branch from it is unreliable.
Before this landed (PR #10614), a branch dispatch sprayed branch-named assets onto the public
nightly release. On a checkout predating it, clean up with:
gh release view nightly --repo TriliumNext/Trilium --json assets --jq '.assets[].name'
gh release delete-asset nightly "<name>" --yesFilter on the branch slug — the real nightly assets come from main.
Same recipe, different branch. Per docs/Developer Guide/Developer Guide/Branching strategy.md:20-30: create a hotfix branch from the release tag, cherry-pick the needed fixes from main, bump + release from hotfix (the recipe above), then merge hotfix back into main via PR. The tag still triggers release.yml the same way — nothing about the bump/notes/labeling rules changes.
| File | When to open |
|---|---|
| references/ci-pipeline.md | Debugging a red "Release" run — job-by-job anatomy (sanity-check → make-electron matrix + build_server → publish_release), the exact failing string per job, and the downstream release-winget.yml. |
| scripts/preflight-release-check.mts | Run before pushing the tag — superset of the CI gate (all 9 package.jsons + notes file + rc/beta labeling warning). |
Related skills: writing-unit-tests / analyzing-coverage if a build job's test step is what failed (the release builds run the suites); evolving-the-data-model if the release includes a DB migration whose version you also need to sanity-check.
© TriliumNext, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 2 other files (scripts, references) in .claude/skills/cutting-a-release of TriliumNext/Trilium.
Open the folder on GitHubat commit 96bed2f
Cutting A Release next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Cutting A Release this skillTriliumNext/Trilium | 38k | — | ~3.2k | Automated safety check: Pass | AGPL-3.0 | |
| Automate npm Releasejd-solanki/slidev-theme-dracula | 161 | — | ~626 | Automated safety check: Pass | None | |
| Verdaccio Pull Request Workflowverdaccio/verdaccio | 18k | — | ~1.9k | Automated safety check: Pass | MIT | |
| Hunk Release Workflowmodem-dev/hunk | 9.6k | — | ~3.8k | Automated safety check: Pass | MIT | |
| Version ReleaseNG-ZORRO/ng-zorro-antd | 9.2k | — | ~3.1k | Automated safety check: Pass | MIT | |
| Release Roundethereumjs/ethereumjs-monorepo | 2.8k | — | ~2k | Automated safety check: Pass | None |
jd-solanki/slidev-theme-dracula
Automate npm package publishing via GitHub Actions for single-package repos and independent monorepo packages, including bumpp version tags, GitHub release notes, trusted publishing, provenance, and…
verdaccio/verdaccio
Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.
modem-dev/hunk
Maintainer workflow for preparing, publishing, verifying and curating Hunk releases, with confirmation gates before tags, publishes and public edits.
NG-ZORRO/ng-zorro-antd
NG-ZORRO/ng-zorro-antd repository release workflow. An agent skill from NG-ZORRO/ng-zorro-antd.
ethereumjs/ethereumjs-monorepo
Runs a coordinated EthereumJS npm release round in six human-gated phases — intent and readiness, CHANGELOG, version bump, publish (human executes), post-publish verification, and announcements.
SeemSeam/claude_codex_bridge
Maintain this CCB project's GitHub-facing release and npm publication surface.
TriliumNext/Trilium
A skill your agent uses when working on the Trilium Electron desktop app (apps/desktop) — adding or changing an electronApi method / IPC channel, touching preload.ts, main.ts, services/window.ts or…
TriliumNext/Trilium
A skill your agent uses when adding a DB migration or a new column/field to a Becca entity in Trilium ("add a migration", "new column on notes/attributes", "ALTER TABLE", "add a field to…
TriliumNext/Trilium
A skill your agent uses when adding, moving, or wiring an internal REST endpoint in Trilium (a new /api/ route) — choosing between a core-shared handler (packages/trilium-core/src/routes/index.ts…
TriliumNext/Trilium
A skill your agent uses when adding, changing, or reviewing an LLM/MCP tool in Trilium (the defineTools definitions under packages/trilium-core/src/services/llm/tools/ —…
TriliumNext/Trilium
Write, extend, and review CKEditor 5 plugins in the Trilium (TriliumNext Notes) monorepo — the rich-text-note editor under packages/ckeditor5, whose plugins live in src/plugins/.
TriliumNext/Trilium
Testing CKEditor 5 plugins in the Trilium monorepo. An agent skill from TriliumNext/Trilium.
Categories
A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run. Cutting A Release is an agent skill from TriliumNext/Trilium. Use when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.
Cutting A Release fits situations like: debugging a Trilium release — bumping the monorepo version; diagnosing a failed Release workflow run.
Run `npx skills add TriliumNext/Trilium --skill cutting-a-release -a claude-code`. Or copy the skill folder (.claude/skills/cutting-a-release in TriliumNext/Trilium) into .claude/skills/cutting-a-release in your project. Claude Code loads it when a task matches its description.
Run `npx skills add TriliumNext/Trilium --skill cutting-a-release -a codex`. Or copy the skill folder (.claude/skills/cutting-a-release in TriliumNext/Trilium) into .agents/skills/cutting-a-release in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add TriliumNext/Trilium --skill cutting-a-release -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/cutting-a-release, .gemini/skills/cutting-a-release, .github/skills/cutting-a-release and .opencode/skills/cutting-a-release in your project.
Going by SKILL.md and its folder, Cutting A Release needs TypeScript for the scripts in its folder, the command-line tools its instructions call (git, gh, pnpm and npx) and credentials named GITHUB_TOKEN. Our summary lists: Node.js; Docker; A credential in GITHUB_TOKEN.
SKILL.md contains no URLs. Its commands use git, gh and npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
Cutting A Release is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 3.2k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.5k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Cutting A Release: Automate npm Release (jd-solanki/slidev-theme-dracula, 161 stars), Verdaccio Pull Request Workflow (verdaccio/verdaccio, 18k stars), Hunk Release Workflow (modem-dev/hunk, 9.6k stars) and Version Release (NG-ZORRO/ng-zorro-antd, 9.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
TriliumNext (a GitHub organization) maintains it in TriliumNext/Trilium, which has 38,256 GitHub stars. The repository holds 22 skills in this directory. The repository was last updated on October 9, 2026.
Source: TriliumNext/Trilium on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
