Agent skill

Release Publishing

by andymai in andymai/brepjs

This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a…

Apache-2.0Auto-check passedDevelopment

Install Release Publishing

skills CLI
$ npx skills add andymai/brepjs --skill release-publishing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install andymai/brepjs release-publishing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/andymai/brepjs.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release-publishing .claude/skills/release-publishing && rm -rf skills-src

Use ~/.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/

Facts

Skill name
release-publishing
GitHub stars
115
Token cost
~3.4k tokens
SKILL.md length
1,216 words
Files
1
Skills in repo
21
Repo updated
First seen
Licence
Apache-2.0

At a glance

This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a…

  • Works in 6 steps: Commits land on main with… → The release-please job (App token,… → The auto-merge job serializes root… → …
  • Phrases include release PR
  • SKILL.md covers Mental model, How a normal release flows, Hard rules and Recovery playbook, plus 3 more sections
  • Calls npm and gh; needs GHCR_TOKEN

What it does

Release Publishing is an agent skill from andymai/brepjs. This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a breaking marker. Trigger phrases include "release PR", "release-please", "autorelease: pending", "publish to npm", "npm publish failed", "republish", "ETARGET from a leaf release PR ordered ahead of root", "version bump", "why did the major version bump", "breaking change commit", "trusted publisher", "dryrun", "release…

Its SKILL.md is about 3.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development. It works with npm and GitHub Actions. The repository describes itself as: Web CAD library with exact B-Rep geometry. The licence is Apache-2.0.

When your agent uses it

  • Phrases include release PR
  • Autorelease: pending
  • Npm publish failed
  • ETARGET from a leaf release PR ordered ahead of root

Example prompts

  • “release PR”
  • “release-please”
  • “autorelease: pending”
  • “/release-publishing”

Requirements

  • Node.js
  • Docker
  • A credential in GHCR_TOKEN

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Commits land on main with Conventional-Commit subjects (enforced by commitlint — see commitlint.config.js, .husky/commit-msg; format…
  2. The release-please job (App token, googleapis/release-please-action@v5) opens or updates release PRs labeled autorelease: pending.
  3. The auto-merge job serializes root before leaves: it lists open autorelease: pending PRs and, per branch name
  4. Root release PR merges. CI passes trivially on release PRs — ci.yml skips the paths-filter for release-please--* branches, and ci-pass…
  5. publish-brepjs runs inline in release-please.yml: npm ci && npm run build && npm publish --provenance (OIDC). This is the ONLY package…
  6. Merging bumps main. The next release-please run regenerates each leaf PR with a now-valid brepjs pin, auto-merges them, and each…

What it can do on your machine

Read from SKILL.md and the folder at commit 6e20740. It shows what the files ask for, not the result of running them.

  • Tool permissions

    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.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npm and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • GHCR_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Release Publishing loads about 3.4k tokens when it runs. Until then it costs about 159 tokens; SKILL.md has 1,216 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~159
When it runs · the whole SKILL.md, loaded when a task matches
~3.4k

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.

Safety

Auto-check passed

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); files beside SKILL.md are not scanned.

SKILL.md

The full file from andymai/brepjs at commit 6e20740, republished under its Apache-2.0 licence (© andymai). 1,216 words, ~3,446 tokens.

Download SKILL.mdSave it as .claude/skills/release-publishing/SKILL.md (or your agent's skills folder).
name
release-publishing
description
This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a breaking marker. Trigger phrases include "release PR", "release-please", "autorelease: pending", "publish to npm", "npm publish failed", "republish", "ETARGET from a leaf release PR ordered ahead of root", "version bump", "why did the major version bump", "breaking change commit", "trusted publisher", "dry_run", "release tag", "manifest conflict", or editing .github/workflows/publish-*.yml or release-please-config.json.

Releases and npm publishing

Every release in this repo flows through one workflow: .github/workflows/release-please.yml. Its inline comments are the canonical deep documentation — read them before changing anything. This skill is the operator's playbook: how a normal release flows, the hard rules that prevent outages, and the recovery recipes when a step fails.

Mental model

  • release-please, manifest mode. Versions live in .release-please-manifest.json; managed packages are declared in release-please-config.json. On every push to main, release-please opens/updates a per-package release PR (separate-pull-requests: true), bumping the version and CHANGELOG from Conventional Commits.
  • Six managed packages, two deliberately unmanaged. Managed: root . (brepjs), packages/brepjs-opencascade, packages/brepjs-voxel-wasm, packages/brepjs-cad, packages/brepjs-bim, packages/brepjs-sheetmetal. NOT managed by release-please: brepjs-viewer (versioned/published manually — see below) and packages/brepjs-voxel (unpublished workspace consumer).
  • node-workspace re-pins cross-deps. The node-workspace plugin rewrites each leaf package's brepjs dependency to the version of the pending root release. This is the source of the ETARGET hazard (below).
  • npm auth is OIDC trusted publishers, bound to workflow filenames. Each package's publish authenticates via an npm trusted publisher tied to a specific .github/workflows/publish-*.yml filename. Renaming a publish workflow breaks auth silently.

How a normal release flows

  1. Commits land on main with Conventional-Commit subjects (enforced by commitlint — see commitlint.config.js, .husky/commit-msg; format detail lives in the git-pr-workflow skill).
  2. The release-please job (App token, googleapis/release-please-action@v5) opens or updates release PRs labeled autorelease: pending.
  3. The auto-merge job serializes root before leaves: it lists open autorelease: pending PRs and, per branch name:
    • *--components--brepjs-opencascade → permanently held (manual, expensive WASM build).
    • root branch release-please--branches--main--components--brepjs → gh pr merge --auto --squash (merges first).
    • any other leaf → held while a root release PR is open; merged on a later run after root lands.
  4. Root release PR merges. CI passes trivially on release PRs — ci.yml skips the paths-filter for release-please--* branches, and ci-pass treats skipped jobs as pass — so --auto completes.
  5. publish-brepjs runs inline in release-please.yml: npm ci && npm run build && npm publish --provenance (OIDC). This is the ONLY package published inline.
  6. Merging bumps main. The next release-please run regenerates each leaf PR with a now-valid brepjs pin, auto-merges them, and each auto-publishing leaf's job dispatches its own publish-brepjs-<pkg>.yml with -f dry_run=false --ref <release-tag>. (brepjs-opencascade is the exception — always manual via publish-opencascade.yml; brepjs-voxel-wasm has no publish workflow.)

Leaves dispatch against the immutable release tag release-please just created, never main: the dispatch API accepts a tag but rejects a raw SHA, and the tag pin avoids publishing the wrong commit if another push lands mid-window.

Hard rules

RuleWhyWhere
Never put !/BREAKING CHANGE on a commit unless intentionally breaking the brepjs public API.Root is 18.x; any breaking marker majors the library immediately..release-please-manifest.json
Root exclude-paths are apps, tests and every packages/* workspace, so a satellite-only or test-only commit never bumps root. A breaking commit touching root docs/, README.md, scripts/, or .github/ still majors root.Every non-excluded path attributes to the root component, and attribution uses the PR's changed-file list, not the squash commit's (see publish-pipeline.md).release-please-config.json:8-22
Never rename or move a publish-*.yml file without re-registering the npm trusted publisher for that package.OIDC auth is bound to the exact filename; a rename makes npm publish fail auth.comments in each publish-*.yml
Never merge a leaf release PR while the root brepjs release PR is open.node-workspace pins the leaf to an unpublished brepjs version → npm install ETARGET → Vercel deploys break. Also conflicts the root PR on the shared manifest.release-please.yml:57-72
Never cancel an in-flight Release Please run.Cancelling mid-publish leaves a tagged-but-unpublished release; the concurrency group queues, never cancels.release-please.yml:17-24
Manual publish dispatches default to dry_run: true (build-only). A real publish needs -f dry_run=false and a ref.A bare dispatch is a safe smoke build.every publish-*.yml
brepjs-opencascade is always manual.~60-min Docker WASM build from ghcr.io/andymai/opencascade.js:v8 (needs GHCR_TOKEN).publish-opencascade.yml
Show full SKILL.md (594 more words)Show less

Recovery playbook

Root brepjs publish failed (release tagged, npm empty). Do NOT re-run the failed push job — release-please would try to re-tag. Instead re-dispatch the whole workflow in republish mode:

gh workflow run release-please.yml -f republish=true

This skips the release-please job and runs only publish-brepjs against the current main package.json version. Republish covers root brepjs only.

A leaf publish failed (brepjs-cad/bim/sheetmetal). Re-dispatch that leaf's own publish workflow against the release tag:

gh workflow run publish-brepjs-<pkg>.yml -f dry_run=false --ref <release-tag>

brepjs-opencascade needs publishing. Manual only:

gh workflow run publish-opencascade.yml -f dry_run=false --ref <release-tag>

Conflicted release PRs (serializer bypassed — e.g. a human merged a leaf early). Not tooled; manual fix. For each still-open release PR: merge main into its branch, take the union of .release-please-manifest.json (keep every package's highest intended version), resolve CHANGELOG/package.json, push. Then let the auto-merge job re-arm on the next run.

npm install/CI fails with ETARGET after a merge. A leaf on main is pinned to a brepjs version not yet on npm. Confirm root actually published (npm view brepjs version); if root is fine, the leaf pin is ahead — publish root first (republish above), or bump the leaf's pin down to a published version and open a fix PR. Related consumer-side symptoms are covered in ci-triage and companion-packages.

Pack validation failed (prepack). Root npm pack/npm publish runs scripts/validate-pack.sh (wired as prepack, with prepublishOnly: npm run build). It fails on more than 500 files or any .d.ts.map sidecar. Inspect with npm pack --dry-run. .d.ts.map files mean declarationMap got re-enabled — check vite.config.ts.

Package publish matrix

PackageManaged?Auto-merge?Auto-publish?Publish route
brepjs (root)yesyes (first)yes, inlinerelease-please.yml job publish-brepjs (OIDC)
brepjs-cadyesyes (after root)yes, dispatchedpublish-brepjs-cad.yml
brepjs-bimyesyes (after root)yes, dispatchedpublish-brepjs-bim.yml
brepjs-sheetmetalyesyes (after root)yes, dispatchedpublish-brepjs-sheetmetal.yml
brepjs-opencascadeyesheld (manual)manual onlypublish-opencascade.yml (Docker WASM)
brepjs-voxel-wasmyes (bumps Cargo.toml)yes (after root)no workflow, not on npmnone
brepjs-viewernon/amanualpublish-brepjs-viewer.yml
brepjs-voxelnon/anot publishednone

Build prerequisites baked into the publish workflows: brepjs-cad restores OCCT WASM (scripts/ensure-wasm.sh, 3× retry) then builds root + brepjs-viewer + itself (viewer is a build-time devDep whose dist is bundled into the brepjs-cad build output). bim and sheetmetal build root brepjs first (their vite-plugin-dts needs root's emitted types). brepjs-viewer uses npm ci --ignore-scripts and publishes --access public.

Notes and gotchas

  • brepjs-viewer is intentionally de-managed from release-please. node-workspace kept re-pinning brepjs-cad's build-time brepjs-viewer devDep ("brepjs-viewer": "*") to viewer's pending unpublished version, breaking monorepo npm ci. Version and publish it by hand via publish-brepjs-viewer.yml.
  • The Claude-plugin marketplace version is independent of the npm version. release-please does not bump packages/brepjs-cad/.claude-plugin/plugin.json; the plugin version and the npm brepjs-cad version move separately.
  • Docs deploy is not release-triggered. .github/workflows/docs.yml chains off successful CI on main (workflow_run); emergency redeploy is a main-only workflow_dispatch.
  • npm unpublish is never available for brepjs. The published satellites (brepjs-bim, brepjs-families, brepjs-sheetmetal, brepjs-cad) declare brepjs >=18.x, and npm refuses to unpublish a version that any registry package depends on, even inside the 72-hour window; only npm deprecate is offered. A mistaken release therefore stays: annotate its changelog section and GitHub release notes instead (brepjs 20.0.0, 2026-09-21, was a no-op major kept this way). Rewinding the manifest is not an option either, since the version remains on the registry.
  • scripts/publish-all.sh is a legacy manual OTP fallback (opencascade → root only, --no-provenance). The OIDC workflows supersede it; use only as a local last resort, and note it does not cover cad/bim/sheetmetal/viewer.

Additional resources

  • Commit format and the ! decision: git-pr-workflow skill.
  • CI job failure modes (npm ci EUSAGE/ETARGET, release PR won't merge, publish red): ci-triage skill.
  • Which package to edit and how a change ripples to consumers: companion-packages skill.
  • Canonical deep reference: the inline comments in .github/workflows/release-please.yml.

© andymai, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/release-publishing of andymai/brepjs.

Open the folder on GitHubat commit 6e20740

Compare with similar skills

Release Publishing 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.

Release Publishing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release Publishing this skillandymai/brepjs115—~3.4kAutomated safety check: PassApache-2.0
Ccb GitHubSeemSeam/claude_codex_bridge3.6k—~4.9kAutomated safety check: PassCustom licence
ZCF Release AutomationUfoMiao/zcf6.1k—~3.4kAutomated safety check: PassMIT
Cline CLI Release Publishercline/cline70k—~3.4kAutomated safety check: WarnApache-2.0
Linea Dependency MaintenanceConsensys-Incorporated/linea-attestation-registry1771 repos~3.7kAutomated safety check: WarnMIT
Codexhost ReleaseBytePioneer-AI/codex-host2.8k—~998Automated safety check: PassLGPL-3.0

Similar skills

  • Ccb GitHub

    SeemSeam/claude_codex_bridge

    Maintain this CCB project's GitHub-facing release and npm publication surface.

    3.6k GitHub stars~4.9k tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Automates a version release with changesets: analyzes code changes, writes a bilingual CHANGELOG, bumps the version and commits through a release branch and pull request.

    6.1k GitHub stars~3.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Walks through releasing the Cline CLI package to npm: release notes, version bump, matching git tag, and either the GitHub workflow or a local publish.

    70k GitHub stars~3.4k tokensUpdated today
    DevelopmentAuto-check: warnings
  • Linea Dependency Maintenance

    Consensys-Incorporated/linea-attestation-registry

    Safely plan and execute dependency maintenance for JavaScript/TypeScript (npm, pnpm) and GitHub Actions, including npm lockfiles, pnpm workspaces, catalogs, overrides, SHA-pinned action versions…

    177 GitHub starsUsed in 1 repo~3.7k tokens
    DevelopmentAuto-check: warnings
  • Codexhost Release

    BytePioneer-AI/codex-host

    发布 codexhost 正式版、预览版,编写或确认 Release Notes,检查发布 CI,暂停、恢复或排查发布。支持正常正式发布,以及 npm latest + GitHub Prerelease、不给现有用户更新提示的预览发行。不用于普通代码提交或 Harness CLI 更新。

    2.8k GitHub stars~998 tokensUpdated today
    DevelopmentAuto-check passed
  • npm Package Publisher

    klaudworks/universal-skills

    Releases an npm package by committing changes, bumping the version with npm version, pushing the tag and checking the GitHub Actions publish.

    181 GitHub stars~923 tokensUpdated 8 mo ago
    DevelopmentAuto-check passed

More from andymai/brepjs

All 21 skills in this repo
  • Implement

    andymai/brepjs

    A skill your agent uses when authoring or editing a brepjs .brep.ts part — writing the geometry with the functional API (box, cylinder, fuse, cut, fillet, sketch→extrude…), declaring an expected…

    115 GitHub stars~3.4k tokensUpdated today
    Auto-check passed
  • Memory And Disposal

    andymai/brepjs

    This skill should be used when managing WASM handle lifetimes or hunting memory leaks in brepjs — when a task mentions "createHandle() without using keyword risks WASM memory leak"…

    115 GitHub stars~3.1k tokensUpdated today
    Auto-check passed
  • Polish

    andymai/brepjs

    A skill your agent uses when a valid brepjs part should look designed rather than glued-from-primitives (products, toys, mechanisms, anything a human eyeballs), and when exporting/handing off the…

    115 GitHub stars~588 tokensUpdated today
    Auto-check passed
  • Wasm Interop

    andymai/brepjs

    This skill should be used when working across the JS/WASM boundary in brepjs — writing or debugging code in src/kernel/occt, src/kernel/occtWasm, or src/kernel/brepkit, or diagnosing symptoms like…

    115 GitHub stars~3k tokensUpdated today
    Auto-check passed
  • Writing Tests

    andymai/brepjs

    This skill should be used when writing, running, or fixing tests in the brepjs repository — when a task says "add a test", "write a regression test", "tests are failing", "test timed out", "coverage…

    115 GitHub stars~4.3k tokensUpdated today
    Auto-check passed
  • Adding Operations

    andymai/brepjs

    This skill should be used when adding or extending a geometric shape operation in brepjs — the end-to-end recipe once the target module is chosen (which is decided by architecture-navigation) — when…

    115 GitHub stars~4.4k tokensUpdated today
    Auto-check passed

Categories

Questions about Release Publishing

What does Release Publishing do?

This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a…. Release Publishing is an agent skill from andymai/brepjs. This skill should be used when operating releases or npm publishing in brepjs — cutting or merging a release-please PR, recovering a failed npm publish, or deciding whether a commit may carry a breaking marker.

When should I use Release Publishing?

Release Publishing fits situations like: phrases include release PR; autorelease: pending; npm publish failed; ETARGET from a leaf release PR ordered ahead of root.

How do I install Release Publishing in Claude Code?

Run `npx skills add andymai/brepjs --skill release-publishing -a claude-code`. Or copy the skill folder (.claude/skills/release-publishing in andymai/brepjs) into .claude/skills/release-publishing in your project. Claude Code loads it when a task matches its description.

How do I install Release Publishing in Codex?

Run `npx skills add andymai/brepjs --skill release-publishing -a codex`. Or copy the skill folder (.claude/skills/release-publishing in andymai/brepjs) into .agents/skills/release-publishing in your project. Codex loads it when a task matches its description.

Can I use Release Publishing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add andymai/brepjs --skill release-publishing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-publishing, .gemini/skills/release-publishing, .github/skills/release-publishing and .opencode/skills/release-publishing in your project.

What does Release Publishing need to run?

Going by SKILL.md and its folder, Release Publishing needs the command-line tools its instructions call (npm and gh) and credentials named GHCR_TOKEN. Our summary lists: Node.js; Docker; A credential in GHCR_TOKEN.

Does Release Publishing access the network?

SKILL.md contains no URLs. Its commands use npm and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Release Publishing safe to install?

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. Review the folder before installing.

What licence does Release Publishing use?

Release Publishing is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Release Publishing use?

About 3.4k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Release Publishing?

Skills that share tags, products or a category with Release Publishing: Ccb GitHub (SeemSeam/claude_codex_bridge, 3.6k stars), ZCF Release Automation (UfoMiao/zcf, 6.1k stars), Cline CLI Release Publisher (cline/cline, 70k stars) and Linea Dependency Maintenance (Consensys-Incorporated/linea-attestation-registry, 177 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release Publishing?

andymai (a GitHub user) maintains it in andymai/brepjs, which has 115 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on October 8, 2026.

Source: andymai/brepjs on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.