Back to Details

linear-issue-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Linear Issue Workflow

Linear 需求单工作流

Use this skill when implementing features or fixes tracked in Linear.
当你需要实现Linear中跟踪的功能或修复问题时，可以使用本技能。

Phase 1: Understand the Issue

阶段1：理解需求单

Fetch the Linear issue using the 
linear
subagent:
Task(subagent_type="linear", prompt="Fetch issue <ISSUE-ID> including title, description, status, and acceptance criteria")
Ask the user clarifying questions if the scope is unclear before proceeding.
使用
linear
子代理获取Linear需求单：
Task(subagent_type="linear", prompt="Fetch issue <ISSUE-ID> including title, description, status, and acceptance criteria")
在开始前，如果需求范围不明确，请向用户询问澄清问题。

Phase 2: Explore and Plan

阶段2：探索与规划

  1. Use the 
    explore
    subagent to understand the codebase:
    • Where changes need to be made
    • Existing patterns to follow
    • Related code that might be affected
  2. Create an implementation plan covering:
    • Files to modify
    • New functions/types to add
    • Tests to write
  3. Present the plan to the user and ask if they would like any changes before proceeding. Do not start implementation until the user approves the plan.
  4. Optionally attach the plan to the Linear issue:
    Task(subagent_type="linear", prompt="Attach this implementation plan as a document to <ISSUE-ID>: <plan>")
  5. Mark the issue as "In Progress":
    Task(subagent_type="linear", prompt="Update issue <ISSUE-ID> status to In Progress")
  1. 使用
    explore
    子代理了解代码库：
    • 需要修改的位置
    • 需遵循的现有代码模式
    • 可能受影响的相关代码
  2. 创建实现计划，涵盖：
    • 要修改的文件
    • 要新增的函数/类型
    • 要编写的测试用例
  3. 将计划提交给用户，询问是否需要修改。在用户批准计划前，不要开始实现。
  4. （可选）将计划附加到Linear需求单中：
    Task(subagent_type="linear", prompt="Attach this implementation plan as a document to <ISSUE-ID>: <plan>")
  5. 将需求单状态标记为"进行中"：
    Task(subagent_type="linear", prompt="Update issue <ISSUE-ID> status to In Progress")

Phase 3: Set Up Worktree

阶段3：设置工作树

Get the branch name from Linear:
Task(subagent_type="linear", prompt="Get the git branch name for issue <ISSUE-ID>")
Determine the repository's default branch:
bash
git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
Fetch the latest changes and create a worktree based on the remote default branch:
bash
git fetch origin
git worktree add ../worktree/<branch-name> -b <branch-name> origin/<default-branch>
Important: Always base new branches on 
origin/<default-branch>
(where 
<default-branch>
is 
main
, 
master
, or whatever the repository uses). This ensures your branch starts from the latest remote state, even if your local default branch is out of date.
After creating the worktree:
bash
cd ../worktree/<branch-name>
Then install local dependencies (look at developer documentation for how to do this).
Worktrees share the 
.git
directory but have their own working directory. The 
node_modules
directory is NOT shared, so each worktree needs its own dependency installation.
All subsequent work happens in the worktree directory.
从Linear获取分支名称：
Task(subagent_type="linear", prompt="Get the git branch name for issue <ISSUE-ID>")
确定仓库的默认分支：
bash
git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
获取最新变更并基于远程默认分支创建工作树：
bash
git fetch origin
git worktree add ../worktree/<branch-name> -b <branch-name> origin/<default-branch>
重要提示：始终基于
origin/<default-branch>
创建新分支（
<default-branch>
可以是
main
、
master
或仓库使用的其他默认分支）。这样可以确保你的分支从最新的远程状态开始，即使本地默认分支已过时。
创建工作树后：
bash
cd ../worktree/<branch-name>
然后安装本地依赖（请参考开发者文档了解具体安装方式）。
工作树共享
.git
目录，但有自己的工作目录。
node_modules
目录不会共享，因此每个工作树都需要单独安装依赖。
所有后续工作都在工作树目录中进行。

Phase 4: Implement

阶段4：实现

  1. Use 
    TodoWrite
    to track implementation tasks
  2. Implement changes, marking todos as complete as you go
  3. Write tests for new functionality
  4. Run the project's build/verification command
  1. 使用
    TodoWrite
    跟踪实现任务
  2. 进行代码变更，完成任务后标记为已完成
  3. 为新功能编写测试用例
  4. 运行项目的构建/验证命令

Phase 5: Verify

阶段5：验证

If the changes affect critical paths or integration points, run the project's test suite or integration tests as appropriate for the changes made.
如果变更影响关键路径或集成点，请根据变更内容运行项目的测试套件或集成测试。

Phase 6: Commit and PR

阶段6：提交与创建PR

Squash commits if needed

（可选）压缩提交

If you made multiple commits that should be one:
bash
git reset --soft HEAD~<n> && git commit -m "<message>"
如果你进行了多个可合并为一个的提交：
bash
git reset --soft HEAD~<n> && git commit -m "<message>"

Self-review

自审

Before pushing, load the 
code-review
skill and perform a self-review of your changes. If serious issues are found that would prohibit merging, fix them before proceeding. Do not push until the review passes.
After the review passes, ask the user for confirmation before pushing and creating the PR.
推送前，加载
code-review
技能并对自己的变更进行自审。如果发现会阻止合并的严重问题，先修复再继续。在审核通过前不要推送。
审核通过后，在推送和创建PR前请向用户确认。

Post review to PR

将审核结果发布到PR

After creating the PR, post a summary of the code review as a comment:
bash
gh pr comment <PR-NUMBER> --body "$(cat <<'EOF'
创建PR后，将代码审核摘要作为评论发布：
bash
gh pr comment <PR-NUMBER> --body "$(cat <<'EOF'

Self-Review Summary

自审摘要

<summary of what was reviewed and any issues found/fixed>
<审核内容总结及发现/修复的问题>

Files Reviewed

已审核文件

  • path/to/file.ts
    : <brief assessment>
  • path/to/file.ts
    : <简要评估>

Issues Found and Resolved

发现并解决的问题

<list any issues found during self-review and how they were fixed, or "None"> EOF )"
undefined
<列出自审中发现的问题及解决方式，若无则写"无"> EOF )"
undefined

Push and create PR

推送并创建PR

Fetch the latest changes and rebase before pushing:
bash
git fetch origin
git rebase origin/<default-branch>
Verify the build still passes after rebasing, then push:
bash
git push -u origin <branch-name>
Create the PR:
bash
gh pr create \
  --title "<title>" \
  --reviewer <REVIEWER> \
  --body "$(cat <<'EOF'
获取最新变更并在推送前变基：
bash
git fetch origin
git rebase origin/<default-branch>
变基后验证构建是否仍能通过，然后推送：
bash
git push -u origin <branch-name>
创建PR：
bash
gh pr create \
  --title "<title>" \
  --reviewer <REVIEWER> \
  --body "$(cat <<'EOF'

Summary

摘要

<1-3 bullet points>
<1-3个要点>

Changes

变更内容

  • path/to/file.ts
    : <what changed>
  • path/to/file.ts
    : <变更说明>

Testing

测试情况

<how it was tested>
Closes <ISSUE-ID> EOF )"
undefined
<测试方式>
Closes <ISSUE-ID> EOF )"
undefined

Phase 7: Cleanup After Merge

阶段7：合并后的清理

After the PR has been merged, clean up the worktree and local branch:
bash
undefined
PR合并后，清理工作树和本地分支：
bash
undefined

From the main repository directory (not the worktree)

从主仓库目录（非工作树目录）执行

git fetch origin git worktree remove ../worktree/<branch-name> git branch -d <branch-name>

If the worktree directory was already manually deleted, prune stale worktree references:

```bash
git worktree prune
git fetch origin git worktree remove ../worktree/<branch-name> git branch -d <branch-name>

如果工作树目录已被手动删除，请清理过期的工作树引用：

```bash
git worktree prune

Linear Subagent Patterns

Linear子代理使用模式

Common operations:
ActionPrompt
Fetch issue
Fetch issue <ISSUE-ID> with full details
Get branch name
Get the git branch name for issue <ISSUE-ID>
Update status
Update issue <ISSUE-ID> status to In Progress
Attach document
Attach this as a document titled "X" to <ISSUE-ID>: <content>
Add comment
Add a comment to <ISSUE-ID>: <comment>
Always use 
subagent_type="linear"
when calling the Task tool for Linear operations.
常见操作：
操作提示语
获取需求单
Fetch issue <ISSUE-ID> with full details
获取分支名称
Get the git branch name for issue <ISSUE-ID>
更新状态
Update issue <ISSUE-ID> status to In Progress
附加文档
Attach this as a document titled "X" to <ISSUE-ID>: <content>
添加评论
Add a comment to <ISSUE-ID>: <comment>
使用Task工具执行Linear操作时，始终指定
subagent_type="linear"
。