用途：在准备开启 pull request 时，按 Sentry 工程实践生成结构化描述，基于已提交的分支 diff，说明改了什么、为何改以及审查者需要的上下文。适合使用 GitHub CLI、希望获得可重复 PR 撰写流程的场景。
前提：需要已认证且可用的 GitHub CLI（gh）。创建 PR 前须确保所有改动已提交；若有未提交改动，先用可用的 commit 技能提交。可用 git status --porcelain 检查。
流程：1）验证分支状态，用 gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 检测默认分支，再用 git status 与 git log BASE..HEAD --oneline 检查，确保改动已提交、分支与远程同步、必要时已变基。2）分析改动，用 git log BASE..HEAD 与 git diff BASE...HEAD 查看提交与完整 diff。3）撰写 PR 描述，结构为：简述、动机、考虑过的替代方案（如有）、审查者需要的额外上下文。不要包含“测试计划”、测试步骤勾选清单或对 diff 的冗余总结；应包含清晰说明、相关 issue/工单链接、代码之外不明显的信息、需重点审查的说明。4）创建 PR：gh pr create --draft --title "<type>(<scope>): <description>" --body "$(cat <<'EOF' … EOF)"。标题格式遵循提交约定，如 feat(scope): Add new feature、fix(scope): Fix the bug、ref: Refactor something。
issue 引用：Fixes #1234 合并时关闭 GitHub issue；Fixes SENTRY-1234 关闭 Sentry issue；Refs GH-1234 仅链接；Refs LINEAR-ABC-123 链接 Linear issue。
准则：每个功能/修复一个 PR，不捆绑无关改动；保持 PR 可审查；解释“为什么”；尽早标记 WIP，用草稿 PR 获取早期反馈。
编辑已有 PR：使用 gh api 而非 gh pr edit（后者因 GitHub Projects classic 弃用而失效），例如 gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="…" 更新描述或标题。
限制：仅在任务明确匹配上述范围时使用；输出不能替代环境特定验证、测试或专家审查；缺少必要输入、权限、安全边界或成功标准时应停止并请求澄清。其他收费、价格或平台等细节暂未提供。