create-pr

创建 PR

为忙碌的开发者而写：在补充细节之前，先说明变更内容及其目的。

阅读当前模板

• 每次都要找到并阅读仓库适用的 PR 模板，包括 HTML 注释、链接的指南和贡献说明。检查仓库根目录、.github/ 和 docs/，包括模板目录。如果存在多个模板，选择最适合该变更的一个。
• 使用模板当前的章节、顺序、长度限制和检查清单说明。不要将其结构复制到本技能中，也不要复用记忆中的版本。
• 优先使用实际的当前 PR 模板，而不是其他指南中过时的结构副本；同时仍要遵循任何兼容的贡献规则。
• 如果本地不存在模板，检查目标仓库及其共享的 GitHub 默认模板。如果都不存在，使用适合该变更的紧凑结构，并说明未找到模板。
• 检查针对预期基础分支的完整 diff 以及相关 issue 上下文。描述最终变更，而不是工作顺序或被放弃的方案。

撰写描述

将以下内容放入模板的相应章节，而不是添加一组固定的标题：

• 以简短摘要开头，说明变更内容及其重要性。如果模板以链接或元数据开头，保留该顺序，并让第一个说明性章节以摘要开头。
• 使用短句、简单的英语和具体行为。将更深入的技术细节放在后面，仅在模板允许且审查者需要时放置。
• 对于缺陷修复，包括复现原始问题的设置和步骤、预期行为、修复前观察到的行为，以及修复如何弥合该差距。即使以紧凑示例表达，也要保持这些内容彼此区分。除非你确实复现了问题，否则不要声称已复现；对未验证的步骤加以标注。
• 简要说明实现方法：关键决策及其如何产生预期行为。仅当权衡或后果会影响审查或用户时，才提及它们。
• 当少量小图或代码示例能比文字更清楚地说明复现、前后行为、方法或后果时，考虑使用它们。优先使用聚焦的代码片段或 Mermaid 图；省略仅重复文字的视觉内容。遵守模板的长度限制。
• 不要添加验证或核实章节、命令日志，或已运行的检查或测试列表。你可以简要提及添加到代码库中的测试及其覆盖的行为。此限制针对描述；仍要执行仓库要求的检查。
• 保留必需的检查清单项，并如实标记。如果模板明确要求验证章节或执行结果，保留其必需标题或字段，但省略命令/测试运行报告，遵循用户偏好。在 PR 之外向用户说明这一具体冲突。

链接相关工作

• 在模板的链接章节或最接近的现有章节中包含相关 issue 和关联 PR。如果没有合适的章节，仅当其指南允许时，添加一个小型链接章节。
• 在该章节中包含随请求提供的任何 Linear 工单。使用其提供的 URL，或通过可用上下文或工具解析其标识符；切勿编造工作区 URL。
• 仅对本次 PR 实际解决的 issue 使用关闭关键词。将其他 issue、工单和 PR 标注为相关工作或依赖，而不是暗示它们将被关闭。
• 不要编造链接或 issue 编号。如果无法解析必需的链接，请询问缺失的信息；当没有已知的相关工作时，遵循模板对空字段的惯例。

创建 PR

• 根据任务和仓库上下文确认目标仓库、基础分支和变更范围。遵循用户请求的是草稿 PR 还是就绪 PR。
• 当请求创建 PR 时，使用可用的 GitHub 工具或 gh 来完成。如果仅请求描述，则返回草稿而不发布。仅在用户授权范围内提交或推送，并排除无关变更。
• 发布前，将完成的描述与每个模板部分和说明进行比对。确认陈述与 diff 一致、链接准确、没有遗留占位符。
• 使用 gh 时，将准确的 Markdown 写入临时文件，并使用 --body-file 以保留换行和字面代码。
• 创建 PR 前，检查该分支是否已有 PR。如果创建结果不明确，先检查是否已成功再重试，以避免重复。对于未解决的身份验证或权限失败，应报告而不是反复重试。
• 返回 PR 链接并请用户审阅。将执行结果和任何阻塞项保留在任务响应中，而非 PR 描述中。