fix-linear-ticket

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix Linear Ticket

修复Linear工单

Flags

参数

Flag / Arg	Effect
`<ticket-id>`	Linear ticket identifier (e.g. `ENG-123` ). Extracted from the message.
`--base <branch>`	Base branch to branch from. Default: `main` .

If no ticket ID is found, stop and ask: "Which Linear ticket should I fix? Please provide the ticket ID."

参数/参数值	作用
`<ticket-id>`	Linear工单标识符（例如： `ENG-123` ），从消息中提取。
`--base <branch>`	用于创建分支的基准分支。默认值： `main` 。

如果未找到工单ID，则停止操作并询问：“我应该修复哪个Linear工单？请提供工单ID。”

Step 1: Fetch ticket details

步骤1：获取工单详情

Use Linear MCP tools to fetch the full record: title, description, comments, attachments, linked issues, labels, state, priority. Never infer ticket content from the ID alone. If Linear MCP is unavailable, the ticket is not found, or the API errors, stop and report.

使用Linear MCP工具获取完整工单记录：标题、描述、评论、附件、关联问题、标签、状态、优先级。切勿仅通过工单ID推断工单内容。若Linear MCP不可用、未找到工单或API出错，则停止操作并上报问题。

Step 2: Derive the branch name

步骤2：生成分支名称

Convention:

pd/<type>/<ticket-id>-<slug>

```
<type>
```
:
```
fix
```
(bug/defect),
```
feat
```
(feature/enhancement),
```
chore
```
(maintenance/tooling),
```
docs
```
(documentation). Default
```
fix
```
when unclear.
```
<ticket-id>
```
: lowercase.
```
<slug>
```
: kebab-case from the title, 4-5 words max.

Example: ENG-123 "Fix auth redirect loop" →

pd/fix/eng-123-fix-auth-redirect-loop

If the name cannot be constructed, stop and ask the user for one.

命名规则：

pd/<类型>/<工单ID>-<短标题>

。

```
<类型>
```
：
```
fix
```
（bug/缺陷）、
```
feat
```
（功能/增强）、
```
chore
```
（维护/工具）、
```
docs
```
（文档）。若类型不明确，默认使用
```
fix
```
。
```
<工单ID>
```
：小写形式。
```
<短标题>
```
：由工单标题转换为短横线分隔格式（kebab-case），最多4-5个单词。

示例：ENG-123 “修复认证重定向循环” →

pd/fix/eng-123-fix-auth-redirect-loop

。

若无法生成分支名称，则停止操作并询问用户提供名称。

Step 3: Create the branch off base

步骤3：基于基准分支创建新分支

bash

git fetch origin <base-branch>
git checkout <base-branch>
git reset --hard origin/<base-branch>
git checkout -b <derived-branch-name>

Report the branch created.

bash

git fetch origin <base-branch>
git checkout <base-branch>
git reset --hard origin/<base-branch>
git checkout -b <derived-branch-name>

上报已创建的分支。

Step 4: Plan the fix

步骤4：制定修复方案

Search the codebase for files related to the ticket, function/component/module names from the description, and the bug area or feature surface. Read them to understand the current implementation. Then outline: files to change, the change per file, dependencies/ordering, and risks or edge cases. See

./REFERENCE.md

for the full search strategy.

Present the plan, then wait for explicit user confirmation before writing any code.

在代码库中搜索与工单相关的文件、描述中提到的函数/组件/模块名称，以及bug所在区域或功能面。阅读这些文件以理解当前实现。然后列出：需要修改的文件、每个文件的修改内容、依赖关系/执行顺序，以及风险或边缘情况。完整搜索策略请参考

./REFERENCE.md

。

展示修复方案，然后等待用户明确确认后再编写任何代码。

Step 5: Implement the fix

步骤5：实施修复

Apply the approved changes only. Keep changes focused and minimal, and do not touch unrelated code.

仅执行已批准的修改。保持修改集中且最小化，请勿触碰无关代码。

Step 6: Review

步骤6：审核

Re-read every changed file and check it against the four review checks in

./REFERENCE.md

: ticket requirements met, no regressions, edge cases covered, style consistent with surrounding code.

Report: what was implemented, how it addresses the ticket, any regressions or edge cases, and follow-up work.

重新阅读所有已修改的文件，并对照

./REFERENCE.md

中的四项审核标准检查：是否满足工单需求、是否存在回归问题、是否覆盖边缘情况、代码风格是否与周边代码一致。

上报：已实现的内容、如何解决工单问题、是否存在回归或边缘情况，以及后续工作。

Constraints

约束条件

Never commit, build, run tests, or push. Do none of these unless the user asks outside this skill.
Never infer ticket content. Always fetch from Linear.
If the ticket or branch name cannot be found, stop and ask.

切勿提交、构建、运行测试或推送代码。除非用户在本技能之外提出要求，否则不执行这些操作。
切勿推断工单内容。始终从Linear获取工单信息。
若无法找到工单或分支名称，则停止操作并询问用户。