R包发布清单生成工具 - 自动化创建GitHub Issue，提升R包发布效率

create-release-checklist by posit-dev/skills

91 周安装量

205 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/posit-dev/skills --skill create-release-checklist

自动化 R语言版本控制

🇨🇳中文介绍

创建 R 包发布清单

为 R 包生成发布清单并创建相应的 GitHub issue。

概述

此技能通过以下步骤指导您在 GitHub 上创建 R 包发布清单 issue：

确定当前版本并提示发布类型。
生成初始清单。
提示用户进行额外自定义。
根据最终清单创建 GitHub issue。

前提条件

工作目录必须是一个在根目录包含 DESCRIPTION 文件的 R 包。
必须安装 usethis R 包。

要启用自动 issue 创建，还需满足：

必须安装并认证 gh CLI。
R 包必须关联到一个 GitHub 仓库。

工作流程

步骤 1：验证

首先，检查前提条件是否满足（为提高效率，按此顺序检查）：

检查工作目录是否包含名为 DESCRIPTION 的文件。如果没有，通知用户必须从 R 包根目录运行此命令，然后停止。
使用 Rscript -e 'utils::packageVersion("usethis")' 检查是否安装了包。如果没有，指导用户使用安装，然后停止。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 2：初始化

接下来，需要确定当前包的名称和版本。读取 DESCRIPTION 文件并从中提取 Version: 和 Package: 字段。

然后，检查是否存在 NEWS.md 文件。如果存在，读取第一部分（通常是最近未发布的更改）以了解进行了哪些类型的更改。使用此信息来建议合适的发布类型：

如果 NEWS 中提到 "breaking changes"、"breaking"、"BREAKING" 或类似语言，建议进行主要发布。
如果 NEWS 中仅提到 "bug fixes"、"fixes"、"patch" 或类似语言，且没有新功能，建议进行补丁发布。
其他情况（新功能、改进、增强），建议进行次要发布。

向用户显示当前版本，并使用 AskUserQuestion 工具询问他们这应该是什么类型的发布。将建议的发布类型设为第一个选项，并在标签后附加"（推荐）"：

问题："这是什么类型的发布？" 标题："发布类型" 选项（推荐选项在前）：

主要 (X.0.0) - 破坏性更改（如果建议，添加"（推荐）"）
次要 (x.X.0) - 新功能但不包含破坏性更改（如果建议，添加"（推荐）"）
补丁 (x.x.X) - 仅错误修复（如果建议，添加"（推荐）"）

根据用户的回答，通过操作当前版本来计算新版本。例如：

当前版本 1.2.3 + 主要发布 → 2.0.0
当前版本 1.2.3 + 次要发布 → 1.3.0
当前版本 1.2.3 + 补丁发布 → 1.2.4
当前版本 0.2.1.9000 + 补丁发布 → 0.2.2
当前版本 0.2.1.9003 + 次要发布 → 0.3.0

注意：如果当前版本以 .9xxx 结尾（R 风格的开发版本），在计算新版本之前去掉此后缀。

显示："正在为 ${PACKAGE_NAME} ${CURRENT_VERSION} → ${NEW_VERSION} 准备发布清单"。

步骤 3：清单生成

使用此技能附带的 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..." 行。

读取生成的清单（Markdown 格式）并显示给用户。

步骤 4：用户自定义

使用 AskUserQuestion 工具询问：

问题："在创建 issue 之前，您想自定义清单吗？" 标题："自定义？" 选项：

否，按原样创建 issue
是，让我自定义

如果用户想要自定义清单，则进入迭代优化循环：

询问："建议应添加的项目或可以安全删除的项目，或者确认没有更多更改请求。"
根据用户的反馈，更新清单（添加项目、删除项目、重写项目等）。保持清单为 Markdown 格式，并使用正确的复选框语法（任务使用 - [ ]）。
向用户显示更新后的清单。
询问："这看起来可以吗，还是有更多建议？"
如果用户有更多建议，则返回步骤 2。如果用户确认看起来可以，则退出循环并继续步骤 5。

在整个过程中，清单应保持为 Markdown 字符串，以便轻松传递给 GitHub issue 创建命令。

步骤 5：GitHub Issue 创建

最终清单应格式化为具有适当章节和复选框的 Markdown。

如果 gh 可用且已认证，使用它自行创建 GitHub issue，通过 stdin 直接传递清单内容：

gh issue create \
  --title "Release ${PACKAGE_NAME} ${NEW_VERSION}" \
  --body-file - <<'EOF'
[checklist content here]
EOF

然后向用户显示：

包含 issue URL 的成功消息。
建议："您现在可以使用 'do-release-checklist' 技能来逐步执行清单任务。"（注意：这是一个配套技能，可帮助指导用户执行清单项目。如果您的仓库中尚未存在此技能，可以省略此建议。）

如果 gh 不可用，则向用户显示清单，并附上手动创建 GitHub issue 的说明：

显示建议的 issue 标题："Release ${PACKAGE_NAME} ${NEW_VERSION}"
显示格式化为 Markdown 的完整清单内容。
指导用户复制内容并在其仓库的 issues 页面手动创建 issue。

如果 GitHub issue 创建失败（使用 gh 时），检查常见问题：

认证错误：确保 gh auth status 显示用户已登录。如果需要，建议运行 gh auth login。
仓库权限：用户必须具有写入权限才能创建 issue。使用 gh repo view 检查他们是否具有正确的权限。
网络错误：如果存在连接问题，建议重试命令或检查互联网连接。
无效的 Markdown：如果 issue 正文存在格式错误，请验证清单 Markdown 是否格式正确且语法有效。

如果 issue 创建失败，请保留清单内容并提供以下选项：

重试命令。
改为显示清单以供手动创建 issue。

🇺🇸English

Create an R Package Release Checklist

Generate a release checklist for an R package and create the corresponding GitHub issue.

Overview

This skill guides you through creating a R package release checklist issue on GitHub by:

Determining the current version and prompting for release type.
Generating an initial checklist.
Prompting the user for additional customization.
Creating a GitHub issue from the final checklist.

Prerequisites

The working directory must be an R package with a DESCRIPTION file at the root.
The usethis R package must be available.

And to enable automatic issue creation:

The gh CLI must be installed and authenticated.
The R package must be associated with a GitHub repository.

Workflow

Step 1: Validation

First, check that the prerequisites are available (in this order for efficiency):

Check that the working directory contains a file called DESCRIPTION. If not, inform the user that this must be run from an R package root directory and stop.
Use Rscript -e 'utils::packageVersion("usethis")' to check if the usethis package is installed. If not, instruct the user to install it with install.packages("usethis"), then stop.
Determine the GitHub URL for the repository, if one exists. First try gh repo view --json url. If that fails, diagnose the error:
- If gh is not installed, try running git remote -v to find a GitHub URL.
- If the local repo does not have a GitHub remote, suggest the user connect the package to GitHub using usethis::use_github(). Offer to run this command for the user; if they decline, continue without a GitHub URL.
- If gh is installed but not authenticated and the repo has a GitHub remote, suggest that the user run gh auth login.

If any check fails, inform the user of the specific issue with clear instructions on how to fix it, then stop the workflow. Do not proceed to the next step until all prerequisites are met.

Step 2: Initialization

Next, you need to determine the current package's name and version. Read the DESCRIPTION file and extract the Version: and Package: fields from it.

Then, check if a NEWS.md file exists. If it does, read the first section (typically the most recent unreleased changes) to understand what kind of changes have been made. Use this to suggest an appropriate release type:

If the NEWS mentions "breaking changes", "breaking", "BREAKING", or similar language, suggest a Major release.
If the NEWS mentions only "bug fixes", "fixes", "patch", or similar language with no new features, suggest a Patch release.
Otherwise (new features, improvements, enhancements), suggest a Minor release.

Display the current version to the user and ask them what type of release this should be using the AskUserQuestion tool. Make the suggested release type the first option with "(Recommended)" appended to the label:

Question: "What type of release is this?" Header: "Release type" Options (with recommended option first):

Major (X.0.0) - Breaking changes (add "(Recommended)" if suggested)
Minor (x.X.0) - New features but without breaking changes (add "(Recommended)" if suggested)
Patch (x.x.X) - Bug fixes only (add "(Recommended)" if suggested)

Calculate the new version by manipulating the current version according to the user's answer. For example:

Current version 1.2.3 + Major release → 2.0.0
Current version 1.2.3 + Minor release → 1.3.0
Current version 1.2.3 + Patch release → 1.2.4
Current version 0.2.1.9000 + Patch release → 0.2.2
Current version 0.2.1.9003 + Minor release → 0.3.0

Note: If the current version ends in .9xxx (R-style development versions), strip that suffix before calculating the new version.

Display: "Preparing release checklist for ${PACKAGE_NAME} ${CURRENT_VERSION} → ${NEW_VERSION}".

Step 3: Checklist Generation

Generate an initial checklist using the scripts/generate_checklist.R script included with this skill:

# If the GitHub URL is known:
Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}" "${GITHUB_URL}"

# Otherwise:
Rscript "${SKILL_DIR}/scripts/generate_checklist.R" "${NEW_VERSION}"

(Where ${SKILL_DIR} represents the directory where this skill is installed.)

Ignore any "Setting active project..." lines in the output.

Read the generated checklist (which is Markdown) and display it to the user.

Step 4: User Customization

Use the AskUserQuestion tool to ask:

Question: "Would you like to customize the checklist before creating the issue?" Header: "Customize?" Options:

No, create the issue as-is
Yes, let me customize it

If the user wants to customize the checklist, enter an iterative refinement loop:

Ask: "Suggest items that should be added or any items that can be safely removed, or confirm that there are no more changes requested."
Based on the user's feedback, update the checklist (add items, remove items, reword items, etc.). Keep the checklist in Markdown format with proper checkbox syntax (- [ ] for tasks).
Display the updated checklist to the user.
Ask: "Does this look good or do you have more suggestions?"
If the user has more suggestions, go back to step 2. If the user confirms it looks good, exit the loop and proceed to Step 5.

The checklist should be maintained as a Markdown string throughout this process so it can be easily passed to the GitHub issue creation command.

Step 5: GitHub Issue Creation

The final checklist should be formatted as Markdown with proper sections and checkboxes.

Ifgh is available and authenticated, use it to create the GitHub issue yourself, passing the checklist content directly via stdin:

gh issue create \
  --title "Release ${PACKAGE_NAME} ${NEW_VERSION}" \
  --body-file - <<'EOF'
[checklist content here]
EOF

Then show the user:

A success message with the issue URL.
The suggestion "You can now use the 'do-release-checklist' skill to walk through the checklist tasks." (Note: This is a companion skill that helps guide users through executing the checklist items. If this skill doesn't exist yet in your repository, you may omit this suggestion.)

Ifgh is not available, display the checklist to the user with instructions to manually create a GitHub issue:

Show the suggested issue title: "Release ${PACKAGE_NAME} ${NEW_VERSION}"
Show the full checklist content formatted as Markdown.
Instruct the user to copy the content and create the issue manually at their repository's issues page.

Error Handling

If the GitHub issue creation fails (when using gh), check for common issues:

Authentication errors : Ensure gh auth status shows the user is logged in. Suggest running gh auth login if needed.
Repository permissions : The user must have write access to create issues. Check with gh repo view to verify they have the correct permissions.
Network errors : If there are connectivity issues, suggest retrying the command or checking their internet connection.
Invalid Markdown : If the issue body has formatting errors, verify the checklist Markdown is properly formatted with valid syntax.

If the issue creation fails, preserve the checklist content and offer to:

Retry the command.
Display the checklist for manual issue creation instead.

Weekly Installs

Repository

posit-dev/skills

GitHub Stars

205

First Seen

Feb 10, 2026

Security Audits

Gen Agent Trust HubWarn SocketPass SnykPass

Installed on

opencode84

github-copilot84

claude-code83

codex82

gemini-cli82

kimi-cli81

Skills CLI 使用指南：AI Agent 技能包管理器安装与管理教程

43,100 周安装