release:prep 依赖缺失的 pypi-release-process.md 导致流程阻塞

[codeasier]

问题描述

在 pt-snap-cli 仓库执行 /release:prep 0.1.0 时，流程在阶段 1 要求读取：

• .claude/pypi-release-process.md
• .github/workflows/publish.yml
• CHANGELOG.md

但目标仓库实际情况是：

• .claude/pypi-release-process.md 不存在
• .github/workflows/publish.yml 不存在，实际存在的是 .github/workflows/release.yml
• CHANGELOG.md 不存在

因此 release:prep 在准备 changelog 前被迫停下，需要用户决定如何适配。

复现方式

在一个没有 .claude/pypi-release-process.md，且 release workflow 文件名为 .github/workflows/release.yml 的 Python 仓库中执行：

/release:prep 0.1.0

实际结果

命令要求读取固定路径 .claude/pypi-release-process.md 和 .github/workflows/publish.yml，文件缺失时无法继续按技能流程完成 release prep。

期望结果

建议 release:prep 对这些文件依赖做更稳健的处理，例如：

1. 将 .claude/pypi-release-process.md 视为可选文件：存在则读取并遵守，不存在则使用内置默认发布流程并提示。
2. workflow 文件不要硬编码为 .github/workflows/publish.yml，可自动发现包含 tag 发布/PyPI 发布逻辑的 workflow，例如 release.yml。
3. 如果 CHANGELOG.md 不存在，支持进入“新建 changelog”的路径，而不是只能依赖既有风格。
4. 在缺失关键文件时输出明确的可操作建议，区分“必须停止”的错误和“可以适配继续”的情况。

影响

当前实现会让 release prep 对仓库模板结构有较强假设。对于已经使用 tag-triggered release workflow、但文件名或流程文档不同的仓库，用户需要人工判断并中断流程。

环境备注

触发场景来自 codeasier/pt-snap-cli 仓库，实际 workflow 文件为 .github/workflows/release.yml，其中 release 由 v* tag 触发，并校验 tag 版本与 pyproject.toml 版本一致。

[codeasier]

已核对当前仓库中的 /release:prep 技能实现，这个问题真实存在，且 issue 中的改进方向总体合理。

依据：

• /release:prep 的实现位于 plugins/release/skills/prep/SKILL.md。
• 该技能在阶段 1 明确要求读取并遵守：
  • .claude/pypi-release-process.md
  • .github/workflows/publish.yml
  • 当前 CHANGELOG.md 的既有风格
• 同一文件还多处把 CHANGELOG.md 和 .github/workflows/publish.yml 作为后续 release 校验依据，例如要求只提交 CHANGELOG.md，以及在打 tag 前复用 .github/workflows/publish.yml 的规则校验 CHANGELOG.md 中的 ## [{version}] 条目。

因此，如果目标仓库缺少这些文件，当前技能文本确实会把流程带到无法按说明继续执行的状态；这不是单纯的使用误解。

对 issue 中建议的判断：

1. 将 .claude/pypi-release-process.md 视为可选文件：合理。
   该文件更像仓库级发布补充约定。存在时应优先读取并遵守；不存在时，技能应能退回内置默认流程，并明确提示“未发现仓库级发布说明，使用默认流程”。

2. workflow 文件不应固定为 .github/workflows/publish.yml：合理。
   当前技能把文件名写死，但实际仓库可能使用 release.yml、publish.yml、pypi.yml 等不同命名。更合理的边界是：优先自动发现 .github/workflows/*.yml / *.yaml 中与 tag 发布、PyPI 发布、GitHub Release 或 release notes 提取相关的 workflow；如果发现多个候选，再让用户确认；如果没有发现，则把 workflow 校验降级为不可执行并说明影响。

3. CHANGELOG.md 不存在时支持新建路径：部分合理，需要边界。
   如果技能目标仍是“准备 changelog + PR”，那么 CHANGELOG.md 不存在时可以进入“创建首个 changelog”的路径，而不是直接阻塞。
   但如果目标仓库的发布流程本身并不依赖 changelog，例如由 workflow 从 git log / PR 自动生成 release notes，则技能应先识别这一点，并询问用户是否仍希望新增 CHANGELOG.md，而不是默认强制创建。

4. 区分必须停止与可适配继续：合理。
   版本号不合法、远程不可达、tag 已存在、工作区存在冲突性改动等属于应停止或要求用户决策的情况；而缺少仓库级流程文档、workflow 文件名不同、没有既有 changelog 风格等情况，更适合给出适配路径后继续。

建议修复方向：

• 在 plugins/release/skills/prep/SKILL.md 中把固定路径读取改成“发现 / 可选 / 降级”的流程。
• 对 .claude/pypi-release-process.md：存在则读取，不存在则提示并使用默认流程。
• 对 workflow：扫描 .github/workflows/ 下的 YAML 文件，识别 tag 触发、PyPI 发布、GitHub Release、release notes 提取等逻辑；避免只认 publish.yml。
• 对 CHANGELOG.md：存在则保持风格；不存在则根据仓库 workflow 判断是创建首个 changelog、跳过 changelog，还是先询问用户。

结论：issue 描述的问题成立，建议方向合理；但 CHANGELOG.md 的处理不应一律“缺失就创建”，正确边界应取决于目标仓库实际发布流程是否依赖 changelog。