ProfSynapseProfSynapse/nexus/.claude/skills/nexus-release/SKILL.md

nexus-release

Skill158 starsChanged 10 days agoMITView on GitHub

Cut a Nexus release — bump the version with the repo's own machinery, get the docs and generated sources right, push a tag the GitHub Actions workflow will actually pick up, and recover when it does not. Use when asked to release, publish, ship, cut a release, bump the version, or tag a version, and when a release workflow did not fire, failed its version guard, or produced the wrong assets.

In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- nexus-agentsSkill
- nexus-eval-harnessSkill
- nexus-llm-adaptersSkill
- nexus-mobile-compatSkill
- nexus-model-evalSkill
- nexus-model-updatesSkill
- nexus-storageSkill
- nexus-testingSkill
- nexus-tool-schemasSkill
- nexus-ui-mockupsSkill
- nexusSkill

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Do not duplicate these; call them.
line 62

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Nexus Release

Context: a Nexus release is one artifact — a bare X.Y.Z git tag on main. Everything downstream (installing, building, naming the release, uploading main.js / manifest.json / styles.css, provenance attestation) is done by <repo>/.github/workflows/release.yml from the tagged commit. You never build the release; you make the tagged commit correct and then tag it.

Two consequences shape everything here. The tag is the point of no return — the workflow reads the tree as committed at that tag. And the workflow guards only three things, so everything else is on you.

Path convention: <repo>/… means relative to the Nexus repo root. Bare paths (protocols/…, scripts/…) are inside this skill.

Workflow

Cutting a release → follow protocols/cut-release.md end to end, in order. Do not improvise the sequence: several steps only have any effect before the tag exists.
Bringing user-facing docs in line (a phase of the above; also runnable on its own) → protocols/doc-review.md. This includes the media catalog and usage index: identify screenshots/GIFs affected by the release, review or replace them at stable paths, and verify the Your AI Second Brain course callout. Follow <repo>/media/WORKFLOW.md.
Before pushing any tag you MUST get a clean exit from the readiness check. It reproduces the workflow's own version guard locally, so a failure here is a failure you would otherwise discover after the tag exists:
```
python3 .claude/skills/nexus-release/scripts/check_release_ready.py --tag X.Y.Z
```
(--repo defaults to the repo root found by walking up from the working directory. Run --help for the flags; stdlib only, no node_modules. If the mirror above is absent, the same file is at <repo>/.skills/nexus-release/scripts/check_release_ready.py.)
The workflow did not run, failed its guard, or shipped the wrong assets → protocols/recover.md. NEVER hand-create a release or hand-attach assets to fix it — that silently drops provenance attestation.
After a release session → protocols/self-refine.md.

Map

protocols/ the how: cut-release.md, doc-review.md, recover.md, self-refine.md.
references/ the why, read on demand: release-machinery.md (what the workflow really does, what it guards, what it does not, and the build-order asymmetry that decides which generated file can ship stale), changelog-format.md (the conventions the changelog actually follows).
scripts/ check_release_ready.py — version consistency across package.json, manifest.json, versions.json, the lockfile and the tag.
refinement-log.md — what past releases taught this skill.

Siblings

Do not duplicate these; call them.

Need	Skill
Regenerate the tool catalog a release must ship current	`nexus-tool-schemas`
Choose a Jest lane, or debug a failing guidance/drift test	`nexus-testing`
Provider/model metadata that a release happens to include	`nexus-model-updates`
Mobile or plugin-store compliance of what is being shipped	`nexus-mobile-compat`

Editing this skill

<repo>/.skills/ is the source of truth for this skill; .claude/skills/, .codex/skills/ and .cline/skills/ are mirrors written by npm run sync:skills. Edit the copy under <repo>/.skills/nexus-release/ and re-run the sync. The mirror copy overwrites changed files but does not delete extra ones, so editing a mirror leaves a half-reverted hybrid on the next sync.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free