create-issue

创建议题

根据用户的输入，结合当前仓库内容，整理出可直接实施的议题，然后创建该议题。用户要求提交议题，即授权在通过以下关卡后创建议题。

在各自适用范围内，跨轮次复用授权和已确定的决策。 在必须暂停前，先完成独立且已获授权的工作，然后以 Markdown 链接形式提供准确的 skill 文件链接，并在块引用中逐字引用要求作出新决策或获取授权的规则。

关卡

• 起草前先调查：阅读适用的项目说明和愿景，搜索未关闭及已关闭的议题，查找目标结果及实现机制是否已有重复议题，并检查受影响的代码、测试和文档。
• 对尚未解决的重要需求或用户要求的访谈，使用实际注册的 grill-with-docs 或 grill-me 流程；优先使用 grill-with-docs。复用已确定的决策。如果两者都不可用，则直接调查，并且只询问影响议题的缺失信息。
• 如果请求与项目愿景冲突、属于重复议题，或需要无法确认的重要事实，则在起草前停止。若发现重复议题，返回现有议题并停止；不要询问用户是否仍要提交相同请求，也不要修改现有议题。
• 发布前，从当前 GitHub 账户和 Agent 环境中确认已认证的 GitHub 用户名及准确的模型名称。如果任一项不可用，则停止；切勿猜测或用通用标签代替。

草案审核

根据项目证据选择模板、标题、标签和正文，并直接创建议题，无需草案审批。仅当用户明确要求先审批草案时，才先展示草案；例如使用 /create-issue draft 或说“先给我看草案”，包括在后续轮次中提出的此类要求；该要求在其指定范围内持续有效。接受 automatic，但不会因此改变任何内容。应按上述关卡询问并解决重要歧义，不要因此转而要求对完整草案进行审核。

工作流

1. 查找仓库的问题模板和现有标签惯例。

2. 调查请求，并使用上述关卡解决任何尚未解决的重要问题。所有进展声明都必须以本次运行收集的证据为依据。

3. 根据匹配的模板起草内容。保留模板中的所有标题，原文不变且顺序不变；对于没有内容可写的标题，写一行 None 或说明原因。在这些标题下，只保留与决策、实现和验证相关的内容：

   • 具体、通俗易懂的标题；
   • 问题、当前行为和预期行为、范围、约束及所需行为；
   • Bug 的复现和回归预期；
   • 相关的用户/测试影响、可能受影响的区域及相关工作。

4. 对于 UI/UX 工作或本地截图和视频，请阅读 references/ui-evidence.md；切勿将证据媒体提交到仓库。将探测输出等非媒体证据放在折叠的 <details> 块中。

5. 除非用户要求创建新标签，否则只能选择现有标签。

6. 如果起草内容的审核请求仍然适用，且该确切草稿尚未获批，请展示拟定的标题、标签和正文，请用户批准或修改，然后停止；仅在获得批准后创建问题。

7. 在问题正文末尾添加以下视觉上独立的 GitHub Note，并将两个值替换为本次运行中解析出的确切身份：

   说明

   Created on behalf of @username using ModelName.

8. 对草稿运行 template-check，使用 --kind issue --body FILE；在目标仓库检出目录之外时添加 --repo OWNER/REPO，如果仓库有多个模板，则添加 --template-name，并修复检查报告的所有标题问题。使用可用的 GitHub 工具创建问题，验证返回的问题所属仓库及预期内容，然后对实时正文再次运行 template-check，使用 --issue N；如有问题，编辑该问题并修复，最后返回其 URL。如果写入响应丢失或中断，请先搜索问题，再重试。对于尚未解决的写入操作，应报告为不确定；请求已被接受或转交处理，并不能证明问题已创建。

开头直接说明结果。省略套话、重复总结以及对工作流的叙述；模板标题及其一行 None 不属于套话。