为 R 包创建发布检查清单并自动开 GitHub issue

当需要为 R 包发起一次新版本发布、生成发布检查清单并创建对应 GitHub issue 时使用。

适用场景

解决思路

1. 校验前置条件（按效率顺序）：1) 检查当前工作目录根下是否存在 `DESCRIPTION` 文件，若不存在则告知用户必须在 R 包根目录运行并停止；2) 用 `Rscript -e 'utils::packageVersion("usethis")'` 检查 `usethis` 包是否安装，若未安装则提示用户运行 `install.packages("usethis")` 并停止；3) 确定仓库的 GitHub URL：先试 `gh repo view --json url`，失败时诊断错误——若 `gh` 未安装则运行 `git remote -v` 查找 GitHub URL；若本地仓库没有 GitHub remote，建议用户用 `usethis::use_github()` 连接并询问是否代为执行，若用户拒绝则继续但不带 GitHub URL；若 `gh` 已安装但未认证且仓库有 GitHub remote，建议用户运行 `gh auth login`。任一检查失败都要说明具体问题并给出修复指引后停止，未满足全部前置条件不得进入下一步。
2. 读取 `DESCRIPTION` 文件，提取 `Version:` 和 `Package:` 字段，确定当前包名和版本。
3. 检查是否存在 `NEWS.md`：若存在，读取第一段（通常是最新的未发布变更）以判断变更类型，并据此建议发布类型——提到 "breaking changes"、"breaking"、"BREAKING" 等则建议 **Major**；只提到 "bug fixes"、"fixes"、"patch" 等且无新功能则建议 **Patch**；其他情况（新功能、改进、增强）建议 **Minor**。
4. 向用户展示当前版本，并用 AskUserQuestion 工具询问发布类型，问题为 "What type of release is this?"，Header 为 "Release type"，选项顺序为：Major (X.0.0) - Breaking changes、Minor (x.X.0) - New features but without breaking changes、Patch (x.x.X) - Bug fixes only，将建议的选项放在第一位并在标签后追加 "(Recommended)"。
5. 根据用户选择计算新版本号（例如 `1.2.3` + Major → `2.0.0`；`1.2.3` + Minor → `1.3.0`；`1.2.3` + Patch → `1.2.4`；`0.2.1.9000` + Patch → `0.2.2`；`0.2.1.9003` + Minor → `0.3.0`）。注意：若当前版本以 `.9xxx` 结尾（R 风格开发版本），先去掉该后缀再计算。
6. 显示 "Preparing release checklist for ${PACKAGE_NAME} ${CURRENT_VERSION} → ${NEW_VERSION}"。
7. 用技能自带的 `scripts/generate_checklist.R` 脚本生成初始检查清单：已知 GitHub URL 时运行 `Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}" "${GITHUB_URL}"`，否则运行 `Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}"`（`${SKILL_DIR}` 为技能安装目录）。忽略输出中的 "Setting active project..." 行。
8. 读取生成的 Markdown 检查清单并展示给用户。
9. 用 AskUserQuestion 工具询问 "Would you like to customize the checklist before creating the issue?"，Header 为 "Customize?"，选项为 "No, create the issue as-is" 和 "Yes, let me customize it"。
10. 若用户选择自定义，进入迭代细化循环：1) 询问 "Suggest items that should be added or any items that can be safely removed, or confirm that there are no more changes requested."；2) 根据反馈更新清单（增删条目、改写措辞等），保持 Markdown 格式并使用正确的复选框语法（任务用 `- [ ]`）；3) 向用户展示更新后的清单；4) 询问 "Does this look good or do you have more suggestions?"；5) 若用户还有建议则回到第 2 步，若确认无误则退出循环进入下一步。整个过程中清单应保持为 Markdown 字符串，便于传给 GitHub issue 创建命令。
11. 最终清单应格式化为带正确分节和复选框的 Markdown。
12. 若 `gh` 可用且已认证，直接通过 stdin 传入清单内容创建 GitHub issue：`gh issue create --title "Release ${PACKAGE_NAME} ${NEW_VERSION}" --body-file - <<'EOF'` 后接清单内容再接 `EOF`。
13. 创建成功后向用户展示：带 issue URL 的成功消息，以及建议 "You can now use the 'do-release-checklist' skill to walk through the checklist tasks."（这是引导用户逐项执行清单的配套技能；若仓库中尚无此技能可省略该建议）。
14. 若 `gh` 不可用，则向用户展示清单并指导手动创建 GitHub issue：给出建议标题 "Release ${PACKAGE_NAME} ${NEW_VERSION}"、完整的 Markdown 清单内容，并指示用户复制内容到其仓库的 issues 页面手动创建。
15. 若用 `gh` 创建 issue 失败，排查常见问题：**认证错误**——确认 `gh auth status` 显示已登录，必要时建议运行 `gh auth login`；**仓库权限**——用户必须有写权限才能创建 issue，用 `gh repo view` 核实权限；**网络错误**——若有连接问题，建议重试命令或检查网络；**无效 Markdown**——若 issue 正文有格式错误，检查清单 Markdown 语法是否正确。
16. 若 issue 创建失败，保留清单内容并提供：重试命令，或改为展示清单供手动创建 issue。

适用边界 · 注意事项

• 工作目录不是 R 包根目录（根下没有 `DESCRIPTION` 文件）时。
• 未安装 `usethis` R 包时。
• 需要自动创建 GitHub issue 但 `gh` CLI 未安装/未认证，或该 R 包未关联 GitHub 仓库时（此时只能手动创建）。