Token导航 LogoToken导航

Agent Skill · 效率

universal-release(通用发布)

universal-release 用于辅助 Python 项目开发、测试和数据处理,适合在 OpenClaw 中需要阅读 Python 代码、运行测试或整理脚本流程时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

universal-release 是效率类 Agent Skill,可用宿主为 OpenClaw,通过ClawHub获取,权限为需要联网;许可证为 MIT-0,第三方扫描有提醒项,按安装量在效率类的 21,003 个 Skill 里排第 7,719。

总安装 7,824周安装 326GitHub Stars 公开资料未说明下载 2,608核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT-0
版本
1.0.0

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:universal-release(通用发布)
来源仓库:https://github.com/zoopools/universal-release
安装命令:
openclaw skills install universal-release
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install universal-release

这个 Skill 是做什么的

效率类 Skill 把重复的整理、汇总、转换工作交给助手完成,减少手工复制粘贴。

自动检测版本文件并管理发布流程的工具集。支持 Node.js、Python、Rust 等多种技术栈项目。当提及“发布新版本”或更新 changelog 时触发使用。需确保 CI/CD 环境与权限配置正确无误。universal-release 属于效率类 Skill,可作为该场景下的辅助能力补充。

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 OpenClaw;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 openclaw skills install universal-release;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

universal-release 怎么安装?

在终端执行 openclaw skills install universal-release。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

universal-release 支持哪些 AI 工具?

公开资料标注支持 OpenClaw。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

universal-release 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

universal-release 是免费的吗?

来源标注的许可证是 MIT-0。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

universal-release 用的人多吗?

公开数据是累计安装 7,824 次,近一周安装 326 次,下载 2,608 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

universal-release 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 专注 OpenClaw 一种宿主,触发方式和使用习惯不用来回切换。
  • 许可证明确为 MIT-0,商用和分发边界好判断。

先想清楚的地方

  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 OpenClaw,想直接扩展它能力的人。
  • 需要处理效率类任务、又不想每次都手写提示词的人。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

效率类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
github

GitHub 代码协作 · OpenClaw

7,632,918545需要联网MIT-0通过
nano-pdf

Nano PDF 文档 · OpenClaw

4,249,476231需要联网MIT-0通过
auto-updater

自动更新程序 · OpenClaw

2,964,063386操作浏览器MIT-0通过
video-frames

视频帧 · OpenClaw

2,621,304112需要联网MIT-0通过
gemini

Gemini 助手 · OpenClaw

2,547,39648需要联网MIT-0有提醒
universal-release

通用发布 · 本页

7,824—需要联网MIT-0有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
release-skills
description
Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送".

Release Skills

Universal release workflow supporting any project type with multi-language changelog.

Quick Start

Just run /release-skills - auto-detects your project configuration.

Supported Projects

Project TypeVersion FileAuto-Detected
Node.jspackage.json✓
Pythonpyproject.toml✓
RustCargo.toml✓
Claude Pluginmarketplace.json✓
GenericVERSION / version.txt✓

Options

FlagDescription
--dry-runPreview changes without executing
--majorForce major version bump
--minorForce minor version bump
--patchForce patch version bump

Workflow

Step 1: Detect Project Configuration

  1. Check for .releaserc.yml (optional config override)
  2. Auto-detect version file by scanning (priority order):

- package.json (Node.js) - pyproject.toml (Python) - Cargo.toml (Rust) - marketplace.json or .claude-plugin/marketplace.json (Claude Plugin) - VERSION or version.txt (Generic)

  1. Scan for changelog files using glob patterns:

- CHANGELOG*.md - HISTORY*.md - CHANGES*.md

  1. Identify language of each changelog by filename suffix
  2. Display detected configuration

Language Detection Rules:

Changelog files follow the pattern CHANGELOG_{LANG}.md or CHANGELOG.{lang}.md, where {lang} / {LANG} is a language or region code.

PatternExampleLanguage
No suffixCHANGELOG.mden (default)
_{LANG} (uppercase)CHANGELOG_CN.md, CHANGELOG_JP.mdCorresponding language
.{lang} (lowercase)CHANGELOG.zh.md, CHANGELOG.ja.mdCorresponding language
.{lang-region}CHANGELOG.zh-CN.mdCorresponding region variant

Common language codes: zh (Chinese), ja (Japanese), ko (Korean), de (German), fr (French), es (Spanish).

Output Example:

Project detected:
  Version file: package.json (1.2.3)
  Changelogs:
    - CHANGELOG.md (en)
    - CHANGELOG.zh.md (zh)
    - CHANGELOG.ja.md (ja)

Step 2: Analyze Changes Since Last Tag

LAST_TAG=$(git tag --sort=-v:refname | head -1)
git log ${LAST_TAG}..HEAD --oneline
git diff ${LAST_TAG}..HEAD --stat

Categorize by conventional commit types:

TypeDescription
featNew features
fixBug fixes
docsDocumentation
refactorCode refactoring
perfPerformance improvements
testTest changes
styleFormatting, styling
choreMaintenance (skip in changelog)

Breaking Change Detection:

  • Commit message starts with BREAKING CHANGE
  • Commit body/footer contains BREAKING CHANGE:
  • Removed public APIs, renamed exports, changed interfaces

If breaking changes detected, warn user: "Breaking changes detected. Consider major version bump (--major flag)."

Step 3: Determine Version Bump

Rules (in priority order):

  1. User flag --major/--minor/--patch → Use specified
  2. BREAKING CHANGE detected → Major bump (1.x.x → 2.0.0)
  3. feat: commits present → Minor bump (1.2.x → 1.3.0)
  4. Otherwise → Patch bump (1.2.3 → 1.2.4)

Display version change: 1.2.3 → 1.3.0

Step 4: Generate Multi-language Changelogs

For each detected changelog file:

  1. Identify language from filename suffix
  2. Detect third-party contributors:

- Check merge commits: git log ${LAST_TAG}..HEAD --merges --pretty=format:"%H %s" - For each merged PR, identify the PR author via gh pr view <number> --json author --jq '.author.login' - Compare against repo owner (gh repo view --json owner --jq '.owner.login') - If PR author ≠ repo owner → third-party contributor

  1. Generate content in that language:

- Section titles in target language - Change descriptions written naturally in target language (not translated) - Date format: YYYY-MM-DD (universal) - Third-party contributions: Append contributor attribution (by @username) to the changelog entry

  1. Insert at file head (preserve existing content)

Section Title Translations (built-in):

Typeenzhjakodefres
featFeatures新功能新機能새로운 기능FunktionenFonctionnalitésCaracterísticas
fixFixes修复修正수정FehlerbehebungenCorrectionsCorrecciones
docsDocumentation文档ドキュメント문서DokumentationDocumentationDocumentación
refactorRefactor重构リファクタリング리팩토링RefactoringRefactorisationRefactorización
perfPerformance性能优化パフォーマンス성능LeistungPerformanceRendimiento
breakingBreaking Changes破坏性变更破壊的変更주요 변경사항Breaking ChangesChangements majeursCambios importantes

Changelog Format:

## {VERSION} - {YYYY-MM-DD}

### Features
- Description of new feature
- Description of third-party contribution (by @username)

### Fixes
- Description of fix

### Documentation
- Description of docs changes

Only include sections that have changes. Omit empty sections.

Third-Party Attribution Rules:

  • Only add (by @username) for contributors who are NOT the repo owner
  • Use GitHub username with @ prefix
  • Place at the end of the changelog entry line
  • Apply to all languages consistently (always use (by @username) format, not translated)

Multi-language Example:

English (CHANGELOG.md):

## 1.3.0 - 2026-01-22

### Features
- Add user authentication module (by @contributor1)
- Support OAuth2 login

### Fixes
- Fix memory leak in connection pool

Chinese (CHANGELOG.zh.md):

## 1.3.0 - 2026-01-22

### 新功能
- 新增用户认证模块 (by @contributor1)
- 支持 OAuth2 登录

### 修复
- 修复连接池内存泄漏问题

Japanese (CHANGELOG.ja.md):

## 1.3.0 - 2026-01-22

### 新機能
- ユーザー認証モジュールを追加 (by @contributor1)
- OAuth2 ログインをサポート

### 修正
- コネクションプールのメモリリークを修正

Step 5: Group Changes by Skill/Module

Analyze commits since last tag and group by affected skill/module:

  1. Identify changed files per commit
  2. Group by skill/module:

- skills/<skill-name>/* → Group under that skill - Root files (CLAUDE.md, etc.) → Group as "project" - Multiple skills in one commit → Split into multiple groups

  1. For each group, identify related README updates needed

Example Grouping:

baoyu-cover-image:
  - feat: add new style options
  - fix: handle transparent backgrounds
  → README updates: options table

baoyu-comic:
  - refactor: improve panel layout algorithm
  → No README updates needed

project:
  - docs: update CLAUDE.md architecture section

Step 6: Commit Each Skill/Module Separately

For each skill/module group (in order of changes):

  1. Check README updates needed:

- Scan README*.md for mentions of this skill/module - Verify options/flags documented correctly - Update usage examples if syntax changed - Update feature descriptions if behavior changed

  1. Stage and commit:
   git add skills/<skill-name>/*
   git add README.md README.zh.md  # If updated for this skill
   git commit -m "<type>(<skill-name>): <meaningful description>"
  1. Commit message format:

- Use conventional commit format: <type>(<scope>): <description> - <type>: feat, fix, refactor, docs, perf, etc. - <scope>: skill name or "project" - <description>: Clear, meaningful description of changes

Example Commits:

git commit -m "feat(baoyu-cover-image): add watercolor and minimalist styles"
git commit -m "fix(baoyu-comic): improve panel layout for long dialogues"
git commit -m "docs(project): update architecture documentation"

Common README Updates Needed:

Change TypeREADME Section to Check
New options/flagsOptions table, usage examples
Renamed optionsOptions table, usage examples
New featuresFeature description, examples
Breaking changesMigration notes, deprecation warnings
Restructured internalsArchitecture section (if exposed to users)

Step 7: Generate Changelog and Update Version

  1. Generate multi-language changelogs (as described in Step 4)
  2. Update version file:

- Read version file (JSON/TOML/text) - Update version number - Write back (preserve formatting)

Version Paths by File Type:

FilePath
package.json$.version
pyproject.tomlproject.version
Cargo.tomlpackage.version
marketplace.json$.metadata.version
VERSION / version.txtDirect content

Step 8: User Confirmation

Before creating the release commit, ask user to confirm:

Use AskUserQuestion with two questions:

  1. Version bump (single select):

- Show recommended version based on Step 3 analysis - Options: recommended (with label), other semver options - Example: 1.2.3 → 1.3.0 (Recommended), 1.2.3 → 1.2.4, 1.2.3 → 2.0.0

  1. Push to remote (single select):

- Options: "Yes, push after commit", "No, keep local only"

Example Output Before Confirmation:

Commits created:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation

Changelog preview (en):
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

Ready to create release commit and tag.

Step 9: Create Release Commit and Tag

After user confirmation:

  1. Stage version and changelog files:
   git add <version-file>
   git add CHANGELOG*.md
  1. Create release commit:
   git commit -m "chore: release v{VERSION}"
  1. Create tag:
   git tag v{VERSION}
  1. Push if user confirmed (Step 8):
   git push origin main
   git push origin v{VERSION}

Note: Do NOT add Co-Authored-By line. This is a release commit, not a code contribution.

Post-Release Output:

Release v1.3.0 created.

Commits:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. docs(project): update architecture documentation
  4. chore: release v1.3.0

Tag: v1.3.0
Status: Pushed to origin  # or "Local only - run git push when ready"

Configuration (.releaserc.yml)

Optional config file in project root to override defaults:

# .releaserc.yml - Optional configuration

# Version file (auto-detected if not specified)
version:
  file: package.json
  path: $.version  # JSONPath for JSON, dotted path for TOML

# Changelog files (auto-detected if not specified)
changelog:
  files:
    - path: CHANGELOG.md
      lang: en
    - path: CHANGELOG.zh.md
      lang: zh
    - path: CHANGELOG.ja.md
      lang: ja

  # Section mapping (conventional commit type → changelog section)
  # Use null to skip a type in changelog
  sections:
    feat: Features
    fix: Fixes
    docs: Documentation
    refactor: Refactor
    perf: Performance
    test: Tests
    chore: null

# Commit message format
commit:
  message: "chore: release v{version}"

# Tag format
tag:
  prefix: v  # Results in v1.0.0
  sign: false

# Additional files to include in release commit
include:
  - README.md
  - package.json

Dry-Run Mode

When --dry-run is specified:

=== DRY RUN MODE ===

Project detected:
  Version file: package.json (1.2.3)
  Changelogs: CHANGELOG.md (en), CHANGELOG.zh.md (zh)

Last tag: v1.2.3
Proposed version: v1.3.0

Changes grouped by skill/module:
  baoyu-cover-image:
    - feat: add watercolor style
    - feat: add minimalist style
    → Commit: feat(baoyu-cover-image): add watercolor and minimalist styles
    → README updates: options table

  baoyu-comic:
    - fix: panel layout for long dialogues
    → Commit: fix(baoyu-comic): improve panel layout for long dialogues
    → No README updates

Changelog preview (en):
  ## 1.3.0 - 2026-01-22
  ### Features
  - Add watercolor and minimalist styles to cover-image
  ### Fixes
  - Improve panel layout for long dialogues in comic

Changelog preview (zh):
  ## 1.3.0 - 2026-01-22
  ### 新功能
  - 为 cover-image 添加水彩和极简风格
  ### 修复
  - 改进 comic 长对话的面板布局

Commits to create:
  1. feat(baoyu-cover-image): add watercolor and minimalist styles
  2. fix(baoyu-comic): improve panel layout for long dialogues
  3. chore: release v1.3.0

No changes made. Run without --dry-run to execute.

Example Usage

/release-skills              # Auto-detect version bump
/release-skills --dry-run    # Preview only
/release-skills --minor      # Force minor bump
/release-skills --patch      # Force patch bump
/release-skills --major      # Force major bump (with confirmation)

When to Use

Trigger this skill when user requests:

  • "release", "发布", "create release", "new version", "新版本"
  • "bump version", "update version", "更新版本"
  • "prepare release"
  • "push to remote" (with uncommitted changes)

Important: If user says "just push" or "直接 push" with uncommitted changes, STILL follow all steps above first.

平台分布

OpenClaw

92.62%
按下载量换算2,416

安全审计

VirusTotal

通过

ClawScan

可疑

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills