Back to Details

pr-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GitHub Pull Request

GitHub Pull Request

Determine Mode of Operation

确定操作模式

Identify which mode to use based on user's request:
Mode 1: Generate PR Content in Chat
Use when user wants to see/copy PR content WITHOUT creating it on GitHub:
  • Explicit requests: "show PR", "generate PR", "output PR", "give me PR", "PR to chat", "send to chat"
  • Key indicators: Words like "show", "display", "output", "give", "send to chat" without "create"/"open"
  • When unclear: If ambiguous (no existing PR, no clear "create" intent), default to this mode
Mode 2: Create PR on GitHub
Use when user wants to actually create PR:
  • Explicit creation: "create PR", "open PR", "make PR", "submit PR"
  • Clear action: User clearly wants to create/open PR on GitHub
Default for ambiguous requests: Use Mode 1 (generate in chat) to show user what will be created first.
根据用户的请求确定要使用的模式：
模式1：在聊天中生成PR内容
当用户希望查看/复制PR内容但不在GitHub上创建时使用：
  • 明确请求："show PR"、"generate PR"、"output PR"、"give me PR"、"PR to chat"、"send to chat"
  • 关键标识：包含"show"、"display"、"output"、"give"、"send to chat"等词，但不包含"create"/"open"
  • 模糊情况：如果请求不明确（无现有PR，无明确的"创建"意图），默认使用此模式
模式2：在GitHub上创建PR
当用户希望实际创建PR时使用：
  • 明确创建请求："create PR"、"open PR"、"make PR"、"submit PR"
  • 明确操作：用户明确希望在GitHub上创建/打开PR
模糊请求的默认处理：使用模式1（在聊天中生成），先向用户展示将要创建的内容。

Workflow for Creating Pull Requests

拉取请求创建工作流

Follow this workflow systematically when creating PRs:
创建PR时请系统遵循以下工作流：

Step 1: Determine the Scenario

步骤1：确定场景

Which scenario applies?
  • Scenario A: Creating PR for existing branch with commits
    • Branch exists with commits that differ from base branch
    • Need to analyze ALL commits in the branch
    • → Use git diff/log or branch comparison tools
  • Scenario B: User has uncommitted/unstaged local changes
    • Changes not yet committed
    • User wants to commit and create PR
    • → First help commit changes, then proceed with Scenario A
IMPORTANT: Most PR requests are Scenario A - analyzing an existing feature branch!
适用哪种场景？
  • 场景A：为已有提交的分支创建PR
    • 分支已存在，且与基准分支存在提交差异
    • 需要分析分支中的所有提交
    • → 使用git diff/log或分支对比工具
  • 场景B：用户有未提交/未暂存的本地变更
    • 变更尚未提交
    • 用户希望提交变更并创建PR
    • → 先协助提交变更，再按照场景A的流程操作
重要提示：大多数PR请求属于场景A——分析已有的功能分支！

Step 2: Identify Current Branch and Base Branch

步骤2：识别当前分支和基准分支

First, determine what branch you're working with:
bash
undefined
首先，确定你正在处理的分支：
bash
undefined

Get current branch name

获取当前分支名称

git branch --show-current
git branch --show-current

Identify base branch (usually main/master)

识别基准分支（通常为main/master）

git remote show origin | grep "HEAD branch"

Common base branches: `master`, `main`, `develop`
git remote show origin | grep "HEAD branch"

常见基准分支：`master`、`main`、`develop`

Step 3: Get Complete Branch Changes

步骤3：获取完整的分支变更

CRITICAL: Analyze ALL changes in the entire branch that will be merged, not just:
  • ❌ The last commit
  • ❌ Previous chat context
  • ❌ Individual file changes mentioned earlier
What you need to obtain:
  • Complete diff between current branch and base branch
  • List of all modified files
  • All commit messages in the branch
  • Full context of what changed
How to get this information:
Primary approach - Git commands (universal):
bash
undefined
关键要求：分析将要合并的分支中的所有变更，而不仅仅是：
  • ❌ 最后一次提交
  • ❌ 之前的聊天上下文
  • ❌ 之前提到的单个文件变更
你需要获取的信息：
  • 当前分支与基准分支之间的完整差异
  • 所有已修改文件的列表
  • 分支中的所有提交信息
  • 变更的完整上下文
如何获取这些信息：
主要方式 - Git命令（通用）：
bash
undefined

Get full diff between branches

获取分支间的完整差异

git diff <base-branch>...<current-branch>
git diff <base-branch>...<current-branch>

Example:

示例：

git diff main...feature-branch
git diff main...feature-branch

List changed files only:

仅列出已变更的文件：

git diff --name-status main...feature-branch
git diff --name-status main...feature-branch

See all commits in branch:

查看分支中的所有提交：

git log <base-branch>..<current-branch> --oneline

**Alternative - Use available tools in your environment:**

Depending on your environment, you may have access to:

- IDE diff viewers or change tracking features
- Version control UI showing branch comparisons
- File comparison tools
- Any method that shows complete changeset between branches

The key is obtaining the **complete changeset**, regardless of the method.

**For uncommitted changes:**
If changes are not yet committed, first check what's uncommitted using:

- `git status` and `git diff` (for git environments)
- Your IDE's change tracker or source control panel
- Any tool showing unstaged/uncommitted modifications

**Troubleshooting "No Changes" Issue:**

If you get empty diff or "no changes":

1. ✅ Verify you're comparing correct branches (current vs base)
2. ✅ Check if current branch IS the base branch (can't PR main to main!)
3. ✅ Ensure commits exist in branch: `git log --oneline -10`
4. ✅ Try: `git log <base-branch>..<current-branch>` to see commits
5. ❌ If truly no changes, inform user PR cannot be created without changes
git log <base-branch>..<current-branch> --oneline

**替代方式 - 使用环境中可用的工具：**

根据你的环境，你可能可以使用：

- IDE差异查看器或变更跟踪功能
- 显示分支对比的版本控制UI
- 文件对比工具
- 任何能展示分支间完整变更集的方法

关键是获取**完整的变更集**，无论使用哪种方法。

**针对未提交的变更：**
如果变更尚未提交，首先使用以下方式检查未提交内容：

- `git status` 和 `git diff`（适用于Git环境）
- IDE的变更跟踪器或源代码控制面板
- 任何能展示未暂存/未提交修改的工具

**"无变更"问题排查：**

如果得到空差异或"无变更"提示：

1. ✅ 验证你正在对比的是正确的分支（当前分支 vs 基准分支）
2. ✅ 检查当前分支是否就是基准分支（不能给main分支向main分支创建PR！）
3. ✅ 确保分支中存在提交：`git log --oneline -10`
4. ✅ 尝试：`git log <base-branch>..<current-branch>` 查看提交
5. ❌ 如果确实没有变更，请告知用户没有变更无法创建PR

Step 4: Analyze Changes Comprehensively

步骤4：全面分析变更

  1. Review every modified file in the branch
  2. Understand the cumulative impact of all commits
  3. Identify affected packages/modules (important for monorepos)
  4. Note any breaking changes or migration requirements
  1. 查看分支中的每个已修改文件
  2. 理解所有提交的累积影响
  3. 识别受影响的包/模块（对于单体仓库很重要）
  4. 记录任何破坏性变更或迁移要求

Step 5: Generate PR Content

步骤5：生成PR内容

Based on complete analysis, create:
  • Title that reflects the main purpose of ALL changes
  • Summary listing all significant modifications
  • Motivation explaining why these changes were needed
  • Related issues with proper linking
This workflow ensures PR descriptions accurately reflect the total scope of changes being merged.
基于完整分析，创建：
  • 能反映所有变更主要目的的标题
  • 列出所有重大修改的摘要
  • 解释这些变更必要性的动机说明
  • 带有正确链接的相关问题
此工作流确保PR描述能准确反映将要合并的变更的整体范围。

Step 6: Create PR or Output to Chat

步骤6：创建PR或输出到聊天

If Mode 2 (Create PR on GitHub) - Default action:
  1. Create PR using available GitHub API tools
  2. After successful creation, provide user with:
    • PR URL
    • Brief confirmation message
If Mode 1 (Generate in Chat) - Fallback:
Output the PR content in chat using the format described in "Fallback: Output Format for Chat" section.
Skip GitHub creation if:
  • User explicitly requested text output only (Mode 1)
  • Authentication/API errors occur (then fallback to Mode 1)
  • Request is ambiguous (then fallback to Mode 1 to show user what will be created)
如果是模式2（在GitHub上创建PR）- 默认操作：
  1. 使用可用的GitHub API工具创建PR
  2. 创建成功后，向用户提供：
    • PR链接
    • 简短的确认消息
如果是模式1（在聊天中生成）- 回退方案：
使用"回退方案：聊天输出格式"部分描述的格式，在聊天中输出PR内容。
以下情况跳过GitHub创建：
  • 用户明确要求仅输出文本（模式1）
  • 发生认证/API错误（然后回退到模式1）
  • 请求不明确（然后回退到模式1，向用户展示将要创建的内容）

Language Requirement

语言要求

CRITICAL: Always write all PR content (title, description, comments) in English only, regardless of the chat language or user's preferred language. This is a strict requirement for all generated PR content.
重要提示：无论聊天语言或用户偏好语言如何，所有PR内容（标题、描述、评论）必须仅使用英文撰写。这是所有生成的PR内容的严格要求。

Fallback: Output Format for Chat

回退方案：聊天输出格式

Use this format when in Mode 1 (Generate PR Content in Chat):
  • User explicitly requests viewing/copying PR content (see "Determine Mode of Operation" section above)
  • Cannot create PR due to API/authentication issues
  • Request is ambiguous (no clear "create" intent)
  • User specifically asks not to create the PR yet
When outputting PR content to chat instead of creating it on GitHub:
ALWAYS wrap the complete PR content in a markdown code block:
markdown
[PR Title Here]

[Full PR Description Here]
This allows user to easily copy the entire PR content with proper formatting preserved.
DO NOT output PR content as rendered markdown in chat - it must be in a copyable code block.
当使用模式1（在聊天中生成PR内容）时使用此格式：
  • 用户明确请求查看/复制PR内容（请参阅上方"确定操作模式"部分）
  • 因API/认证问题无法创建PR
  • 请求不明确（无明确的"创建"意图）
  • 用户特别要求暂不创建PR
当在聊天中输出PR内容而非在GitHub上创建时：
请始终将完整的PR内容包裹在Markdown代码块中：
markdown
[PR标题]

[完整PR描述]
这样用户可以轻松复制整个PR内容，并保留正确的格式。
请勿在聊天中以渲染后的Markdown格式输出PR内容——必须放在可复制的代码块中。

PR Title

PR标题

  • ≤50 characters, imperative mood ("Add feature" not "Added" or "Adds")
  • Accurately reflect main purpose of changes
  • No issue numbers in title (use description)
  • For monorepos, consider a scoped title (e.g., 
    feat(scope): description
    )
Examples:
  • Add dark mode support to theme package
  • Fix input validation in text field component
  • Refactor build configuration for better performance
  • ≤50个字符，使用祈使语气（"Add feature"而非"Added"或"Adds"）
  • 准确反映变更的主要目的
  • 标题中不包含问题编号（请在描述中使用）
  • 对于单体仓库，可考虑使用带范围的标题（例如：
    feat(scope): description
    ）
示例：
  • Add dark mode support to theme package
  • Fix input validation in text field component
  • Refactor build configuration for better performance

PR Description

PR描述

Required sections:
  1. Summary - What changed (bullet points, mention affected packages/modules)
  2. Motivation - Why these changes were necessary, impact on project
  3. Related Issues - 
    Fixes #123
    , 
    Closes #456
    , 
    Related to #789
Optional sections:
  • Testing Notes
  • Breaking Changes (with migration guide)
  • Performance Impact
Example:
markdown
undefined
必填部分：
  1. 摘要 - 变更内容（使用项目符号，提及受影响的包/模块）
  2. 动机 - 这些变更的必要性，对项目的影响
  3. 相关问题 - 
    Fixes #123
    , 
    Closes #456
    , 
    Related to #789
可选部分：
  • 测试说明
  • 破坏性变更（附带迁移指南）
  • 性能影响
示例：
markdown
undefined

Summary

Summary

Adds dark mode support to the theme package:
  • Added dark color palette with semantic tokens
  • Updated CSS variables for theme switching
  • Added theme toggle component
Adds dark mode support to the theme package:
  • Added dark color palette with semantic tokens
  • Updated CSS variables for theme switching
  • Added theme toggle component

Motivation

Motivation

Users requested dark mode to reduce eye strain and improve accessibility.
Users requested dark mode to reduce eye strain and improve accessibility.

Related Issues

Related Issues

Fixes #42
undefined
Fixes #42
undefined

Writing Style

写作风格

Style Reference:
  • Always write using a similar style as this example: "This is a community for chill dudes😎👍 who love to puff on a hookah🌬 with double apple🍎🍏, know their way around bowl packs💨, aren’t fans of vapers🤣, and respect their ladies👩‍🦳🙏."
  • Use emojis as frequently as shown in the example
  • Do not include the example message itself in PR descriptions, just use it as a style reference
See references/pr-examples.md for more examples.
风格参考：
  • 请始终使用与以下示例类似的风格："This is a community for chill dudes😎👍 who love to puff on a hookah🌬 with double apple🍎🍏, know their way around bowl packs💨, aren’t fans of vapers🤣, and respect their ladies👩‍🦳🙏."
  • 像示例中一样频繁使用表情符号
  • 请勿在PR描述中包含示例消息本身，仅将其作为风格参考
更多示例请参阅 references/pr-examples.md

Edge Cases

边缘情况

  • Large changesets: Group changes by component in summary
  • Updating existing PR: Preserve metadata, add update comment
  • Breaking changes: Mark clearly, provide migration guide
  • Monorepo: Clearly indicate affected packages
  • 大型变更集：按组件分组在摘要中列出变更
  • 更新现有PR：保留元数据，添加更新注释
  • 破坏性变更：清晰标记，提供迁移指南
  • 单体仓库：明确指出受影响的包