release-clawpatch
Skill815 starsChanged 5 months agoMITView on GitHub
clawpatch release: version/changelog, CI, npm publish, GitHub release, verify.
- Installs packages
- Commits and pushes
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 10 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Use $npm and $one-password rules for registry auth.
- Distinctive: line 16
Start clean on main.
- Distinctive: line 26
Ensure release notes are the changelog body for that version and include all user-facing changes.
- Very specific: line 27
Run pnpm install --lockfile-only.
- Distinctive: line 33
Commit and push release prep.
- Distinctive: line 39
Do not publish until release-commit CI and CodeQL are green.
- Distinctive: line 42
Use a temp npmrc, never the default user npmrc.
- Distinctive: line 49
If publish says the version already exists, verify npm metadata and continue only if it matches the release commit/package contents.
- Distinctive: line 51
Verify npm before GitHub release.
- Distinctive: line 62
Use temp files for public GitHub bodies.
- Very specific: line 74
Add next patch section at top of CHANGELOG.md: ## X.Y.(Z+1) - Unreleased.
- Distinctive: line 82
Do not create the GitHub release before npm publish is verified.
- Distinctive: line 83
If npm auth scripts fail, keep the same tmux session.
- Very specific: line 84
Avoid broad secret inspection.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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.
Files
Clawpatch Release
Scope
Release ~/Projects/clawpatch as the public npm package clawpatch.
Use $npm and $one-password rules for registry auth. Keep all op and npm secret work inside one persistent tmux session and temp npmrc. Never print tokens, passwords, or OTPs.
Workflow
- Start clean on
main.cd ~/Projects/clawpatchgit status --short --branchgit pull --ff-only- Confirm target version is not already tagged or released:
git tag --list "vX.Y.Z"andgh release view vX.Y.Z --repo openclaw/clawpatch. - Confirm npm state:
npm view clawpatch version dist-tags time --json.
- Prep release files.
- Set
package.jsonversion to target. - Change top changelog section from
UnreleasedtoX.Y.Z - YYYY-MM-DD. - Ensure release notes are the changelog body for that version and include all user-facing changes.
- Run
pnpm install --lockfile-only; commit lockfile only if it actually changes.
- Set
- Prove locally before publishing.
- Run
pnpm typecheck && pnpm lint && pnpm format:check && pnpm test && pnpm build && pnpm pack:smoke. - Fix failures before continuing.
- Run
- Commit and push release prep.
- Commit with
committer "chore(release): X.Y.Z" CHANGELOG.md package.json [pnpm-lock.yaml]. git push origin main.- Watch CI/CodeQL for the release commit:
gh run list --repo openclaw/clawpatch --branch main --commit <sha> --json databaseId,workflowName,status,conclusion,url,headShagh run view <run_id> --repo openclaw/clawpatch --json status,conclusion,url,jobs
- Do not publish until release-commit CI and CodeQL are green.
- Commit with
- Publish npm.
- Use a temp npmrc, never the default user npmrc.
- First try
npm whoami; if unauthenticated, use npm web login in the tmux session:NPM_CONFIG_USERCONFIG="$tmp_npmrc" npm login --auth-type=web --registry=https://registry.npmjs.org/- Open/approve browser login if prompted.
- For publish, fetch a fresh OTP from the
npmjs1Password item inside the same tmux session. - Publish with
NPM_CONFIG_USERCONFIG="$tmp_npmrc" npm publish --access public --otp "$NPM_OTP". - Clean temp npmrc/work dirs after publish.
- If publish says the version already exists, verify npm metadata and continue only if it matches the release commit/package contents.
- Verify npm before GitHub release.
npm view clawpatch@X.Y.Z version dist-tags dist.tarball dist.integrity time --json- Required: version is
X.Y.Z,latestpoints toX.Y.Z, tarball URL exists, integrity exists, publish time exists.
- Tag and create GitHub release.
- Build release notes from changelog plus npm/proof:
- npm version page
- registry tarball
- integrity string
- CI and CodeQL run URLs
- local proof command
- Use temp files for public GitHub bodies.
git tag -a vX.Y.Z <release_sha> -m "vX.Y.Z"git push origin vX.Y.Zgh release create vX.Y.Z --repo openclaw/clawpatch --title "vX.Y.Z" --notes-file "$notes"
- Build release notes from changelog plus npm/proof:
- Release verify.
npm view clawpatch@X.Y.Z version dist-tags.latest dist.tarball dist.integrity time.X.Y.Z --jsongh release view vX.Y.Z --repo openclaw/clawpatch --json tagName,url,body,isDraft,isPrerelease- Confirm release body contains changelog notes, npm version link, tarball, integrity, and CI/proof.
- Confirm tag points at the release commit:
git rev-list -n1 vX.Y.Z.
- Post-release closeout.
- Add next patch section at top of
CHANGELOG.md:## X.Y.(Z+1) - Unreleased. - Commit with
committer "docs(changelog): open X.Y.(Z+1)" CHANGELOG.md. - Push
main. - Watch closeout CI until green.
- Final:
git checkout main && git pull --ff-only && git status --short --branch.
- Add next patch section at top of
Notes
- Do not create the GitHub release before npm publish is verified; the release body must include npm proof.
- If npm auth scripts fail, keep the same tmux session. Do not start a second secret session unless the first is unusable.
- Avoid broad secret inspection. Query exact
npmjsfields only. - Public
ghcomments/releases should use temp--body-file/--notes-file, not inline quoted bodies.
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
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.

