SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsrelease

release

Deployment & operations

View repository

Updated 10-15 21:36

About this skill

Publish zentao-cli

Execute the process from the repository root and follow AGENTS.md. Respect the execution scope specified by the user; when the user requests a full release, complete local release preparation, commit, and tag. Do not discard existing changes on your own, push to the remote, or publish the npm package.

1. Check pre-release status

  1. Run git rev-parse --show-toplevel, confirm you are operating in the zentao-cli repository root.
  2. Run git status --short --branch, record the current branch and workspace status.
  3. If there are uncommitted or untracked files, list the files and pause; ask the user to first commit, stage, or explicitly specify which changes should be included in the release. Do not stage, overwrite, or discard them on your own.
  4. Read package.json current version, and confirm that the corresponding v<当前版本> tag has no obvious conflict with the release history.

2. Collect version and change scope

  1. Run git describe --tags --abbrev=0 to get the most recent tag. If there is no tag, use the entire history as the release scope.
  2. When there is a tag, run git log <最近-tag>..HEAD --oneline; when there is no tag, run git log --oneline。
  3. Also check commit bodies,git diff --stat、git diff --name-status and necessary source diffs. Do not judge user impact or breaking changes based only on commit titles.
  4. If there are no actual changes since the most recent tag, stop and explain that there is nothing to release.
  5. Read CHANGES.md top and most recent version entries, and follow the existing structure, categories, and Chinese wording.
  6. Collect the changes in the release scope under skills/ , and merge them into each top-level skill directory. If there is no tag, treat all currently bundled skills as the initial release scope..agents/skills/ is a project development skill and does not belong to the skills/published with the npm package; do not sync its version number.

3. Confirm the new version number

  • When the user has specified a version number, verify that it is a valid, increasing, and not-yet-used SemVer.package.json Use a bare version number, and use for the tag v<版本号>。
  • When the user has not specified a version number, recommend a version based on the actual impact:
    • There are incompatible CLI, configuration, MCP tool, or bundled skill behavior changes: increment major.
    • There are backward-compatible new commands, new modules, or new capabilities: increment minor.
    • Contains only backward-compatible fixes, documentation, tests, internal refactoring, or maintenance: increment patch.
  • Do not rely only on feat、fix and similar commit prefixes; base it on code and user-visible behavior.
  • When the user has not specified a version in advance, show "current version → recommended version", the main basis for the changes, and the SemVer rationale, and wait for explicit confirmation before modifying files.
  • Before modifying, confirm that v<版本号> does not exist. If the version number is invalid, not increasing, or the tag already exists, stop and handle the conflict.

4. Update release files

Update package.json

Only precisely modify package.json the version field. Do not modify bun.lock; it does not record this project's version. The build script will read from package.json inject BUILD_VERSION, do not set a separate version constant.

Sync the changed bundled skills

  1. Only process the skills/<技能名>/ directories that actually have file changes within the release scope.
  2. For each affected skill, precisely update its SKILL.md frontmatter's metadata.version to the new version number.
  3. Check and edit one by one; do not batch-replace the entire skills/ directory, and do not update unchanged skills.
  4. Record the names of all skills whose version numbers changed, for use in the changelog and final report.

Update CHANGES.md

  1. Based on the commit records and the actual diff, verify whether the content in ## Unreleased is complete, accurate, and deduplicated.

  2. If ## Unreleasedexists, change its title to ## <版本号>; if it does not exist, then in # Changes insert a new version entry after it. Do not keep an extra empty Unreleased entry.

  3. Organize content according to the existing format, keeping only categories with actual content:

    ## <版本号>

### ✨ 新特性 (Feat)

- ...

### 🐛 修复 (Fix)

- ...

### 🚀 优化与重构 (Refactor)

- ...

### ✅ 测试 (Test)

- ...

### 📝 文档 (Docs)

- ...

### 🤸 技能更新（Skill）

- **<技能名称>**:
  - ...

  4. Use concise Chinese descriptions of user impact, merge duplicate commits, ignore pure release housekeeping, and follow the existing punctuation and wording style.

  5. List each changed bundled skill separately under "Skill Updates"; omit this category when there are no skill changes.

5. Verify release content

Run in sequence:

bun run typecheck
bun test
bun run build
node bin/zentao.js -V
npm pack --dry-run --ignore-scripts

Require all commands to succeed, and confirm that the built CLI outputs the new version number. If a command fails, diagnose and fix the root cause first; do not create a release commit or tag.

Then run git diff --check, and check git status --short, the full diff, and the diff stat:

  • Confirm that package.json、CHANGES.md and the affected skill versions are correct.
  • Confirm there are no unexpected modifications to bun.lock, unchanged skills, or other unrelated files.
  • If changes appear that do not belong to this release, pause and explain; do not include them on your own initiative.

6. Create the release commit and tag

  1. Stage only the confirmed package.json、CHANGES.md and the skills/<技能名>/SKILL.mdwhose version numbers actually changed; do not broadly stage the entire workspace.
  2. Run git diff --cached --check, then check the staged diff and stat; handle errors or unexpected files first.
  3. Use the project's agreed English commit message:git commit -m "* release v<版本号>"。
  4. After a successful commit, run git tag v<版本号> to create a lightweight tag.
  5. Do not push automatically. Report the new version number, changelog summary, skills with synchronized versions, verification results, commit, and tag, and inform the user that they can run git push && git push --tags。

7. Optional publish to npm

Continue only after the user explicitly requests or confirms publishing the npm package:

  1. Run npm whoami to check login status; if not logged in, have the user run npm login to complete authentication.
  2. Run bun publish。
  3. After a successful publish, report the zentao-cli npm package。

If publishing fails, keep the local commit and tag, explain the failed step; do not republish, force-move the tag, or rewrite the created version history.