技能详情（站内镜像，无评论）
作者：Kyle Holzinger @avegancafe
许可证：MIT-0
MIT-0 ·免费使用、修改和重新分发。无需归因。
版本：v1.0.1
统计：⭐ 0 · 425 · 0 current installs · 0 all-time installs
⭐ 0
安装量（当前） 0
🛡 VirusTotal ：良性 · OpenClaw ：良性
Package：avegancafe/semver-helper
安全扫描（ClawHub）
- VirusTotal ：良性
- OpenClaw ：良性
OpenClaw 评估
This is an instruction-only semantic versioning reference; its content, required permissions, and runtime instructions are consistent with its stated purpose.
目的
The name and description match the SKILL.md content (a SemVer 2.0.0 reference). The skill requests no binaries, env vars, or config paths — everything requested is proportional to a read-only reference guide.
说明范围
SKILL.md contains only static guidance, decision trees, and examples. It does not instruct the agent to read files, access environment variables, execute commands, or send data to external endpoints.
安装机制
No install specification and no code files are present (instruction-only). Nothing will be written to disk or downloaded during install.
证书
No environment variables, credentials, or config paths are required. There are no secrets requested or implied by the instructions.
持久
The skill does not request always:true and makes no changes to other skills or system config. It is user-invocable and may be invoked autonomously (platform default), which is appropriate for a harmless helper.
综合结论
This skill is a simple, read-only SemVer reference with no installs, no credentials, and no external calls — safe to add. Note that the agent may call the skill autonomously (platform default), but the skill itself has no ability to access secrets or modify system state.
安装（复制给龙虾 AI）
将下方整段复制到龙虾中文库对话中，由龙虾按 SKILL.md 完成安装。
请把本段交给龙虾中文库（龙虾 AI）执行：为本机安装 OpenClaw 技能「Semver Helper」。简介：Semantic Versioning 2.0.0 reference guide. Quick decision trees and examples fo…。
请 fetch 以下地址读取 SKILL.md 并按文档完成安装：https://raw.githubusercontent.com/openclaw/skills/refs/heads/main/skills/avegancafe/semver-helper/SKILL.md
（来源：yingzhi8.cn 技能库）SKILL.md
---
name: semver-helper
description: Semantic Versioning 2.0.0 reference guide. Quick decision trees and examples for choosing MAJOR, MINOR, or PATCH version bumps.
author: Gelmir
tags: [semver, versioning, release]
---
# Semver Helper
Quick reference for Semantic Versioning 2.0.0 decisions.
## The Golden Rule
Given version `MAJOR.MINOR.PATCH`, increment:
| Level | Bump When | Reset Lower? |
|-------|-----------|--------------|
| **MAJOR** (X.0.0) | Breaking changes (incompatible API changes) | Yes, MINOR and PATCH → 0 |
| **MINOR** (0.X.0) | New features (backwards compatible) | Yes, PATCH → 0 |
| **PATCH** (0.0.X) | Bug fixes (backwards compatible) | No |
## Quick Decision Tree
```
Did you change anything users depend on?
├─ No (internal only) → PATCH
└─ Yes
└─ Did you remove/change existing behavior?
├─ Yes → MAJOR
└─ No (only added new stuff)
└─ Is the new stuff visible to users?
├─ Yes → MINOR
└─ No → PATCH
```
## Real Examples
### 🔴 MAJOR (Breaking)
- Remove a function, endpoint, or CLI flag
- Change the return type of a function
- Require a new mandatory parameter
- Change default behavior significantly
- Rename something users depend on
- Upgrade a dependency that forces downstream changes
**Examples:**
- `removeUser()` → `deleteUser()` rename
- API response format changed from `{id: 1}` to `{data: {id: 1}}`
- Dropping support for Node 16 (if users must upgrade)
### 🟡 MINOR (Feature)
- Add new functionality
- Add optional parameters
- Add new exports/exports
- Deprecate old features (warn, don't remove)
- Performance improvements (no API change)
**Examples:**
- Add `createUser()` alongside existing user functions
- Add `--format json` flag to CLI
- Add new event listeners/hooks
- Mark old method as deprecated (still works)
### 🟢 PATCH (Fix)
- Fix bugs without changing intended behavior
- Documentation updates
- Internal refactoring (no visible change)
- Dependency updates (no API change)
- Test additions
**Examples:**
- Fix null pointer exception
- Correct typo in error message
- Fix race condition
- Update README
## Version Progression Examples
| Changes | Version Bump |
|---------|--------------|
| `fix: null pointer` | `1.2.3` → `1.2.4` |
| `feat: add auth` | `1.2.3` → `1.3.0` |
| `breaking: remove old API` | `1.2.3` → `2.0.0` |
| `fix: bug + feat: new thing` | `1.2.3` → `1.3.0` (MINOR wins) |
| `fix: bug + breaking: remove API` | `1.2.3` → `2.0.0` (MAJOR wins) |
## Pre-releases
Use suffixes for testing before stable:
- `2.0.0-alpha.1` — Very early, unstable
- `2.0.0-beta.2` — Feature complete, testing
- `2.0.0-rc.1` — Release candidate, final testing
Pre-releases sort before their stable version:
`1.0.0-alpha < 1.0.0-beta < 1.0.0-rc < 1.0.0`
## Common Edge Cases
| Situation | Bump | Why |
|-----------|------|-----|
| Fix a bug that was introduced *this version* | PATCH | Still a fix |
| Deprecate a feature (but keep it working) | MINOR | New "deprecated" state is info |
| Change undocumented/internal behavior | PATCH | Users shouldn't depend on it |
| Security fix that requires API change | MAJOR | Breaking for security |
| Rewriting internals, same behavior | PATCH | Invisible to users |
| Adding tests/docs only | PATCH | No code change |
## Anti-Patterns
❌ **Don't** bump MAJOR for big new features (unless breaking)
❌ **Don't** bump MINOR for bug fixes
❌ **Don't** bump PATCH for new functionality
❌ **Don't** keep old numbers when bumping: `1.2.3 → 2.2.3` is wrong
## Cheat Sheet
```
Users' code breaks? → MAJOR
Users get new toys? → MINOR
Users get fixes? → PATCH
```