ticket

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ticket

工单

Create a Linear issue from a free-form description.

This skill is the upstream pair of the

ship

skill: the issues it creates are the inputs

ship

picks up and implements end-to-end. Draft tickets so they read well as inputs to

ship

— clear scope, explicit acceptance criteria, and the plan-approval marker (see Step 3) when the user wants

ship

to gate on a plan review before implementing.

根据自由格式描述创建Linear工单。

本skill是

ship

skill的上游配套工具：它创建的工单是

ship

skill获取并端到端实现的输入。生成工单时需确保其能作为

ship

的优质输入——清晰的范围、明确的验收标准，以及当用户希望

ship

在实现前先进行方案审核时添加的方案审批标记（见步骤3）。

Required tools

所需工具

Linear MCP — to list workspace metadata (teams, projects, labels, statuses) and create the issue. If unreachable, ask the user to reconnect.

Linear MCP —— 用于列出工作区元数据（团队、项目、标签、状态）并创建工单。若无法访问，请要求用户重新连接。

Workflow

工作流程

Read the description. If too thin to form a useful ticket (no problem statement, no scope), ask one short clarifying question. Otherwise proceed.
Probe the workspace via the Linear MCP:
- Pick the team that matches the current project directory — list teams and choose the one whose name / key / linked GitHub repo corresponds to the repo the skill is running in. If the match is ambiguous, ask the user once and remember it.
- List that team's projects and labels.
- Pre-select the project tied to the current repo if obvious.
Draft the ticket:
- Title — short, imperative, no trailing period (e.g. "Fix double-tap heart on profile grid").
- Description — markdown using this template (omit sections that don't apply):
  md
```
## Context

<why this matters / where it shows up>

## Current behavior

<what happens today, if it's a bug>

## Desired behavior

<what should happen>

## Acceptance criteria

- [ ] ...

## Notes

<links, edge cases, code snippets in fenced blocks>
```
- Labels — pick from existing labels only. Don't invent.
- Priority — infer from language ("urgent", "blocker" → High; "nice to have" → Low). Default Medium.
- Assignee — leave unassigned unless the user named one.
- Plan-approval marker — if the user says implementation should require plan approval before code is written, append a clear line to the description:
```
**Plan first: please post a plan and wait for approval before implementing.**
```
  The
```
ship
```
  skill scans the ticket for wording like this to decide whether to gate on a plan review.
Show the draft in chat with title, body, team, project, labels, priority. Wait for explicit approval. Edit and re-show on requested changes.
Create the issue via the Linear MCP. Then post the user's original request verbatim as the first comment on the new ticket — this preserves what the user asked for in their own words, separate from the polished description. Don't paraphrase, summarize, or trim it; copy the request exactly as the user wrote it (in a fenced quote block if it contains markdown that would render oddly). Report back the issue ID and URL.

读取描述：如果描述过于简略无法生成有用的工单（无问题说明、无范围），提出一个简短的澄清问题。否则继续下一步。
通过Linear MCP探测工作区：
- 选择与当前项目目录匹配的团队 —— 列出所有团队，选择名称/标识/关联GitHub仓库与skill运行所在仓库相符的团队。若匹配结果不明确，询问用户一次并记住该选择。
- 列出该团队的项目和标签。
- 若明显可辨，预先选择与当前仓库关联的项目。
生成工单草稿：
- 标题 —— 简短、祈使语气，末尾无句号（例如：“修复个人资料网格上的双击点赞问题”）。
- 描述 —— 使用以下markdown模板（省略不适用的部分）：
  md
```
## 背景

<说明重要性/出现场景>

## 当前行为

<如果是bug，描述当前发生的情况>

## 期望行为

<应该实现的效果>

## 验收标准

- [ ] ...

## 备注

<链接、边缘情况、代码片段请放在围栏代码块中>
```
- 标签 —— 仅从现有标签中选择，不得自行创建。
- 优先级 —— 根据语言推断（“紧急”“阻塞”→高优先级；“锦上添花”→低优先级）。默认中等优先级。
- 经办人 —— 除非用户指定，否则留空不分配。
- 方案审批标记 —— 如果用户要求在编写代码前需先审批方案，在描述末尾添加明确一行：
```
**先做方案：请提交方案并等待审批后再开始实现。**
```
```
ship
```
  skill会扫描工单中的此类表述，以决定是否需要在方案审核通过后再推进。
展示草稿：在聊天中展示工单标题、内容、团队、项目、标签、优先级。等待用户明确审批。根据用户要求修改后重新展示。
创建工单：通过Linear MCP创建工单。然后将用户的原始请求原文作为新工单的第一条评论发布——这样可以保留用户自己表述的需求，与优化后的描述区分开。不得改写、总结或删减；完全复制用户的原始请求（如果包含可能异常渲染的markdown，请放在围栏引用块中）。向用户反馈工单ID和链接。

Rules

规则

No AI attribution in the body.
Labels and priorities must already exist in the workspace.
File paths, errors, and stack traces go verbatim in
```
## Notes
```
inside fenced code blocks.
If the description names a parent or duplicate, set the relation on creation.

内容中不得提及AI相关归属信息。
标签和优先级必须是工作区中已存在的。
文件路径、错误信息和堆栈跟踪需原样放在
```
## 备注
```
的围栏代码块中。
如果描述中提到父工单或重复工单，创建时需设置关联关系。