describe-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generate PR Description

生成PR描述

You are tasked with generating a comprehensive pull request description following the repository's standard template.

你的任务是遵循仓库的标准模板生成详尽的拉取请求（PR）描述。

Steps to follow:

遵循步骤：

Read the PR description template:
- First, check if
```
thoughts/shared/pr_description.md
```
  exists
- If it doesn't exist, inform the user they need to create a PR description template at
```
thoughts/shared/pr_description.md
```
- Read the template carefully to understand all sections and requirements
Identify the PR to describe:
- Check if the current branch has an associated PR:
```
gh pr view --json url,number,title,state 2>/dev/null
```
- If no PR exists for the current branch, or if on main/master, list open PRs:
```
gh pr list --limit 10 --json number,title,headRefName,author
```
- Ask the user which PR they want to describe
Check for existing description:
- Check if
```
thoughts/shared/prs/{number}_description.md
```
  already exists
- If it exists, read it and inform the user you'll be updating it
- Consider what has changed since the last description was written
Gather comprehensive PR information:
- Get the full PR diff:
```
gh pr diff {number}
```
- If you get an error about no default remote repository, instruct the user to run
```
gh repo set-default
```
  and select the appropriate repository
- Get commit history:
```
gh pr view {number} --json commits
```
- Review the base branch:
```
gh pr view {number} --json baseRefName
```
- Get PR metadata:
```
gh pr view {number} --json url,title,number,state
```

4b. Gather reasoning history (if available):

Check if reasoning files exist:

ls .git/claude/commits/*/reasoning.md 2>/dev/null

If they exist, aggregate them:

bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main

This shows what approaches were tried before the final solution
Save the output for inclusion in the PR description

Analyze the changes thoroughly: (ultrathink about the code changes, their architectural implications, and potential impacts)
- Read through the entire diff carefully
- For context, read any files that are referenced but not shown in the diff
- Understand the purpose and impact of each change
- Identify user-facing changes vs internal implementation details
- Look for breaking changes or migration requirements
Handle verification requirements:
- Look for any checklist items in the "How to verify it" section of the template
- For each verification step:
  - If it's a command you can run (like
```
make check test
```
    ,
```
npm test
```
    , etc.), run it
  - If it passes, mark the checkbox as checked:
```
- [x]
```
  - If it fails, keep it unchecked and note what failed:
```
- [ ]
```
    with explanation
  - If it requires manual testing (UI interactions, external services), leave unchecked and note for user
- Document any verification steps you couldn't complete
Generate the description:
- Fill out each section from the template thoroughly:
  - Answer each question/section based on your analysis
  - Be specific about problems solved and changes made
  - Focus on user impact where relevant
  - Include technical details in appropriate sections
  - Write a concise changelog entry
- If reasoning files were found (from step 4b):
  - Add an "## Approaches Tried" section before "## How to verify it"
  - Include the aggregated reasoning showing failed attempts and what was learned
  - This helps reviewers understand the journey, not just the destination
- Ensure all checklist items are addressed (checked or explained)
Save the description:
- Write the completed description to
```
thoughts/shared/prs/{number}_description.md
```
- Show the user the generated description
Update the PR:
- Update the PR description directly:
```
gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md
```
- Confirm the update was successful
- If any verification steps remain unchecked, remind the user to complete them before merging

阅读PR描述模板：
- 首先检查
```
thoughts/shared/pr_description.md
```
  是否存在
- 如果不存在，告知用户需要在
```
thoughts/shared/pr_description.md
```
  路径下创建PR描述模板
- 仔细阅读模板，了解所有章节和要求
确定要描述的PR：
- 检查当前分支是否关联了PR：
```
gh pr view --json url,number,title,state 2>/dev/null
```
- 如果当前分支没有关联PR，或者处于main/master分支，列出所有开放的PR：
```
gh pr list --limit 10 --json number,title,headRefName,author
```
- 询问用户想要描述哪一个PR
检查现有描述：
- 检查
```
thoughts/shared/prs/{number}_description.md
```
  是否已存在
- 如果存在，读取该文件并告知用户将对其进行更新
- 考虑自上次描述编写以来发生的变更
收集全面的PR信息：
- 获取完整的PR差异：
```
gh pr diff {number}
```
- 如果出现“无默认远程仓库”的错误，指导用户运行
```
gh repo set-default
```
  并选择合适的仓库
- 获取提交历史：
```
gh pr view {number} --json commits
```
- 查看基准分支：
```
gh pr view {number} --json baseRefName
```
- 获取PR元数据：
```
gh pr view {number} --json url,title,number,state
```

4b. 收集推理历史（如果可用）：

检查是否存在推理文件：

ls .git/claude/commits/*/reasoning.md 2>/dev/null

如果存在，汇总这些文件：

bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main

这会展示在最终方案确定前尝试过的各种方法
保存输出内容，以便纳入PR描述中

深入分析变更：（深入思考代码变更、其架构影响以及潜在影响）
- 仔细阅读整个差异内容
- 为了解上下文，阅读差异中引用但未显示的所有文件
- 理解每一项变更的目的和影响
- 区分面向用户的变更与内部实现细节
- 识别破坏性变更或迁移要求
处理验证要求：
- 查看模板中“如何验证”章节的所有检查项
- 对于每一项验证步骤：
  - 如果是可运行的命令（如
```
make check test
```
    、
```
npm test
```
    等），执行该命令
  - 如果通过，将复选框标记为已完成：
```
- [x]
```
  - 如果失败，保持未勾选状态并记录失败原因：
```
- [ ]
```
    附带说明
  - 如果需要手动测试（UI交互、外部服务），保持未勾选状态并告知用户
- 记录所有无法完成的验证步骤
生成描述：
- 完整填写模板中的每个章节：
  - 根据你的分析回答每个问题/填写每个章节
  - 具体说明解决的问题和做出的变更
  - 相关情况下聚焦用户影响
  - 在合适的章节中包含技术细节
  - 编写简洁的变更日志条目
- 如果找到推理文件（来自步骤4b）：
  - 在“## 如何验证”之前添加“## 尝试过的方法”章节
  - 纳入汇总的推理内容，展示失败的尝试和学到的经验
  - 这有助于评审者理解整个过程，而不仅仅是最终结果
- 确保所有检查项都已处理（已勾选或已说明）
保存描述：
- 将完成的描述写入
```
thoughts/shared/prs/{number}_description.md
```
- 向用户展示生成的描述
更新PR：
- 直接更新PR描述：
```
gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md
```
- 确认更新成功
- 如果仍有未勾选的验证步骤，提醒用户在合并前完成这些步骤

Important notes:

重要说明：

This command works across different repositories - always read the local template
Be thorough but concise - descriptions should be scannable
Focus on the "why" as much as the "what"
Include any breaking changes or migration notes prominently
If the PR touches multiple components, organize the description accordingly
Always attempt to run verification commands when possible
Clearly communicate which verification steps need manual testing

该命令适用于不同的仓库 - 请始终读取本地模板
内容需详尽但简洁 - 描述应便于快速浏览
既要关注“做了什么”，也要关注“为什么这么做”
突出显示任何破坏性变更或迁移说明
如果PR涉及多个组件，相应地组织描述内容
尽可能尝试执行验证命令
清晰传达哪些验证步骤需要手动测试