Back to Details

yistc-linear-issue

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workflow for working on a Linear issue

处理Linear问题的工作流

Scope

适用范围

Use this workflow only when you are explicitly assigned a Linear issue, with an issue ID like 
L-114
.
仅当你被明确分配了带有
L-114
这类问题ID的Linear问题时，才使用此工作流。

Guidelines

指导原则

Behavioral rules

行为规则

  • Do NOT change issue status unless explicitly required by a workflow step or requested by the user.
  • Do NOT run local test, lint, build, or typecheck unless explicitly requested by the user.
  • Always keep Linear updated with meaningful progress, especially after fixing CI failures or when the PR becomes ready to merge.
  • 除非工作流步骤明确要求或用户提出请求，否则不要更改问题状态。
  • 除非用户明确要求，否则不要运行本地测试、代码检查、构建或类型校验。
  • 始终在Linear中更新有意义的进展，尤其是在修复CI失败后或PR准备好合并时。

Linear MCP References

Linear MCP参考

  • Get Issue - get_issue (MCP)(id: "L-115")
  • List Comments - list_comments (MCP)(issueId: "L-115")
  • Create Comment: save_comment (MCP)(issueId: "L-115", body: "<comment body>")
  • Update commentt: save_comment (MCP)(id: "<comment_id>", issueId: "L-115", body: "<comment body>")
  • Delete comment: delete_comment (MCP)(id: "<comment_id>")
  • 获取问题 - get_issue (MCP)(id: "L-115")
  • 列出评论 - list_comments (MCP)(issueId: "L-115")
  • 创建评论：save_comment (MCP)(issueId: "L-115", body: "<评论内容>")
  • 更新评论：save_comment (MCP)(id: "<评论ID>", issueId: "L-115", body: "<评论内容>")
  • 删除评论：delete_comment (MCP)(id: "<评论ID>")

Description

说明

You will be assigned an issue with issue ID such as 'L-114'. You need to strictly follow the steps listed below. You may consider each step as a task.
你会被分配带有
L-114
这类问题ID的任务。 你需要严格遵循以下列出的步骤，可以将每个步骤视为一项任务。

Goal

目标

Complete the issue by:
  1. updating the Linear issue
  2. creating a dedicated git worktree and branch
  3. planning before implementation
  4. making the code changes
  5. opening a GitHub PR linked to the Linear issue
  6. relying on GitHub Actions for default validation unless the user explicitly requests local validation
通过以下步骤完成问题：
  1. 更新Linear问题
  2. 创建专用的git工作区和分支
  3. 实现前进行规划
  4. 进行代码变更
  5. 打开关联Linear问题的GitHub PR
  6. 除非用户明确要求本地验证，否则依赖GitHub Actions进行默认验证

Phase 1: Implementation

第一阶段：实现

Step 1: Read and understand the issue

步骤1：阅读并理解问题

Before making changes:
  • Read the issue title, description, comments, and any linked context.
  • Identify the expected outcome, constraints, and acceptance criteria.
  • If the issue is ambiguous, state the ambiguity clearly in a Linear comment before proceeding.
  • Do not start coding until the scope is understood well enough to produce a concrete plan.
在进行变更前：
  • 阅读问题标题、描述、评论以及所有关联上下文。
  • 明确预期结果、约束条件和验收标准。
  • 如果问题存在歧义，在继续之前先在Linear中添加评论明确说明歧义点。
  • 在充分理解范围并能制定具体计划前，不要开始编码。

Step 2: Update the Linear issue

步骤2：更新Linear问题

When starting work:
  • Change the issue status to 
    In Progress
    .
  • Add a comment that:
    • you have started working on it,
    • you are creating a branch/worktree,
    • you will follow up with implementation progress and a PR link.
开始工作时：
  • 将问题状态更改为
    In Progress
    （进行中）。
  • 添加一条评论，内容包括：
    • 你已开始处理该问题，
    • 正在创建分支/工作区，
    • 后续会跟进实现进展和PR链接。

Step 3: Create a git worktree and branch

步骤3：创建git工作区和分支

Create a dedicated worktree under:
~/Developer/worktrees/<repo>/<branch>
Branch rules:
  • Base the branch on 
    dev
    .
  • Branch name should follow this format:
linear/<issue-id>-<short-slug>
Example:
linear/L-114-fix-login-timeout
Behavior:
  • If the branch does not exist, create it from 
    dev
    .
  • If the branch already exists locally, reuse it.
  • Move into the worktree directory before making changes.
在以下路径下创建专用工作区：
~/Developer/worktrees/<repo>/<branch>
分支规则：
  • 基于
    dev
    分支创建。
  • 分支名称需遵循以下格式：
linear/<issue-id>-<short-slug>
示例：
linear/L-114-fix-login-timeout
行为要求：
  • 如果分支不存在，从
    dev
    分支创建。
  • 如果分支已在本地存在，直接复用。
  • 在进行变更前切换到工作区目录。

Step 4: Plan before implementation

步骤4：实现前规划

Before editing code:
  • Summarize the issue in your own words.
  • Write an implementation plan.
  • Identify the files or modules likely to be affected.
  • Consider edge cases, risks, and whether tests need to be added or updated.
在编辑代码前：
  • 用自己的话总结问题。
  • 编写实现计划。
  • 确定可能受影响的文件或模块。
  • 考虑边缘情况、风险，以及是否需要添加或更新测试。

Step 5: Implement the change

步骤5：实现变更

  • Make the smallest set of code changes necessary to solve the issue.
  • Follow the repository’s existing conventions and patterns.
  • Avoid unrelated refactors unless they are required to complete the issue safely.
  • If you discover the issue is larger than expected, leave a Linear comment describing the new scope before continuing too far.
  • 仅进行解决问题所需的最小代码变更。
  • 遵循仓库现有的约定和模式。
  • 除非为安全完成问题所必需，否则避免无关的重构。
  • 如果发现问题范围比预期更大，在深入推进前先在Linear中添加评论说明新的范围。

Step 6: Prepare for PR

步骤6：准备PR

Before opening a PR:
  • Review the diff for correctness and unnecessary changes.
  • Do NOT run test, lint, build, or typecheck
  • Prefer to rely on the repository’s GitHub Actions / CI to perform full validation after the PR is opened.
在打开PR前：
  • 检查代码差异，确保正确性并移除不必要的变更。
  • 不要运行测试、代码检查、构建或类型校验
  • 优先依赖仓库的GitHub Actions/CI在PR打开后执行完整验证。

Step 7: Commit and open a PR

步骤7：提交并打开PR

Create a commit and open a PR with GitHub CLI.
PR requirements:
  • Push the branch to origin.
  • PR title should clearly describe the change.
  • PR should merge to 
    dev
    branch.
  • The first line of the PR description must be:
closes <issue_id>
Example:
closes L-114
After the first line:
  • explain the problem,
  • describe the implementation,
  • summarize validation performed,
  • explicitly note that full validation is expected to run in GitHub Actions / CI,
  • mention any known limitations or follow-up work.
使用GitHub CLI创建提交并打开PR。
PR要求：
  • 将分支推送到origin。
  • PR标题需清晰描述变更内容。
  • PR需合并到
    dev
    分支。
  • PR描述的第一行必须为：
closes <issue_id>
示例：
closes L-114
在第一行之后：
  • 说明问题所在，
  • 描述实现方式，
  • 总结已执行的验证，
  • 明确说明PR打开后GitHub Actions/CI会执行完整验证，
  • 提及任何已知限制或后续工作。

Phase 2: PR Follow-up

第二阶段：PR跟进

Step 8: Check GitHub Actions results only when explicitly requested

步骤8：仅在明确要求时检查GitHub Actions结果

Only perform this step when explicitly notified by the user.
When asked to check PR status or validation results: • inspect the GitHub PR checks / GitHub Actions results, • summarize which checks passed, failed, or are still running, • if a check failed, identify the relevant error clearly, • make only the changes necessary to address the failure, • update the branch and push additional commits, • summarize what was fixed.
Do not proactively wait for CI, poll for results, or repeatedly re-check the PR unless the user explicitly asks.
  • After making fixes and pushing updates, add a comment to the Linear issue summarizing:
    • what failed,
    • what was fixed,
    • that CI has been re-run and is expected to validate the changes.
仅当用户明确通知时才执行此步骤。
当被要求检查PR状态或验证结果时： • 查看GitHub PR检查/GitHub Actions结果， • 总结哪些检查通过、失败或仍在运行， • 如果检查失败，清晰指出相关错误， • 仅进行解决失败所需的变更， • 更新分支并推送额外提交， • 总结修复内容。 除非用户明确要求，否则不要主动等待CI完成、轮询结果或反复检查PR。
  • 在修复并推送更新后，在Linear中添加评论总结：
    • 失败内容，
    • 修复内容，
    • 已重新运行CI，预计会验证变更。

Step 9: Update Linear with PR and follow-up status

步骤9：在Linear中更新PR及跟进状态

After opening a PR OR after any significant PR update (e.g. CI failure fix, CI passing, PR ready):
Add a comment to the Linear issue containing:
  • a short summary of what changed,
  • current PR status (e.g. CI failed, CI passed, ready to merge),
  • whether validation is handled or completed by GitHub Actions / CI,
  • any remaining caveats.
Linear Statue: change to 'In Review'
在打开PR后或PR有重大更新后（例如修复CI失败、CI通过、PR准备好合并）：
在Linear中添加评论，内容包括：
  • 变更内容的简短总结，
  • 当前PR状态（例如CI失败、CI通过、准备合并），
  • 验证是否由GitHub Actions/CI处理或已完成，
  • 任何剩余注意事项。
Linear状态：更改为
In Review
（审核中）

Failure or blocker handling

失败或阻塞处理

If you are blocked, add a Linear comment explaining:
  • what blocked you
  • what you tried
  • what is needed to proceed
If you cannot complete the issue safely, do not pretend it is done
如果遇到阻塞，在Linear中添加评论说明：
  • 阻塞原因，
  • 已尝试的解决方法，
  • 继续推进所需的条件。
如果无法安全完成问题，不要假装已完成。

Cleanup

清理

Only perform cleanup when explicitly requested by the user
Before performing cleanup:
  • Do NOT assume the PR is merged or CI has passed.
  • If PR status or CI results are relevant, only use information that has been explicitly checked or provided by the user.
Cleanup may include:
  • removing the git worktree
  • deleting the local branch
  • posting a final Linear comment summarizing:
    • the problem
    • the plan
    • the result
    • the PR status or merge status
仅在用户明确要求时执行清理操作
执行清理前：
  • 不要假设PR已合并或CI已通过。
  • 如果PR状态或CI结果相关，仅使用已明确检查或用户提供的信息。
清理操作可能包括：
  • 删除git工作区
  • 删除本地分支
  • 在Linear中发布最终评论总结：
    • 问题内容，
    • 计划，
    • 结果，
    • PR状态或合并状态