用途
git-commit-push-pr 用于把工作区中的改动一步推进到已创建的拉取请求（PR），也可以只更新已有 PR 的描述。它的关键区别在于：PR 描述会传达改动的价值与意图，并且描述深度与改动复杂度成比例。
主要能力
- 模式检测：如果用户要求更新、刷新或重写已有 PR 描述（未提及提交或推送），进入仅更新描述流程；否则进入完整流程。更新时用户还可提供聚焦点（例如“更新 PR 描述并加入基准测试结果”）。
- 仅更新描述流程：确认意图 → 查找 PR → 撰写并应用更新后的描述。查找 PR 时用
gh pr view --json url,title,state，对非零退出需区分“无 PR”“PR 已关闭/合并”“其他错误”等情况。应用前用gh pr edit --body修改。 - 完整流程：收集上下文 → 确定约定 → 检查已有 PR → 分支、暂存与提交 → 推送 → 撰写 PR 描述 → 创建 PR。
使用方式
仅更新描述流程：
- DU-1 确认意图，使用平台阻塞式提问工具（Claude Code 用 AskUserQuestion，Codex 用 request_user_input，Gemini 用 ask_user）；无工具则提问等待回复，用户拒绝则停止。
- DU-2 用
git branch --show-current找分支，分离 HEAD 则停止；再用gh pr view --json url,title,state找 PR。 - DU-3 用
gh pr view --json body --jq '.body'读取现有描述，按完整流程 Step 6 的原则写新描述，与现有描述对比后向用户总结实质性变化并确认，再应用并报告 PR URL。
完整流程：
- Step 1 收集上下文：
git status、git diff HEAD、git branch --show-current、git log --oneline -10、git rev-parse --abbrev-ref origin/HEAD；失败则用gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'，都失败回退 main。分离 HEAD 时询问是否创建特性分支，用户同意则用git checkout -b <branch-name>。工作区干净时，会检查未推送提交或缺失 PR，并处理默认分支推送风险。 - Step 2 确定约定：优先项目已加载约定（AGENTS.md、CLAUDE.md 等），其次最近 10 条提交历史，默认 conventional commits。
- Step 3 检查已有 PR：
gh pr view --json url,title,state，区分 OPEN、非 OPEN 与其他错误。 - Step 4 分支、暂存与提交：在默认分支上先建特性分支；按文件分组最多两三个逻辑提交；按名称暂存，避免
git add -A/git add .；提交信息用 heredoc。 - Step 5 推送：
git push -u origin HEAD。 - Step 6 撰写 PR 描述：先解析基线分支与远程（按 PR 元数据、
git symbolic-ref、GitHub 默认分支、常见分支名依次回退），再收集分支范围（git merge-base、git log --oneline <merge-base>..HEAD、git diff <merge-base>...HEAD）。描述按改动规模与复杂度自适应：小且简单 1-2 句、300 字符内；小但非平凡 3-5 句问题/修复叙述；中型功能或重构含摘要段与说明段；大型或架构级用完整叙述；性能改进附前后对比表格（如 p95 延迟、内存峰值）。 - Step 7 创建 PR 或走已有 PR 流程。
**写作原则：**以价值开头；无孤立开头段落；描述净结果而非过程；提交冲突时以最终 diff 为准；解释非显而易见之处；按需使用结构与表格；不留空章节；测试计划仅在增加价值时包含；列表项前缀避免用 #，引用 issue/PR 用 org/repo#123 或完整 URL。
适用场景
用户说“commit and PR”“push and open a PR”“ship this”“create a…”，或需要刷新已有 PR 描述时。
限制
除上述流程外，其他功能、收费、价格、平台支持等信息暂未提供。