create-dwy 0.14.1 → 0.14.2

package/CHANGELOG.md

@@ -1,5 +1,13 @@
 # create-dwy
 
+## 0.14.2
+
+### Patch Changes
+
+- 重构 `templates/ai-tools/skills/运维发布/dwy-publish`：主入口只负责识别“应用部署”或“SDK 发版”，再按类型读取独立流程文件。
+- 新增 `references/application-release.md` 与 `references/sdk-release.md`，将应用部署和 SDK 发版流程拆开，避免单文件内混合两套末端流程。
+- `dwy-publish` 主入口改为使用相对路径读取流程文件，避免模板内写死仓库绝对路径。
+
 ## 0.14.1
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-dwy",
-  "version": "0.14.1",
+  "version": "0.14.2",
   "description": "项目脚手架与多平台 AI 配置同步工具",
   "type": "module",
   "bin": {

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-publish/SKILL.md

@@ -1,145 +1,50 @@
 ---
 name: dwy-publish
-description: "发布版本：测试 → bump → changelog → build → publish → tag。触发条件：用户说'发版'、'发布'、'release'、'bump version' 时。"
+description: "部署应用、发布版本、发布 SDK 的通用发版入口。触发条件：用户说“部署”“发版”“发布”“release”“publish”“bump version”时。先根据仓库上下文判断目标是应用部署还是 SDK 发版，再分别读取对应流程文件执行。"
 ---
 
-# 发布版本流程
+# 发布入口
 
-通用的发版流程框架，项目特定的包名、路径、命令由 CLAUDE.md 的 `## Release` 段落定义。
+通用发布 skill。默认进入本 skill 前，测试已经完成。
 
-## 触发条件
+## 第 0 步：读取仓库发布上下文
 
-用户要求发布包时（"发版"、"发布"、"release"、"bump version"）。
+执行前先从仓库里定位发布相关信息。
 
-## 第 0 步：检查项目 Release 配置
+优先查看这些信息源：
 
-**在执行任何操作前**，检查当前项目的 CLAUDE.md 是否包含 `## Release` 段落：
+- `package.json`、`pyproject.toml`、`Cargo.toml`、`Makefile`、发布脚本
+- `.github/workflows/`、CI 配置、Docker 构建文件
+- `README.md`、发布文档、变更日志
+- 现有 tag 格式、历史 release commit、历史 workflow 运行方式
 
-- **有** → 读取其中的包列表、版本文件路径、测试命令、构建命令、发布命令、依赖顺序等配置，按配置执行
-- **没有** → **停止发版流程**，提醒用户：
+如果仍然无法判断发布方式或版本来源，停止并要求用户明确，不猜命令。
 
-> 「当前项目 CLAUDE.md 未定义 `## Release` 段落，无法执行发版流程。需要我帮你加吗？」
+## 第 1 步：先判断发布类型
 
-参考格式（提供给用户）：
+先确认：
 
-```markdown
-## Release
+1. 发布哪个应用或包
+2. 目标是应用部署还是 SDK 发版
+3. 目标版本号是什么；如果用户没给，判断是 `major` / `minor` / `patch`
 
-### 包列表
+归类规则：
 
-| 包名 | scope | 版本文件 | 测试命令 | 构建命令 | 发布命令 | 验证命令 |
-|------|-------|---------|---------|---------|---------|---------|
-| @scope/pkg-a | pkg-a | packages/a/package.json | cd packages/a && pnpm vitest run | pnpm build:a | pnpm publish:a | npm view @scope/pkg-a version |
+- **应用部署**：目标是某个服务、站点、容器、镜像、二进制或线上环境
+- **SDK 发版**：目标是 npm、PyPI、私有包仓库或对外库版本
 
-### 依赖顺序
+多包场景按仓库已有依赖关系、workspace 拓扑、历史发布顺序执行，不自定顺序。
 
-多包发版时按此顺序执行：pkg-a → pkg-b → pkg-c
+## 第 2 步：读取对应流程文件
 
-### Tag 命名
+- **应用部署**：读取 `references/application-release.md`
+- **SDK 发版**：读取 `references/sdk-release.md`
 
-- 单包：`@scope/pkg-a@1.0.0`
-- 仅一个包时可简化为：`v1.0.0`
+不要把两条流程混在一起执行。先判类型，再只读对应流程文件。
 
-### CHANGELOG
+## 通用约束
 
-- 命令：`pnpm changelog`（可选，无则手写）
-- 工具：changelogen
-```
-
-## 发版前置检查（按项目类型）
-
-正式发版前，先按项目类型过对应的前置 skill：
-
-- **SDK 类项目（对外发布的库 / SDK，不限 PyPI / npm / 私有源）** → 先用 `dwy-sdk-spec` 做发布安全检查（接口注释脱敏、商业版源码保护、发布产物审计），通过后再发版。
-- **含 C 扩展 / Cython / .so、需跨平台 wheel** → 用 `dwy-cibuildwheel` 配 GitHub Actions + cibuildwheel 打跨平台 wheel 发 PyPI（此时下方第 4、6 步的 build / publish 由 CI workflow 承担）。
-- **版本号该升哪一位拿不准** → 用 `dwy-semver` 决策（见下方第 2 步）。
-
-## 发版前确认
-
-询问用户：
-
-1. **发哪个包？**（从 Release 配置的包列表中选，可多选）
-2. **版本号？** patch / minor / major，或指定具体版本号
-
-## 发版流程
-
-### 1. 运行测试
-
-执行 Release 配置中对应包的测试命令。**测试必须全部通过才能继续。**
-
-**有失败 → 停止发版，修复后重新开始。**
-
-### 2. Bump Version
-
-**版本级别（major/minor/patch）该怎么定** —— 不确定时用 `dwy-semver` skill 决策，它给出该升哪一位 + 具体新版本号（含 0.x 阶段、预发布、归零规则）。
-
-根据 Release 配置中的版本文件路径，直接编辑 version 字段。新版本号用 `dwy-semver` 的 `scripts/bump.py` 算，避免手算归零出错：
-
-```bash
-python3 <dwy-semver>/scripts/bump.py <当前版本> <major|minor|patch>
-# 如 1.2.3 minor -> 1.3.0
-```
-
-不使用 `npm version`（避免自动 commit）。Python 项目编辑 `pyproject.toml` 中的 `version` 字段。
-
-### 3. 编写 CHANGELOG
-
-**如果项目有 changelog 自动生成工具**（如 changelogen），执行配置的命令。
-
-**如果没有**，手动编写 CHANGELOG 条目：
-
-1. 查看上个版本 tag 以来的 git log：`git log <last-tag>..HEAD --oneline`
-2. 按变更类型分组（feat / fix / refactor / chore）
-3. 写入项目的 CHANGELOG.md，格式：
-
-```markdown
-## x.y.z
-
-### Minor Changes / Patch Changes
-
-- 变更描述 1
-- 变更描述 2
-```
-
-**CHANGELOG 未写不发版。**
-
-### 4. Build
-
-执行 Release 配置中对应包的构建命令。**构建必须成功才能继续。**
-
-### 5. Commit + Tag
-
-```bash
-# 暂存变更（version + changelog）
-git add <changed-files>
-
-# 提交（遵循 dwy-git-commit）
-git commit -m "chore(<scope>): release v<version>"
-
-# 打 tag（按 Release 配置的命名规则）
-git tag <tag-name>
-
-# 推送
-git push origin <branch> --tags
-```
-
-### 6. Publish
-
-执行 Release 配置中对应包的发布命令。
-
-### 7. 发版后验证
-
-执行 Release 配置中对应包的验证命令，确认新版本已发布。
-
-## 多包同时发版
-
-按 Release 配置中定义的依赖顺序，每个包独立走完 测试 → bump → changelog → build → publish，最后统一 commit + tag + push。
-
-## 禁止事项
-
-- **禁止**跳过测试直接发版
-- **禁止**跳过 build 直接 publish
-- **禁止**忘记打 tag
-- **禁止**publish 失败后不回滚 version 变更
-- **禁止**在 CHANGELOG 未编写时发版
-- **禁止**在无 Release 配置的情况下猜测发版命令
+- 禁止在未读清仓库发布上下文时猜发布命令
+- 禁止测试未完成就进入本发布流程
+- 禁止构建失败后继续发布
+- 禁止发布失败后对当前状态含糊表述

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-publish/references/application-release.md

@@ -0,0 +1,106 @@
+# 应用部署流程
+
+适用：发布目标是某个服务、站点、容器、镜像、二进制或线上环境。
+
+## 主流程
+
+流程骨架：
+
+1. `bump`
+2. `CHANGELOG`
+3. `build`
+4. `deploy`
+5. `verify env`
+
+## 1. 判断是否需要 bump
+
+不要一上来改版本号。先判断这次部署是否需要 bump：
+
+- **需要 bump**：带显式版本号的应用发布、镜像 tag 升级、二进制版本升级、对外可见版本变化
+- **可不 bump**：纯重发、仅重跑 workflow、仅补环境配置、仅回滚到已有构建
+- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
+
+如果需要 bump：
+
+1. 读取当前版本
+2. 算出新版本号
+3. 修改版本文件、镜像 tag 或其他版本来源
+
+不要用会自动 commit 的版本命令。直接编辑版本来源，保持提交边界可控。
+
+## 2. 写 CHANGELOG
+
+判断完 bump 后，再处理 `CHANGELOG`。
+
+- **需要正式版本发布**：必须写
+- **仅部署且无版本变化**：按项目约定决定是否跳过
+
+处理顺序：
+
+1. 找上一个 release tag
+2. 查看 `git log <last-tag>..HEAD --oneline`
+3. 按 `feat` / `fix` / `refactor` / `chore` 分组
+4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
+
+如果仓库已有自动生成命令，优先使用；没有再手写。
+
+`CHANGELOG` 未完成，不继续。
+
+## 3. 确认测试已完成并执行 build
+
+本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
+
+然后执行 build，确保发布产物可生成。
+
+构建失败则停止。
+
+## 4. 决定 deploy 入口
+
+不要把 deploy 写死成某种命令。根据仓库上下文自行判断：
+
+- 是推镜像、发二进制、跑部署脚本，还是触发 CI/CD
+- 是 GitHub Actions、其他 CI，还是本地脚本
+- 是否需要先 commit、tag、push 才能触发部署
+
+判断标准示例：
+
+- 存在明确 workflow、触发方式、部署 job，且部署由 CI 完成 → 走 CI
+- 仓库里有明确部署脚本、命令或运维入口 → 走本地部署流程
+
+## 5. 执行 deploy
+
+如果是 CI 驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
+3. 推送分支和 tag
+4. 观察部署运行状态直到成功或失败
+
+如果是本地驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag
+3. 推送分支和 tag
+4. 执行本地部署命令
+
+失败则停止，并给出失败阶段和关键报错。
+
+## 6. verify env
+
+部署完成后，按仓库约定验证环境已生效。可用信号包括：
+
+- 健康检查
+- 版本接口
+- 页面访问
+- 运行日志
+- 镜像 tag
+- 发布平台状态
+- 其他项目约定信号
+
+验证失败，部署不算完成。
+
+## 禁止事项
+
+- 禁止跳过“是否需要 bump”的判断
+- 禁止先部署后补 `CHANGELOG`
+- 禁止把环境验证替换成包仓库验证

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-publish/references/sdk-release.md

@@ -0,0 +1,93 @@
+# SDK 发版流程
+
+适用：发布目标是 npm、PyPI、私有包仓库或对外库版本。
+
+## 主流程
+
+流程骨架：
+
+1. `bump`
+2. `CHANGELOG`
+3. `build`
+4. `publish package`
+5. `verify registry`
+
+## 1. 判断是否需要 bump
+
+SDK 发版默认需要判断版本升级。
+
+- **需要 bump**：正式发布新版本、预发布版本、修复发布产物并重发
+- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
+
+执行顺序：
+
+1. 读取当前版本
+2. 算出新版本号
+3. 修改版本文件
+
+不要用会自动 commit 的版本命令。直接编辑版本文件。
+
+## 2. 写 CHANGELOG
+
+SDK 发版必须写 `CHANGELOG`。
+
+处理顺序：
+
+1. 找上一个 release tag
+2. 查看 `git log <last-tag>..HEAD --oneline`
+3. 按 `feat` / `fix` / `refactor` / `chore` 分组
+4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
+
+如果仓库已有自动生成命令，优先使用；没有再手写。
+
+`CHANGELOG` 未完成，不继续。
+
+## 3. 确认测试已完成并执行 build
+
+本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
+
+然后执行 build，确保包产物可生成。
+
+构建失败则停止。
+
+## 4. 决定 publish 入口
+
+根据仓库上下文判断：
+
+- **CI 发布**：workflow、release job、tag push、workflow_dispatch、release please、cibuildwheel
+- **本地发布**：`pnpm publish`、`uv publish`、`twine upload` 或其他本地发包命令
+
+## 5. 执行 publish package
+
+如果是 CI 驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
+3. 推送分支和 tag
+4. 观察发布运行状态直到成功或失败
+
+如果是本地驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag
+3. 推送分支和 tag
+4. 执行本地发包命令
+
+失败则停止，并给出失败阶段和关键报错。
+
+## 6. verify registry
+
+发布完成后，确认目标仓库中的新版本已可见。验证方式包括：
+
+- npm：`npm view <pkg> version`
+- PyPI：`pip index versions <pkg>` 或项目定义的检查命令
+- 私有仓库：项目约定的版本查询方式
+- GitHub Release：确认 release/tag 已生成
+
+验证失败，发版不算完成。
+
+## 禁止事项
+
+- 禁止跳过版本升级判断
+- 禁止先发包后补 `CHANGELOG`
+- 禁止把包仓库验证替换成环境健康检查