kata-linear

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Linear Ticket Lifecycle

Linear工单生命周期

This skill wraps the general

/linear

skill with structured start/next/end workflows. Always invoke

/linear

for the actual MCP calls.

该Skill在通用

/linear

Skill的基础上，封装了结构化的开始/后续/结束工作流。实际MCP调用请始终通过

/linear

触发。

Determining the Mode

模式判定

Parse the user's request to determine which workflow to run:

User says	Mode
"start KAT-N", "pick up KAT-N", "implement KAT-N", "work on KAT-N"	Start
"finish KAT-N", "complete KAT-N", "done with KAT-N", "close KAT-N"	End
"what's next", "what should I work on", "next ticket", "next issue"	Next

If ambiguous, ask.

解析用户请求以确定要执行的工作流：

用户指令	模式
"start KAT-N"、"pick up KAT-N"、"implement KAT-N"、"work on KAT-N"	开始
"finish KAT-N"、"complete KAT-N"、"done with KAT-N"、"close KAT-N"	结束
"what's next"、"what should I work on"、"next ticket"、"next issue"	后续

若指令模糊，请询问用户确认。

Identifying the Project

项目识别

Check the current working directory's CLAUDE.md for a Linear project reference.
If not found, call
```
list_projects
```
and ask the user which project to use.
Cache the project name for the remainder of the session.

检查当前工作目录下的CLAUDE.md文件，查找Linear项目引用。
若未找到，调用
```
list_projects
```
接口并询问用户要使用哪个项目。
缓存项目名称，用于本次会话的后续操作。

Mode: Next

模式：后续

Find the next actionable issue.

Query
```
list_issues
```
for the project with state
```
Todo
```
.
If results exist, present them. The first
```
Todo
```
issue is the recommended next pick.
If no
```
Todo
```
issues, resolve from blocking relations: a. Query
```
list_issues
```
for the project with state
```
Backlog
```
. b. For each Backlog issue, call
```
get_issue
```
with
```
includeRelations: true
```
. c. Find issues whose
```
blockedBy
```
entries are all
```
Done
```
(or have no blockers). d. Present unblocked issues as candidates.
If the project has Linear documents (execution model, workflow contract), fetch them with
```
list_documents
```
and
```
get_document
```
to understand pillar/phase ordering.

查找下一个可处理的工单。

调用
```
list_issues
```
接口，查询项目中状态为
```
Todo
```
的工单。
若存在结果，展示给用户。首个
```
Todo
```
工单为推荐的后续处理项。
若无
```
Todo
```
工单，则从阻塞关系中查找： a. 调用
```
list_issues
```
接口，查询项目中状态为
```
Backlog
```
的工单。 b. 针对每个Backlog工单，调用
```
get_issue
```
接口并设置
```
includeRelations: true
```
。 c. 找出所有
```
blockedBy
```
条目均为
```
Done
```
状态（或无阻塞项）的工单。 d. 将无阻塞的工单作为候选项展示给用户。
若项目包含Linear文档（执行模型、工作流契约），调用
```
list_documents
```
和
```
get_document
```
接口获取文档，以了解支柱/阶段顺序。

Mode: Start

模式：开始

Step 1 — Validate the issue

步骤1 — 工单验证

Call
```
get_issue
```
for the requested issue with
```
includeRelations: true
```
.
Check every entry in
```
blockedBy
```
. For each blocker, confirm its status is
```
Done
```
.
If any blocker is not
```
Done
```
, stop and report which blockers remain open.

调用
```
get_issue
```
接口获取目标工单信息，设置
```
includeRelations: true
```
。
检查
```
blockedBy
```
中的每个条目，确认每个阻塞项的状态均为
```
Done
```
。
若存在未完成的阻塞项，终止流程并告知用户剩余的未完成阻塞项。

Step 2 — Move to In Progress

步骤2 — 标记为进行中

Call
```
update_issue
```
to set state to
```
In Progress
```
.

调用
```
update_issue
```
接口将工单状态设置为
```
In Progress
```
。

Step 3 — Load context

步骤3 — 加载上下文

Read the issue description for references to specs, mocks, docs, or design files.
Check the project's CLAUDE.md for pointers to spec/mock/design directories.
Read relevant spec files, mock images, or design references found in steps 1 and 2.
Check existing source code in the areas the issue will touch.

读取工单描述，查找对规格说明、原型、文档或设计文件的引用。
检查项目的CLAUDE.md文件，查找规格/原型/设计目录的指向。
读取步骤1和2中找到的相关规格文件、原型图或设计参考。
查看工单涉及代码区域的现有源代码。

Step 4 — Create feature branch

步骤4 — 创建功能分支

Use the
```
gitBranchName
```
field from the issue response as the branch name.
Create the branch from the main branch.

使用工单返回结果中的
```
gitBranchName
```
字段作为分支名称。
基于主分支创建该功能分支。

Step 5 — Summarize

步骤5 — 总结

Present to the user:

Issue title and acceptance criteria
Blocker status (all clear)
Context loaded (specs, mocks, relevant code)
Branch name created
Any project-specific workflow reminders from CLAUDE.md (e.g., TDD mandate)

向用户展示以下内容：

工单标题与验收标准
阻塞项状态（全部已清除）
已加载的上下文（规格、原型、相关代码）
创建的分支名称
来自CLAUDE.md的项目特定工作流提醒（如TDD要求）

Mode: End

模式：结束

Step 1 — Gather evidence

步骤1 — 收集证据

Ask the user to confirm or provide:

PR link or branch with changes
Test results (unit and/or E2E)
Screenshots or spec-state references demonstrating acceptance criteria

If a PR already exists on the current branch, detect it with

gh pr view

请用户确认或提供以下内容：

变更对应的PR链接或分支
测试结果（单元测试和/或端到端测试）
验证验收标准的截图或规格状态引用

若当前分支已存在PR，可通过

gh pr view

检测。

Step 2 — Validate completion gate

步骤2 — 验证完成校验

Check if the project's CLAUDE.md or Linear workflow contract defines a hard gate. Common gates:

Referenced spec states/interactions are verified
Evidence links are attached (tests, screenshots, or traceable PR notes)
Gap analysis items are either closed or split into follow-up issues

If evidence is insufficient, list what's missing and stop.

检查项目的CLAUDE.md或Linear工作流契约是否定义了强制校验规则。常见校验规则：

已验证引用的规格状态/交互
已附加证据链接（测试、截图或可追溯的PR说明）
差距分析项已关闭或拆分为后续工单

若证据不足，列出缺失项并终止流程。

Step 3 — Attach evidence to the issue

步骤3 — 为工单附加证据

Call

create_comment

on the issue with a structured evidence summary:

## Completion Evidence
- PR: [link]
- Tests: [pass/fail summary]
- Acceptance coverage: [which criteria verified]
- Screenshots: [if applicable]

调用

create_comment

接口为工单添加结构化的证据总结：

## 完成证据
- PR: [链接]
- 测试: [通过/失败总结]
- 验收覆盖: [已验证的验收标准]
- 截图: [如有提供]

Step 4 — Move to Done

步骤4 — 标记为已完成

Call
```
update_issue
```
to set state to
```
Done
```
.

调用
```
update_issue
```
接口将工单状态设置为
```
Done
```
。

Step 5 — Promote next in chain

步骤5 — 推进链式工单

Call
```
get_issue
```
with
```
includeRelations: true
```
on the completed issue.
For each issue in the
```
blocks
```
list: a. Call
```
get_issue
```
with
```
includeRelations: true
```
on that downstream issue. b. Check if ALL of its
```
blockedBy
```
entries are now
```
Done
```
. c. If yes, call
```
update_issue
```
to move it to
```
Todo
```
. d. Report which issue was promoted.

调用
```
get_issue
```
接口获取已完成工单的信息，设置
```
includeRelations: true
```
。
针对
```
blocks
```
列表中的每个工单： a. 调用
```
get_issue
```
接口获取下游工单信息，设置
```
includeRelations: true
```
。 b. 检查其所有
```
blockedBy
```
条目是否均已变为
```
Done
```
状态。 c. 若是，调用
```
update_issue
```
接口将其状态改为
```
Todo
```
。 d. 告知用户哪个工单已被推进。

Step 6 — Summarize

步骤6 — 总结

Present:

Issue marked Done with evidence link
Which downstream issue(s) were promoted to Todo
Suggested next action

向用户展示：

已标记为Done的工单及证据链接
哪些下游工单已被推进至Todo状态
建议的下一步操作