用途：create-pr 提供创建良好 PR 的模式与约定。工作完成后，为当前改动创建新 PR；若尚未在新分支上，先创建分支再创建 PR。它把改动视为正式交付物，认为描述是读者最先看到的内容，多数人不会逐行阅读 diff。
目标读者：团队中的开发者，已了解仓库与现有架构，但未见过本次工作。无需解释代码库、框架或系统一般运作方式，但需清楚说明本 PR 引入的所有新内容，包括概念、实体、流程与行为，使读者不打开 diff 也能理解改动。只覆盖本 PR 内容；若属于更大工作（MVP、迁移、重构），用一句话交代背景即可，不要重述整个项目。
标题：一行总结改动，具体、陈述式、祈使语气。例如 Add alert incident lifecycle and worker pipeline；避免 Alert work、Various improvements 之类。若仓库有前缀约定（feat:、fix:、[backend] 等），需匹配。
描述必须传达：本 PR 做了什么（用平实语言说明实际改动）；为什么存在（问题、动机或解除阻塞，若标题已自明可省略）。此外按需包含：引入的新领域概念（实体、事件、任务、状态等）是什么、何时创建、由谁产生和消费；非显然决策，如权衡、被否决的替代方案、diff 中不可见的 schema 或并发选择；有意的范围裁剪与已知后续工作；评审者否则需从代码反推的内容；相关时的测试或验证方式。仅代码层面有趣的内容（命名、文件移动、机械重构）留在 diff 中。
结构：不套固定模板，结构取决于 PR 内容。先问读者需要知道什么、按什么顺序，再分组为标题贴合实际内容的章节。小 bug 修复可能三句话、无标题；引入新子系统的 PR 可能有五个章节。顺序上先放最快定位读者的内容（通常是摘要），再放背景，边缘情况、注意事项和后续工作靠后。
链接：若存在相关 issue 或 PR，使用 GitHub 关键词语法链接，如 Closes #123、Refs #456。
风格：读起来像资深工程师写给同事，直接、具体、无填充。避免营销形容词（comprehensive、robust、seamless、powerful、elegant、sophisticated、production-ready、first-class）；避免模糊动词（aims to、seeks to、strives to）；避免填充动词（leverages/utilizes 改为 uses，ensures that X 直接陈述 X，facilitates 改为描述实际机制）；避免开场套话（It's worth noting that、Importantly、In essence、It should be mentioned that）；避免结尾总结（In summary、Overall、Ultimately）；避免模糊抽象（provides functionality for X 改为说明具体做什么）；避免人为排比（fast, clean, and reliable 只保留真正重要的一个）；避免 Not just X but Y 句式；In order to 改为 to；避免在章节首句重述提示或标题。用陈述式写作，如 Adds X. X is created when Y happens.，而非 This PR aims to introduce X。散文适合连贯想法，列表适合避免大段文字，不要罗列每个改动文件。标题默认小写，除非仓库现有 PR 使用其他约定。
输出：以原始 markdown 返回标题和描述，分别放在独立代码块中，便于直接粘贴到 GitHub，不加前言或后置评论。若 PR 包含明显 UI 工作（新视图、新章节、视觉变化），在末尾提醒附上截图或简短录屏，供评审者参考。
限制：资料未提供安装命令、价格、平台支持或具体工具集成方式，暂未提供。