ticket

Ticket

根据自由格式的描述创建一个 Linear issue。

此技能是 ship / ship-autonomous 技能的上游搭档：它创建的 issue 是这两个技能接手并端到端完成实现的输入。起草 ticket 时，应让其适合作为这些技能的输入——范围明确、验收标准清晰；如果用户希望 ship-autonomous 在实现前先审核计划，则添加计划审批标记（见第 3 步）。

必需工具

• Linear MCP — 用于列出工作区元数据（团队、项目、标签、状态）并创建 issue。如果无法连接，请让用户重新连接。

工作流

1. 阅读描述。 如果信息过少，无法形成有用的 ticket（没有问题陈述或范围），请提出一个简短的澄清问题。否则继续。

2. 通过 Linear MCP 探查工作区：

   • 选择与当前项目目录匹配的团队——列出团队，并选择名称、键或关联的 GitHub 仓库与技能运行所在仓库相符的团队。如果无法明确匹配，只询问用户一次并记住答案。
   • 列出该团队的项目和标签。
   • 如果当前仓库对应的项目显而易见，则预先选择该项目。

3. 起草 ticket：

   • 标题 — 简短、使用祈使语气，不加句末句号（例如：“修复个人资料网格中的双击爱心问题”）。

   • 描述 — 使用以下模板的 Markdown（省略不适用的部分）：

     ## Context
     
     <为什么这很重要／会在哪里出现>
     
     ## Current behavior
     
     <当前发生的情况（如果是 bug）>
     
     ## Desired behavior
     
     <应有的行为>
     
     ## Acceptance criteria
     
     - [ ] ...
     
     ## Notes
     
     <链接、边缘情况、围栏代码块中的代码片段>
     

   • 标签 — 只能从现有标签中选择，不要自行创建。

   • 优先级 — 根据措辞推断（“紧急”“阻塞” → 高；“有更好” → 低）。默认为中。

   • 指派对象 — 除非用户指定，否则留空。

   • 计划审批标记 — 如果用户表示必须先审批计划才能编写代码，则在描述中追加一行明确说明：**Plan first: please post a plan and wait for approval before implementing.** ship-autonomous 技能会扫描 ticket 中的此类措辞，以判断是否需要先进行计划审核。

4. 在聊天中展示草稿，包括标题、正文、团队、项目、标签和优先级。等待用户明确批准。 如果用户要求修改，请编辑后重新展示。

5. 创建 issue，并通过 Linear MCP 在新 ticket 下发布用户最初请求的原文作为第一条评论——这样可以将用户自己的原话与润色后的描述分开保留。不要改述、总结或删减；应逐字复制用户写下的请求（如果其中的 Markdown 渲染后会产生异常，则放入引用围栏代码块）。返回 issue ID 和 URL。

规则

• 正文中不得注明由 AI 生成。
• 标签和优先级必须已存在于工作区中。
• 文件路径、错误信息和堆栈跟踪必须原样放在 ## Notes 的围栏代码块中。
• 如果描述中提到了父项或重复项，则在创建时设置关联关系。