l-make-mcp-release

Release the public zudotext-mcp npm package end to end from its private source repository: prepare a version, verify and land it, push the MCP-only tag, watch trusted publication, and smoke the regist...

/l-make-mcp-release

Publish @takazudo/zudotext-mcp publicly on npm from its permanently private source repository. The tag workflow also creates an authenticated GitHub Release mirror for maintainers.

This skill is deliberately separate from an unqualified zudo-text release, which means the desktop app. The desktop release is not automated by a project-local skill yet, so stop and explain that limitation when it is requested. Never reinterpret it as permission to publish the MCP package.

Autonomy and boundary

Without --confirm, the invocation authorizes the complete MCP release, including the final tag push and monitoring its workflow. With --confirm, perform all safe preparation and verification, show the exact tag and commit, then stop before pushing the tag.

The npm name/version pair is the irreversible boundary. Do not delete or move a published tag or attempt to reuse a published npm version. Fix forward with a new version.

Inputs

• No version argument:

  • If no zudotext-mcp-v* tag exists, release the valid version already in packages/zudotext-mcp/package.json; this establishes the first baseline.

  • Otherwise infer patch, minor, or major from MCP-relevant commits since the newest MCP tag: breaking changes require major, feat requires minor, and all other releasable changes require patch.

• major, minor, or patch: bump that component from the newest MCP tag.

• An exact semantic version: use it after verifying it is newer than the newest MCP tag and is not already tagged or released.

• --confirm: stop before the tag push.

• cancel: close an unmerged release PR and delete its untagged release branch after checking the exact targets. Never remove a published release or tag.

For a no-argument inferred major bump, stop and ask whether to publish the major now or choose an explicit version. This is the only default-path version strategy pause.

For inferred or keyword bumps, require the package version to equal the newest MCP tag's version before calculating the next version. If it differs, stop and reconcile the abandoned or partial preparation explicitly; never overwrite it with a computed version that could be lower. An exact version must also be strictly greater than both the package version and newest tag. The no-tag first release is the exception: an exact version equal to the valid current package version establishes the baseline without rewriting it.

A prepared unpublished version is the other continuation case: when the package version is greater than the newest tag, allow that exact current version only if its tag and GitHub Release are absent and npm already contains the same verified tarball integrity. This resumes a bootstrap or interrupted release without bumping again.

Preconditions

Run all checks before changing files:

1. Require branch main, a clean working tree, successful gh auth status, and local main not behind origin/main after fetching main and tags.

2. Read the current package version and newest tag matching the strict pattern zudotext-mcp-v<semver>. Ignore desktop-app and unrelated package tags.

3. Require .github/workflows/release-zudotext-mcp.yml and verify that the target tag and GitHub Release do not already exist. Check the public npm registry for the package/version too.

4. For later releases, inspect commits in the tag-to-HEAD range only for packages/zudotext-mcp/, its bundled workspace dependencies packages/cloud-crypto/ and packages/file-utils/, and .github/workflows/release-zudotext-mcp.yml. Inspect pnpm-lock.yaml semantically: count a lockfile-only commit only when it changes the packages/zudotext-mcp importer or a resolved package reachable from that importer's runtime/bundled dependency closure. A shared lockfile touch by itself is not MCP-relevant. If the scoped range is empty and no exact higher version was requested, stop: unrelated app changes do not justify an MCP release.

5. Summarize the target version, base tag, categorized commits, files that will change, and the final tag. In default mode this is visibility, not a confirmation gate.

Prepare a later version

Skip this section for the first release when the package already contains the target version and no release tag exists.

1. Create release/zudotext-mcp-v<VERSION> from current main.

2. Run:

   pnpm --dir packages/zudotext-mcp release:version -- <VERSION>
   pnpm --filter @takazudo/zudotext-mcp exec vitest run src/server-inventory.test.ts -u

3. Confirm the version script updated every guarded static consumer listed in packages/zudotext-mcp/RELEASING.md. Review the inventory diff; the snapshot should change only when the tool surface truly changed.

4. Run the verification gate below, commit the reviewed release files, push the branch, open a PR against main, and wait for required CI. Merge only when green, delete the release branch, then update local main and capture its exact commit SHA. Do not tag a pre-merge branch commit.

Verification gate

From repository root, run:

pnpm --filter @takazudo/zudotext-mcp test
pnpm --filter @takazudo/zudotext-mcp typecheck
pnpm --dir packages/zudotext-mcp release:verify -- \
  --expected-tag "zudotext-mcp-v<VERSION>"

Require a clean tracked working tree afterward. The generated packages/zudotext-mcp/dist/release/ output is ignored build evidence, not a file to commit.

Immediately before publishing, re-check that:

• HEAD is the intended clean main commit and is present on origin/main;

• package and README versions match <VERSION>;

• the tag and release are still absent; and

• the verification gate succeeded for that exact tag.

One-time npm bootstrap

If the package name does not exist on npm, stop before the tag push. A new npm package cannot configure trusted or staged publishing until an owner performs one direct publish. Ask the user to follow the exact bootstrap section in packages/zudotext-mcp/RELEASING.md, then verify the registry version and tarball integrity. After that, require the user to configure the named trusted publisher before resuming the tag push. Never request or store an npm token.

Publish and watch

Unless --confirm was passed:

git tag "zudotext-mcp-v<VERSION>" <MAIN_SHA>
git push origin "zudotext-mcp-v<VERSION>"

Find the run created by the just-completed push and require all of its identity fields to match: workflow path .github/workflows/release-zudotext-mcp.yml, workflow name Release zudotext-mcp, event push, head branch/ref zudotext-mcp-v<VERSION>, and head SHA <MAIN_SHA>. If multiple attempts or runs share the SHA, select the current attempt for that exact tag and inspect its creation time/run ID. Do not use a sibling tag, older attempt, or branch CI run as release evidence.

After it succeeds, require all of the following:

1. npm view @takazudo/zudotext-mcp@<VERSION> reports the exact version and the registry dist.integrity matches the locally verified tarball.

2. A fresh temporary-prefix install of @takazudo/zudotext-mcp@<VERSION> succeeds, and its installed zudotext-mcp --version prints <VERSION>.

3. gh release view zudotext-mcp-v<VERSION> reports a published, non-draft maintainer mirror at the exact tag.

4. The mirror contains exactly the expected package asset zudotext-mcp-v<VERSION>.tgz (apart from GitHub-generated source archives).

5. The repository remains clean on main.

Report the npm package/version, integrity, tag SHA, workflow URL/result, mirror release URL/asset, and installed version. A credentialed live-workspace verification is a separate post-release lane; never call missing credentials a package-release failure.

Failure recovery

• Before npm or tag publication: leave or repair the release PR/branch; no immutable release exists.

• npm bootstrap succeeds but trusted publisher setup is pending: keep the tag absent, verify the published bytes, and wait for the owner configuration.

• Workflow failure after tag push: retain the tag and diagnose the exact run. If tagged contents or tagged workflow source need a change, fix forward with a higher version. If the failure is transient infrastructure and the exact tag still points to the intended immutable SHA, rerun that workflow attempt only after proving there is no conflicting release or asset. Never move, delete, or recreate the tag.

• Workflow success but install smoke failure: preserve the release as evidence, file a blocking issue, and prepare a higher patch version.

• Timeout or ambiguous state: inspect the tag, release, and exact-SHA workflow before retrying any mutation.

The package's canonical implementation details remain in packages/zudotext-mcp/RELEASING.md; follow that document if it becomes stricter than this orchestration skill.