agentleFS
openclawopenclaw/clawpatch/.agents/skills/release-clawpatch/SKILL.md

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
  1. Very specific:

    Use $npm and $one-password rules for registry auth.

    line 12
  2. Distinctive:

    Start clean on main.

    line 16
  3. Distinctive:

    Ensure release notes are the changelog body for that version and include all user-facing changes.

    line 26
  4. Very specific:

    Run pnpm install --lockfile-only.

    line 27
  5. Distinctive:

    Commit and push release prep.

    line 33
  6. Distinctive:

    Do not publish until release-commit CI and CodeQL are green.

    line 39
  7. Distinctive:

    Use a temp npmrc, never the default user npmrc.

    line 42
  8. Distinctive:

    If publish says the version already exists, verify npm metadata and continue only if it matches the release commit/package contents.

    line 49
  9. Distinctive:

    Verify npm before GitHub release.

    line 51
  10. Distinctive:

    Use temp files for public GitHub bodies.

    line 62
  11. Very specific:

    Add next patch section at top of CHANGELOG.md: ## X.Y.(Z+1) - Unreleased.

    line 74
  12. Distinctive:

    Do not create the GitHub release before npm publish is verified.

    line 82
  13. Distinctive:

    If npm auth scripts fail, keep the same tmux session.

    line 83
  14. Very specific:

    Avoid broad secret inspection.

    line 84

≈ “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.

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

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

  1. Start clean on main.
    • cd ~/Projects/clawpatch
    • git status --short --branch
    • git pull --ff-only
    • Confirm target version is not already tagged or released: git tag --list "vX.Y.Z" and gh release view vX.Y.Z --repo openclaw/clawpatch.
    • Confirm npm state: npm view clawpatch version dist-tags time --json.
  2. Prep release files.
    • Set package.json version to target.
    • Change top changelog section from Unreleased to X.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.
  3. Prove locally before publishing.
    • Run pnpm typecheck && pnpm lint && pnpm format:check && pnpm test && pnpm build && pnpm pack:smoke.
    • Fix failures before continuing.
  4. 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,headSha
      • gh run view <run_id> --repo openclaw/clawpatch --json status,conclusion,url,jobs
    • Do not publish until release-commit CI and CodeQL are green.
  5. 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 npmjs 1Password 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.
  6. 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, latest points to X.Y.Z, tarball URL exists, integrity exists, publish time exists.
  7. 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.Z
    • gh release create vX.Y.Z --repo openclaw/clawpatch --title "vX.Y.Z" --notes-file "$notes"
  8. Release verify.
    • npm view clawpatch@X.Y.Z version dist-tags.latest dist.tarball dist.integrity time.X.Y.Z --json
    • gh 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.
  9. 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.

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 npmjs fields only.
  • Public gh comments/releases should use temp --body-file / --notes-file, not inline quoted bodies.

Download now (ZIP)

  • In this repository2 other files it gives its agents.

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.