create-pull-requests

创建拉取请求

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

工作流

1. 确保更改按逻辑单元提交。使用 commit-changes 技能进行暂存、拆分和编写提交消息。
2. 起草 PR 正文前，先扫描当前上下文，查找相关议题。 检查用户请求、上下文对话、分支名称、提交 消息、任何现有变更日志条目、现有 PR 文本，以及任何可用的 议题跟踪器上下文。如果可以访问跟踪器，找出此代码 PR 应关闭的主要 Linear 议题；配套文档 PR 只应引用这些议题。
3. 从当前工作树分支创建拉取请求。
4. 添加并提交变更日志条目。请勿在此处手动创建或编辑 变更日志条目；使用 tenzir-ship 技能生成、格式化和 更新条目。
5. 如果更改影响了 docs.tenzir.com 上记录的面向用户行为，请遵循 update-documentation 技能，创建配套文档 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/docs#261 的普通行，而不是创建单独的章节。
• 在页脚中链接 GitHub PR 时，使用 GitHub 简写，例如 tenzir/tenzir#5999 或 tenzir/docs#261，而不是完整 URL。只有简写无法表达的深层链接（例如特定议题评论）才使用完整 URL。

页脚示例：

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

PR 正文

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

## 🔍 Problem



## 🛠️ Solution



## 💬 Review

说明：

• 目标读者是资深软件工程师。简明扼要，直入主题。
• 用简短说明替换每条 HTML 注释。
• 优先使用项目符号列表，避免冗长的散文。
• 差异本身已说明问题，无需解释修改了哪些文件。
• 将页脚放在 PR 正文最末尾，以便议题跟踪器可靠解析，同时让相关 PR 链接紧凑醒目。