tenzir-create-pull-requests

创建拉取请求

创建拉取请求并及时更新其变更日志。

工作流

1. 确保更改按合理的单元提交。使用 tenzir-commit-changes 技能进行暂存、拆分和编写提交消息。
2. 起草 PR 正文前，扫描当前上下文，查找相关问题。 检查用户请求、周边对话、分支名称、提交消息、 任何现有的变更日志条目、现有 PR 文本以及任何可用的问题跟踪器上下文。如果可以使用问题跟踪器，请确定此代码 PR 应关闭的主要 Linear 问题；配套文档 PR 只应引用这些问题。
3. 从当前工作树分支创建拉取请求。
4. 添加并提交变更日志条目。不要在此处手动创建或编辑变更日志条目；请使用 tenzir-ship 技能生成、格式化和更新条目。
5. 如果更改影响 docs.tenzir.com 上记录的面向用户的行为，请遵循 tenzir-update-docs 技能，创建配套文档 PR， 交叉链接两个 PR，并在文档 PR 中引用相同的 Linear 问题。
6. 推送分支。

进行后续编辑时，确保变更日志条目与更改后的功能保持同步，并通过 tenzir-ship 处理任何条目更新，而不要手动编辑变更日志文件。

PR 页脚

最终确定 PR 描述前，务必查找相关问题和配套 PR。

• 首先扫描当前上下文：用户提示、分支名称、近期提交、 任何现有变更日志文本、PR 标题和正文草稿，以及配套文档或后续 PR。
• 如果可以使用问题跟踪器，请确认此代码 PR 应关闭哪些问题。
• 在 PR 正文的最末尾使用一个紧凑的 <sub>...</sub> 页脚。
• 将页脚放在 PR 描述中，而不是 PR 评论中。
• 如果已经有页脚，请扩展它，而不是新建一个版块或第二个页脚。
• 保持简洁且便于机器读取：每行优先放一个指令或链接，并用 <br> 连接各行。
• 如果扫描后仍找不到可靠的问题引用或配套 PR，则省略该行；如果关联关系很重要，也可以询问用户。

对于 Linear，请在页脚中明确使用其魔法词：

• 在主要代码 PR 中，使用 closes 等关闭词，以便合并时将主要问题推进到完成状态。
• 对于配套文档 PR 或此 PR 不应关闭的次要问题，使用 references、related to 或 part of 等非关闭词。
• 可以在行首添加表情符号以便于阅读，但不能用它们替代 Linear 的魔法词。实际关键词文本必须保持不变。
• 即使分支名称或 PR 标题中已经提到了问题 ID，如果你希望明确表达关闭还是关联的意图，仍应添加页脚。
• 多个问题具有相同的关联关系时，请在同一行的一个魔法词后列出它们，以保持页脚简洁，例如 ✅ Closes TNZ-82, TNZ-499, TNZ-108, TNZ-109。
• 仅当关联关系不同时才分行，例如一行使用 closes，另一行使用 references。
• 如果有配套文档 PR，请在同一个页脚块中添加类似 📚 Docs PR: tenzir/content#261 的普通文本行，而不是新建专门版块。
• 在页脚中链接 GitHub PR 时，请使用 GitHub 简写，例如 tenzir/tenzir#5999 或 tenzir/content#261，而不要使用完整 URL。只有简写无法表达的深层链接（例如某条具体的问题评论）才使用完整 URL。

页脚示例：

<sub>
📚 Docs PR: tenzir/content#261<br>
✅ Closes TNZ-150, TNZ-151<br>
🎫 References TNZ-152<br>
📎 Related: tenzir/tenzir#5999
</sub>

PR 正文

请使用此模板撰写拉取请求描述：

## 🔍 Problem



## 🛠️ Solution



## 💬 Review

说明：

• 目标读者是资深软件工程师。内容应简洁明了。
• 用简短说明替换每个 HTML 注释。
• 优先使用项目符号列表，避免冗长的叙述。
• 差异本身已足以说明问题，无需解释修改了哪些文件。
• 将页脚放在 PR 正文的最末尾，以便问题跟踪器可靠解析，并让相关 PR 链接保持紧凑。