release-and-publish
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Required · GitHub
- Operating systems
- macOS
- Runtime requirements
- Bun
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: release-and-publish
description: > Use when this capability is needed. This skill runs after git wrapup. By the time it's invoked…
category: ai
runtime: Bun
---
# release-and-publish output preview
## PART A: Task fit
- Use case: > Use when this capability is needed. This skill runs after git wrapup. By the time it's invoked: If any are missing, halt and tell the user to finish wrapup first. Do not attempt to redo wrapup work from inside this skill. requires GitHub API key; runs on Bun. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Preconditions / Failure Protocol / Steps” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Use when this capability is needed. This skill runs after git wrapup. By the time it's invoked: If any are missing, halt and tell the user to finish wrapup first. Do not attempt to redo wrapup work from inside this skill. requires GitHub API key; runs on Bun. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Preconditions / Failure Protocol / Steps” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; requires GitHub API keys.
## Running Rules
- read files, write/modify files; may access external network resources; requires GitHub API keys.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Preconditions / Failure Protocol / Steps”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: release-and-publish
description: > Use when this capability is needed. This skill runs after git wrapup. By the time it's invoked…
category: ai
source: tomevault-io/skills-registry
---
# release-and-publish
## When to use
- > Use when this capability is needed. This skill runs after git wrapup. By the time it's invoked: If any are missing…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Preconditions / Failure Protocol / Steps” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; requires GitHub API keys.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "release-and-publish" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Preconditions / Failure Protocol / Steps
rules -> SKILL.md triggers / order / output contract
runtime -> Bun | read files, write/modify files | may access external network resources
guardrails -> requires GitHub API keys + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Preconditions
This skill runs after git wrapup. By the time it's invoked:
package.jsonversion is bumpedserver.jsonversion is bumped (top-level + each package entry)CHANGELOG.mdhas a new entry for this version with a concrete date (never[Unreleased])- README badges and version-bearing files are in sync
- Release commit (
chore: release v<version>) exists - Annotated tag (
v<version>) exists locally - Working tree is clean
If any are missing, halt and tell the user to finish wrapup first. Do not attempt to redo wrapup work from inside this skill.
Failure Protocol
Stop on the first non-zero exit. No retries, no remediation from inside the skill. Report to the user:
- Which step failed
- The exact error output
- Which destinations already received the release (npm published? tag pushed?) so they know the partial state
The user fixes locally and re-invokes, or runs the remaining steps manually. Publishes hard-fail with "version already exists" if replayed — that's the signal the step already succeeded.
Steps
1. Sanity-check wrapup outputs
Read package.json → capture version. Read server.json → verify top-level version matches and every packages[].version matches. Then verify git state:
git status --porcelain # must be empty — clean working tree
git describe --exact-match --tags HEAD 2>&1 # must equal v<version>
git rev-parse --abbrev-ref HEAD # note the branch nameIf working tree is dirty, HEAD isn't on v<version>, or server.json versions drift from package.json, halt.
2. Run the verification gate
All three must succeed:
bun run devcheck
bun run rebuild
bun testAny non-zero exit → halt with the failing command's output.
devcheck runs lint + format + typecheck + bun audit. rebuild is a clean + bun build to catch build-time regressions devcheck alone can miss.
3. Push to origin
git push
git push --tagsIf the remote rejects either push, halt. On a fresh branch, git push may need -u origin <branch> — read the error and re-run if that's the only gap.
4. Publish to npm
bun publish --access publicbun publish uses whatever npm auth the user has configured in ~/.npmrc. If 2FA is enabled on the npm account, the command will prompt for an OTP or open a browser — that's expected; the user completes it interactively.
Friction reducers (optional, configure once):
| Option | How |
|---|---|
| npm granular access token with "Bypass 2FA for publish" | Generate at npmjs.com → replace _authToken in ~/.npmrc → no OTP prompt at all |
1Password CLI TOTP injection (requires brew install --cask 1password-cli + signed-in op) |
bun publish --access public --otp="$(op item get 'npm' --otp)" |
Halt on publish error other than "version already exists" (which means this step already ran).
5. Publish to MCP Registry
bun run publish-mcpThis repo's publish-mcp script is defined in package.json and runs scripts/validate-mcp-publish-schema.ts before invoking mcp-publisher. Reads server.json at the repo root.
Prereqs:
- A GitHub PAT with
read:org+read:userscopes, reachable by thepublish-mcpscript (conventionally stored in Keychain under servicemcp-publisher-github-paton macOS) mcp-publisherCLI installed (npm i -g mcp-publisherorbrew install mcp-publisher)
If the Keychain entry doesn't exist:
security add-generic-password -a "$USER" -s mcp-publisher-github-pat -w
# paste PAT at the silent promptHalt on any publisher error other than "cannot publish duplicate version".
6. Report the deployed artifacts
Print clickable URLs for every destination that succeeded:
- npm:
https://www.npmjs.com/package/@cyanheads/git-mcp-server/v/<version> - MCP Registry:
https://registry.modelcontextprotocol.io/v0/servers?search=io.github.cyanheads/git-mcp-server - GitHub release tag:
https://github.com/cyanheads/git-mcp-server/releases/tag/v<version>
Skip any destination that was skipped or failed in its step.
Optional: Create a GitHub Release
The annotated tag is enough for npm/MCP Registry. A GitHub Release adds a human-readable changelog page and optional assets. Skip unless the project publishes releases to GitHub Releases specifically.
gh release create "v<version>" \
--title "v<version>" \
--notes-file <(awk "/^## v<version>/,/^## v/" CHANGELOG.md | sed '$d')The awk expression extracts just the current version's section from CHANGELOG.md.
Checklist
- Working tree clean; HEAD tagged
v<version> -
package.jsonandserver.jsonversions match -
bun run devcheckpasses -
bun run rebuildsucceeds -
bun testpasses -
git pushsucceeds -
git push --tagssucceeds -
bun publish --access publicsucceeds -
bun run publish-mcpsucceeds - Deployed artifact URLs reported to the user
Source: cyanheads/git-mcp-server — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review