用途：在需要打开或准备一个 Pull Request 时，按目标仓库当前适用的 PR 模板撰写简洁清晰的标题与描述，并可实际创建 PR。
主要能力：每次运行都会在仓库根目录、.github/ 与 docs/（含模板目录）中查找并读取现行 PR 模板，包括其中的 HTML 注释、链接的指南与贡献说明；若存在多个模板，选择与本次改动匹配的那个。会用模板自身的分区、顺序、长度限制与清单要求来组织内容，而不是套用固定标题或记忆中的旧版本。
写法要求：先看针对目标基础分支的完整 diff 和相关议题上下文，描述最终改动而非工作过程或被放弃的方案。叙述以一个简短摘要开头，说明改了什么、为何重要；用短句和具体行为表述，深层技术细节放在模板允许且评审者需要的位置。修 bug 时区分原始问题复现条件、预期行为、修复前实际行为以及修复如何弥合差距；未实际复现的步骤需标注为未验证。可补充实现思路与关键决策、影响评审或用户的权衡，必要时用聚焦的片段或 Mermaid 图辅助，但不重复文字。不要在描述中加入验证章节、命令日志或测试清单，只可简述新增测试覆盖的行为；模板强制要求时保留其标题但按用户偏好省略执行报告，并在 PR 外说明该冲突。
链接与发布：把相关议题与 PR 放进模板的链接分区，若请求中带有 Linear 工单，则用其提供的 URL 或通过可用上下文解析标识符，绝不编造工作区链接；仅对确实会被关闭的议题使用关闭关键字，其余标为相关工作或依赖。发布前确认仓库、基础分支与改动范围，遵从用户对 draft 或正式 PR 的要求；用 gh 时把 Markdown 写入临时文件并用 --body-file 保留换行与代码。创建前先检查该分支是否已有 PR，结果不明确时先确认是否已成功，避免重复；认证或权限失败要如实报告而非反复重试。最后返回 PR 链接并请用户审阅，执行结果与阻塞项留在任务回复中。
限制：若未找到本地模板，则查目标仓库及 GitHub 共享默认模板，仍无则使用适配改动的紧凑结构并说明未找到模板；缺少必要链接时应向用户索取，不得编造链接或议题编号；全部事实以资料为准。