npx skills add https://github.com/ahmedhamadto/software-forge --skill release指导专业的发布流程:确定版本更新、编写结构化的发布说明、更新变更日志、提交、打标签并推送。确保发布的一致性和质量。
开始时宣布: "我正在使用发布技能来创建新版本。"
不应使用的情况:
所有提交和标签的作者都是用户,而不是 Claude。
Co-Authored-By: Claude 或任何 AI 归属信息Co-Authored-By 尾注git config user.name 和 git config user.email 中配置的人员广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
在开始之前:
main 分支或发布分支。如果在功能分支上,请与用户确认。package.json、Cargo.toml、pyproject.toml、RELEASE-NOTES.md、git 标签或项目跟踪其版本的任何位置。读取自上一个发布标签以来的提交历史以了解更改内容:
git log <last-tag>..HEAD --oneline
应用语义化版本控制:
| 变更类型 | 更新 | 示例 |
|---|---|---|
| 破坏性的 API/行为变更 | 主版本 (X.0.0) | 移除功能、重命名公共 API、更改数据格式 |
| 新功能、新阶段、新技能 | 次版本 (x.Y.0) | 添加技能、添加阶段、新功能 |
| 错误修复、拼写错误、文档更新、重构 | 修订版本 (x.y.Z) | 修复拼写错误、更正阶段编号、更新文档 |
向用户呈现建议:
基于自 vX.Y.Z 以来的更改,我建议进行次版本更新至 vX.Y+1.0:
- [列出关键变更]
这看起来正确吗?或者您希望使用其他版本?
在继续之前等待确认。
阅读现有的 RELEASE-NOTES.md 以匹配项目已建立的风格和结构。新条目必须在语气、标题级别和格式上与之前的条目保持一致。
发布说明结构:
## vX.Y.Z (YYYY-MM-DD)
### [章节标题 — 描述主题]
[叙述性段落,解释主要变更。它是什么,为什么重要,以及高层次的工作原理。]
### [根据需要添加其他章节]
[在描述性标题下对相关变更进行分组。并非每个变更都需要自己的章节 — 将小的变更分组在一起。]
### 完整变更日志
- 类型: 变更描述
- 类型: 变更描述
规则:
feat:、fix:、refactor:、docs:、chore:)更新每个清单文件中的版本字符串:
| 文件 | 需要更新的字段 |
|---|---|
| .claude-plugin/plugin.json | .version |
| .claude-plugin/marketplace.json | .metadata.version AND .plugins[].version |
| .cursor-plugin/plugin.json | .version (如果存在) |
| .codex/plugin.json | .version (如果存在) |
| package.json | .version |
| Cargo.toml / pyproject.toml | version 字段 |
同时检查 README 徽章或版本引用。
暂存所有与发布相关的更改并创建单个发布提交:
git add -A
git commit -m "release: vX.Y.Z — [主要变更的单行摘要]"
没有 Co-Authored-By 尾注。没有 AI 归属。
创建带注释的标签:
git tag -a vX.Y.Z -m "vX.Y.Z"
在推送前询问用户:
准备将发布提交和标签推送到 origin。是否继续?
如果确认:
git push && git push --tags
在完整变更日志部分使用这些前缀:
| 前缀 | 含义 |
|---|---|
feat: | 新功能或能力 |
fix: | 错误修复 |
refactor: | 代码重构,行为不变 |
docs: | 仅文档 |
chore: | 构建、CI、依赖项、工具 |
perf: | 性能改进 |
test: | 测试添加或修复 |
style: | 格式化、空白(逻辑不变) |
| 错误 | 修正方法 |
|---|---|
| 未运行测试就发布 | 始终在步骤 1 中运行测试 |
| 提交信息为"更新版本" | 使用 release: vX.Y.Z — [摘要] |
| 添加 AI 共同作者 | 用户就是作者。仅此而已。 |
| 将原始 git 日志转储为发布说明 | 编写人类愿意阅读的叙述性发布说明 |
| 跳过打标签 | 标签是用户和工具识别发布的方式 |
| 强制推送发布 | 绝不。如果出现问题,请创建新的修订版本发布。 |
| 从功能分支发布 | 除非用户明确确认,否则发布应来自 main 分支 |
每周安装次数
1
仓库
GitHub 星标
4
首次出现
1 天前
安全审计
安装于
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
Guides a professional release process: determines the version bump, writes structured release notes, updates the changelog, commits, tags, and pushes. Ensures consistency and quality across releases.
Announce at start: "I'm using the release skill to cut a new version."
When NOT to use:
All commits and tags are authored by the user, not by Claude.
Co-Authored-By: Claude or any AI attribution to commitsCo-Authored-By trailers of any kindgit config user.name and git config user.emailBefore anything else:
main or a release branch. If on a feature branch, confirm with the user.package.json, Cargo.toml, pyproject.toml, RELEASE-NOTES.md, git tags, or wherever the project tracks its version.Read the commit history since the last release tag to understand what changed:
git log <last-tag>..HEAD --oneline
Apply Semantic Versioning:
| Change Type | Bump | Examples |
|---|---|---|
| Breaking API/behavior changes | Major (X.0.0) | Removed feature, renamed public API, changed data format |
| New features, new phases, new skills | Minor (x.Y.0) | Added skill, added phase, new capability |
| Bug fixes, typos, doc updates, refactors | Patch (x.y.Z) | Fixed typo, corrected phase number, updated docs |
Present the recommendation to the user:
Based on the changes since vX.Y.Z, I recommend a minor bump to vX.Y+1.0:
- [list key changes]
Does this look right, or would you prefer a different version?
Wait for confirmation before proceeding.
Read the existing RELEASE-NOTES.md to match the project's established style and structure. The new entry must be consistent with previous entries in tone, heading levels, and formatting.
Release notes structure:
## vX.Y.Z (YYYY-MM-DD)
### [Section Header — describes the theme]
[Narrative paragraph explaining the headline change. What it is, why it matters, how it works at a high level.]
### [Additional sections as needed]
[Group related changes under descriptive headers. Not every change needs its own section — group small changes together.]
### Full Changelog
- type: description of change
- type: description of change
Rules:
feat:, fix:, refactor:, docs:, chore:)Update the version string in every manifest file that exists:
| File | Fields to update |
|---|---|
| .claude-plugin/plugin.json | .version |
| .claude-plugin/marketplace.json | .metadata.version AND .plugins[].version |
| .cursor-plugin/plugin.json | .version (if exists) |
| .codex/plugin.json | .version (if exists) |
| package.json | .version |
| Cargo.toml / pyproject.toml | version field |
Also check for README badges or version references.
Stage all release-related changes and create a single release commit:
git add -A
git commit -m "release: vX.Y.Z — [one-line summary of headline change]"
NoCo-Authored-By trailer. No AI attribution.
Create an annotated tag:
git tag -a vX.Y.Z -m "vX.Y.Z"
Ask the user before pushing:
Ready to push the release commit and tag to origin. Proceed?
If confirmed:
git push && git push --tags
Use these in the Full Changelog section:
| Prefix | Meaning |
|---|---|
feat: | New feature or capability |
fix: | Bug fix |
refactor: | Code restructuring without behavior change |
docs: | Documentation only |
chore: | Build, CI, dependencies, tooling |
perf: | Performance improvement |
| Mistake | Fix |
|---|---|
| Releasing without running tests | Always run tests in Step 1 |
| "Bump version" as the commit message | Use release: vX.Y.Z — [summary] |
| Adding AI co-authorship | The user is the author. Period. |
| Dumping raw git log as release notes | Write narrative release notes that a human would want to read |
| Skipping the tag | Tags are how users and tools identify releases |
| Force-pushing a release | Never. If something is wrong, cut a new patch release. |
| Releasing from a feature branch | Releases come from main unless the user explicitly confirms otherwise |
Weekly Installs
1
Repository
GitHub Stars
4
First Seen
1 day ago
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
agent-browser 浏览器自动化工具 - Vercel Labs 命令行网页操作与测试
147,400 周安装
test:| Test additions or fixes |
style: | Formatting, whitespace (no logic change) |