create-dwy 0.14.0 → 0.14.2

package/CHANGELOG.md

@@ -1,5 +1,19 @@
 # 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
+
+- 修正 `templates/ai-tools/skills` 内多处写死的绝对 skill 路径，统一改为 skill 内相对路径，例如 `./scripts/`、`./references/`、`./preference.json`，避免项目级/插件级安装时路径失效。
+
 ## 0.14.0
 
 ### Minor Changes

package/package.json

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

package/templates/ai-tools/skills//345/205/203/345/267/245/345/205/267/dwy-shared/SKILL.md

@@ -196,7 +196,7 @@ git -C "$REPO_PATH" push origin master
 
 告知用户：
 - ✓ 已 push 到 Gitee
-- 更新 `/Users/chances/WebstormProjects/dwy-shared/claude-cli/templates/ai-tools/` 后，发布新的 `create-dwy` 版本；其他项目升级 CLI 后即可使用新模板
+- 更新当前仓库的 `templates/ai-tools/` 后，发布新的 `create-dwy` 版本；其他项目升级 CLI 后即可使用新模板
 - 提醒：如果对方 dwy CLI <0.12.0，必须先升级 CLI 才能识别分类目录结构
 
 ## 工作流程 B：dwy CLI 管理

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-pentest/SKILL.md

@@ -7,7 +7,7 @@ description: "白帽渗透测试：对指定服务器执行全面安全评估。
 
 对指定目标执行全面安全评估，发现漏洞后报警提示，不执行破坏性操作。
 
-**脚本目录：** `~/.claude/skills/dwy-pentest/scripts/`（以下简称 `{scripts}`）
+**脚本目录：** `./scripts/`（以下简称 `{scripts}`）
 
 ## 流程总览
 

package/templates/ai-tools/skills//346/225/260/346/215/256/345/272/223/dwy-dolphindb/SKILL.md

@@ -137,7 +137,7 @@ s.run("cancelConsoleJob(`xxxx)")                // 同步作业
 文档来自爬取，需要周期刷新。所有命令在 skill 目录下跑：
 
 ```bash
-cd ~/.claude/skills/数据库/dwy-dolphindb     # 或源仓库对应路径
+cd .     # skill 根目录
 
 # 检查文档新鲜度（默认 90 天阈值）
 uv run scripts/check_freshness.py

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

@@ -17,7 +17,7 @@ description: "部署后线上环境基础安全巡检：远程 SSH 到目标服
 | 副作用 | 可能触发 IDS、产生大量请求 | 仅 SSH 登录读取配置，零侵入 |
 | 输出 | 漏洞清单 + 复现步骤 | 配置不合规清单 + 修复建议 |
 
-**脚本目录：** `~/.claude/skills/dwy-deploy-audit/scripts/`（以下简称 `{scripts}`）
+**脚本目录：** `./scripts/`（以下简称 `{scripts}`）
 
 **详细检查规则索引：**
 

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-deploy-audit/references/checks-data.md

@@ -4,7 +4,7 @@
 
 本文件聚焦"数据与凭证安全"维度的检查规则、严重度判定与输出格式。涵盖数据库暴露、环境变量与文件权限、凭证强度审计。
 
-脚本目录简称 `{scripts}` = `~/.claude/skills/dwy-deploy-audit/scripts/`。
+脚本目录简称 `{scripts}` = `../scripts/`。
 
 ---
 

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-deploy-audit/references/checks-network.md

@@ -4,7 +4,7 @@
 
 本文件聚焦"网络与传输安全"维度的检查规则、严重度判定与输出格式。涵盖 SSH、Nginx、HTTPS 证书、依赖服务连通性。
 
-脚本目录简称 `{scripts}` = `~/.claude/skills/dwy-deploy-audit/scripts/`。
+脚本目录简称 `{scripts}` = `../scripts/`。
 
 ---
 

package/templates/ai-tools/skills//350/277/220/347/273/264/345/217/221/345/270/203/dwy-deploy-audit/references/checks-runtime.md

@@ -4,7 +4,7 @@
 
 本文件聚焦"运行时与韧性"维度的检查规则、严重度判定与输出格式。涵盖 Docker 安全、自愈与资源耗尽防护、日志大小与防爆、硬件识别与资源推荐。
 
-脚本目录简称 `{scripts}` = `~/.claude/skills/dwy-deploy-audit/scripts/`。
+脚本目录简称 `{scripts}` = `../scripts/`。
 
 ---
 

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

@@ -7,9 +7,9 @@ description: "Docker 工程规范检查与镜像版本管理。触发场景：
 
 涵盖镜像版本选择 + Dockerfile / docker-compose / k8s manifest 工程结构。
 
-**脚本目录：** `~/.claude/skills/dwy-docker/scripts/`（以下简称 `{scripts}`）
+**脚本目录：** `./scripts/`（以下简称 `{scripts}`）
 
-**参考文件：** `~/.claude/skills/dwy-docker/references/`
+**参考文件：** `./references/`
 - `templates.md` — compose / Dockerfile / dev.sh 模板（用户问"怎么写"时读）
 - `version-rules.md` — N-1 minor 选法 + 各类镜像表（选具体版本号时读）
 - `ask-templates.md` — AskUserQuestion 模板（违规需要询问用户时读）

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

@@ -7,7 +7,7 @@ description: "国内镜像源加速配置检查与修复：扫描 pip/uv/poetry/
 
 国内开发环境下，pip/npm/Docker 等工具默认境外源会让安装/拉取拖慢数倍甚至失败。本 skill 统一检查所有支持工具的镜像源配置，识别问题并辅助切换到国内加速源。
 
-**脚本目录：** `~/.claude/skills/dwy-mirror-source/scripts/`（以下简称 `{scripts}`）
+**脚本目录：** `./scripts/`（以下简称 `{scripts}`）
 
 ---
 
@@ -25,7 +25,7 @@ description: "国内镜像源加速配置检查与修复：扫描 pip/uv/poetry/
 
 **阿里云**（覆盖最全，BGP 多线，全国质量稳定）。
 
-可通过 `~/.claude/skills/dwy-mirror-source/preference.json` 修改：
+可通过 `./preference.json` 修改：
 
 ```json
 {

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`
+- 禁止把包仓库验证替换成环境健康检查