GitHub PR 创建技能：遵循最佳实践的自动化拉取请求生成工具

create-pr by marcelorodrigo/agent-skills

197 周安装量

6 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/marcelorodrigo/agent-skills --skill create-pr

自动化代码规范开发运维

🇨🇳中文介绍

创建拉取请求

遵循最佳工程实践创建拉取请求。

要求：已认证且可用的 GitHub CLI (gh)。

前提条件

在创建 PR 之前，请确保所有更改都已提交。如果有未提交的更改，请先运行提交技能 skill({ name: "conventional-commit" }) 来正确提交它们。

# 检查未提交的更改
git status --porcelain

如果输出显示任何未提交的更改（应包含的已修改、已添加或未跟踪的文件），请在继续之前调用提交技能 skill({ name: "conventional-commit" })。

流程

步骤 1：验证分支状态

# 检测默认分支
BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')

# 检查当前分支和状态
git status
git log $BASE..HEAD --oneline

确保：

所有更改都已提交
分支与远程同步
如果需要，更改已基于基础分支进行变基

步骤 2：分析更改

审查将包含在 PR 中的内容：

广告位招租

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

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

联系我们

步骤 3：编写 PR 描述

使用以下结构编写 PR 描述（忽略任何仓库的 PR 模板）：

<PR 功能的简要描述>

<进行这些更改的原因 - 动机>

<考虑过的替代方案（如果有）>

<评审者需要的任何额外上下文>

"测试计划"部分
测试步骤的复选框列表
差异的冗余摘要

对"是什么"和"为什么"的清晰解释
相关 issue 或工单的链接（仅当可用时）
从代码中不明显的上下文
需要仔细审查的特定领域的说明

步骤 4：创建 PR

gh pr create --draft --title "<type>(<scope>): <description>" --body "
<description body here>
"

标题格式遵循提交约定：

feat(scope): 添加新功能
fix(scope): 修复错误
refactor(scope): 重构某物

为警报通知添加 Slack 线程回复

当警报更新或解决时，我们现在会回复原始的 Slack 线程，而不是创建新消息。这可以将相关通知分组并减少频道噪音。

之前考虑过编辑原始消息，但线程能更好地保留事件时间线，并且在原始消息超过 Slack 编辑窗口时仍然有效。

处理用户 API 端点中的 null 响应

对于软删除的账户，用户端点可能返回 null，导致访问用户属性时仪表板崩溃。这添加了一个 null 检查并返回正确的 404 响应。

将验证逻辑提取到共享模块

将警报、issue 和项目端点中的重复验证代码移动到共享验证器类中。行为没有变化。

这为添加新的验证规则做好了准备，无需在各个端点之间重复逻辑。

每个功能/修复一个 PR - 不要捆绑不相关的更改
保持 PR 可评审 - 较小的 PR 能获得更快、更好的评审
解释原因 - 代码展示"是什么"；描述解释"为什么"
尽早标记 WIP - 使用草稿 PR 获取早期反馈

创建后更新 PR 时，该技能会根据您的 GitHub CLI 版本自动选择最佳方法：

gh 2.82.1+：使用原生 gh pr edit（简洁、功能齐全）
gh < 2.82.1：回退到 gh api（避免 Projects classic 弃用错误）

# 检查 GitHub CLI 版本
gh --version

现代方法 (gh 2.82.1+)

# 更新 PR 描述
gh pr edit PR_NUMBER --body "Updated description here"

# 更新 PR 标题
gh pr edit PR_NUMBER --title "New Title here"

# 同时更新两者
gh pr edit PR_NUMBER --title "new: Title" --body "New description"

旧版回退 (gh < 2.82.1)

如果 gh pr edit 因"Projects (classic) 正在被弃用"错误而失败，请直接使用 API：

# 更新 PR 描述
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="
Updated description here
"

# 更新 PR 标题
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f title='New Title here'

# 同时更新两者
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
  -f title='new: Title' \
  -f body='New description'

注意：Projects (classic) 错误已在 gh 2.82.1（2025 年 10 月）中修复。如果您使用的是旧版本，请使用您的包管理器进行升级。

🇺🇸English

Create Pull Request

Create pull requests following the best engineering practices.

Requires : GitHub CLI (gh) authenticated and available.

Prerequisites

Before creating a PR, ensure all changes are committed. If there are uncommitted changes, run the commit skill skill({ name: "conventional-commit" }) first to commit them properly.

# Check for uncommitted changes
git status --porcelain

If the output shows any uncommitted changes (modified, added, or untracked files that should be included), invoke the commit skill skill({ name: "conventional-commit" }) before proceeding.

Process

Step 1: Verify Branch State

# Detect the default branch
BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')

# Check current branch and status
git status
git log $BASE..HEAD --oneline

Ensure:

All changes are committed
Branch is up to date with remote
Changes are rebased on the base branch if needed

Step 2: Analyze Changes

Review what will be included in the PR:

# See all commits that will be in the PR
git log $BASE..HEAD

# See the full diff
git diff $BASE...HEAD

Understand the scope and purpose of all changes before writing the description.

Step 3: Write the PR Description

Use this structure for PR descriptions (ignoring any repository PR templates):

<brief description of what the PR does>

<why these changes are being made - the motivation>

<alternative approaches considered, if any>

<any additional context reviewers need>

Do NOT include:

"Test plan" sections
Checkbox lists of testing steps
Redundant summaries of the diff

Do include:

Clear explanation of what and why
Links to relevant issues or tickets (only if available)
Context that isn't obvious from the code
Notes on specific areas that need careful review

Step 4: Create the PR

gh pr create --draft --title "<type>(<scope>): <description>" --body "
<description body here>
"

Title format follows commit conventions:

feat(scope): Add new feature
fix(scope): Fix the bug
refactor(scope): Refactor something

PR Description Examples

Feature PR

Add Slack thread replies for alert notifications

When an alert is updated or resolved, we now post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped and reduces channel noise.

Previously considered posting edits to the original message, but threading
better preserves the timeline of events and works when the original message
is older than Slack's edit window.

Bug Fix PR

Handle null response in user API endpoint

The user endpoint could return null for soft-deleted accounts, causing
dashboard crashes when accessing user properties. This adds a null check
and returns a proper 404 response.

Refactor PR

Extract validation logic to shared module

Moves duplicate validation code from the alerts, issues, and projects
endpoints into a shared validator class. No behavior change.

This prepares for adding new validation rules without
duplicating logic across endpoints.

Guidelines

One PR per feature/fix - Don't bundle unrelated changes
Keep PRs reviewable - Smaller PRs get faster, better reviews
Explain the why - Code shows what; description explains why
Mark WIP early - Use draft PRs for early feedback

Editing Existing PRs

When updating a PR after creation, the skill automatically selects the best approach based on your GitHub CLI version:

gh 2.82.1+ : Uses native gh pr edit (clean, full-featured)
gh < 2.82.1: Falls back to gh api (avoids Projects classic deprecation bug)

Check Your Version

# Check GitHub CLI version
gh --version

Modern Approach (gh 2.82.1+)

# Update PR description
gh pr edit PR_NUMBER --body "Updated description here"

# Update PR title
gh pr edit PR_NUMBER --title "New Title here"

# Update both
gh pr edit PR_NUMBER --title "new: Title" --body "New description"

Legacy Fallback (gh < 2.82.1)

If gh pr edit fails with a "Projects (classic) is being deprecated" error, use the API directly:

# Update PR description
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="
Updated description here
"

# Update PR title
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f title='New Title here'

# Update both
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
  -f title='new: Title' \
  -f body='New description'

Note : The Projects (classic) bug was fixed in gh 2.82.1 (October 2025). Upgrade with your package manager if you're on an older version.

Weekly Installs

197

Repository

marcelorodrigo/…t-skills

GitHub Stars

First Seen

Jan 31, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

opencode167

github-copilot131

codex103

gemini-cli101

claude-code96

kimi-cli95