‹ 首页

dev-release

@evolution-foundation · 收录于 5 天前 · 上游提交 2 个月前

Release preparation — changelog generation, version bump, tag creation. Generic version (not project-specific). For EvoNexus releases, use custom-release instead.

适合你,如果每次发版前都要手动整理变更和打标签

/ 通过 npx 安装 校验哈希
npx oh-my-skill add evolution-foundation/evo-nexus/dev-release
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- evolution-foundation/evo-nexus/dev-release
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify evolution-foundation/evo-nexus/dev-release
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
509GitHub stars
~511上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 7f5dd76 · 表述以原文为准
它做什么

装好后,你让 Claude 发布项目新版本,它就会自动生成变更日志、更新版本号、创建 Git 标签,并保存发布说明。

什么时候触发

当你要求准备发布一个非 EvoNexus 的项目(如通用库),且当前分支干净、代码通过测试时触发。

装好后可以这样说
自动检测当前版本并询问升级类型
指定版本号,直接开始对应流程
指定 patch 类型,简化确认
技能原文 SKILL.md作者撰写 · Apache-2.0 · 7f5dd76

Dev Release

Derived from oh-my-claudecode (MIT, Yeachan Heo). Adapted for the EvoNexus Engineering Layer.

Generic release preparation: changelog generation from git log, version bump, tag creation. For EvoNexus-specific releases, use custom-release (the existing skill that handles git-flow develop→main).

Use When
  • Releasing a non-EvoNexus project (Evolution API, Evo AI, Evo Go, etc.)
  • Generic semver bump on a library you're maintaining
Do Not Use When
  • Releasing EvoNexus itself → use custom-release instead
  • Project has its own custom release process → follow that
Workflow
Phase 1 — Pre-flight
  • Verify on the right branch (not main/master directly)
  • Verify clean working tree (no uncommitted changes)
  • Verify CI is green on the target commit
  • Verify tests pass locally (dev-verify)
Phase 2 — Determine version
  • Read current version from manifest (package.json, Cargo.toml, go.mod, pyproject.toml)
  • Determine bump type: major / minor / patch (semver)
  • Confirm with user
Phase 3 — Generate changelog
  • Read commits since last tag: git log {last-tag}..HEAD --oneline
  • Group by type (feat / fix / docs / etc.) if conventional commits
  • Save to CHANGELOG.md with new version section
Phase 4 — Bump version
  • Update manifest file
  • Update any version references in docs
Phase 5 — Commit and tag
  • git commit -m "chore(release): vX.Y.Z"
  • git tag vX.Y.Z
  • git push origin vX.Y.Z (after user confirmation)
Phase 6 — Verify
  • @oath-verifier confirms the release commit and tag are correct
Output

Save release notes to workspace/development/research/[C]release-{version}-{date}.md.

Pairs With
  • @flow-git (commits and tags)
  • @oath-verifier (verification)
  • @quill-writer (changelog formatting)
  • dev-verify (pre-flight)
EvoNexus-Specific Note

EvoNexus has its own release skill (custom-release) that handles the git-flow develop→main workflow with EvoNexus-specific gates (CHANGELOG entry, version sync across files, GitHub release creation). Use custom-release for EvoNexus releases. Use dev-release only for projects in workspace/projects/ that have their own release lifecycle.

按 Apache-2.0 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。