linear

Linear 问题管理

使用 Linear 工作流前，请先发现可用的 Linear 工具，包括延迟加载的工具，并检查它们当前的架构。应根据能力选择工具（问题查询、图片、子问题、创建/更新、评论），而不是依赖固定的 MCP 前缀或历史工具名称。只有在完成发现后，才能报告缺少某项能力。

工作流

1. 开始前，使用问题查询能力获取问题详情。
2. 查看图片——问题描述中通常包含截图，其中有重要背景信息（设计稿、错误状态、前后对比）。使用可用的图片提取或查看能力；仅阅读原始 Markdown 会遗漏报告者所看到的内容。
3. 使用可用的父级筛选条件或问题关系字段检查子问题。
4. 开始规划或实施时，立即将状态标记为进行中——这会告知团队该问题已有负责人，避免其他人重复处理。
5. 进入下一个问题前，遵循逐问题完成规范。

创建问题

创建问题时，请添加 claude code 标签。原因：团队通过此标签筛选/审计 AI 生成的问题；如果没有该标签，这些问题就会淹没在普通待办列表中，团队也会无法了解 AI 贡献情况。

除非用户明确指定其他经办人，或要求问题保持未分配状态，否则请传入 assignee: "me"，将问题分配给已认证的 Linear 用户。始终优先遵循用户明确指定的分配要求，而非此默认设置。

语言

问题所用语言应与产生该问题的对话一致——如果讨论使用中文，就用中文撰写问题；如果讨论使用英语，就用英语撰写。原因：问题是对话的延续，强行切换语言会给发起该讨论的协作者造成翻译负担。

具体要求：

• 中文对话 → 中文正文；技术术语（文件路径、标识符、库名称、命令、错误消息）保留英文。
• 英语对话 → 英语正文。
• 无论周围使用何种语言，代码块、文件路径和引用的字符串始终保留原样。
• 这同样适用于更新——编辑现有问题时（包括描述**和标题），保留触发此次编辑的对话所用语言；不要在重构过程中途切换问题语言。

创建子问题树

将父问题拆分为子问题树时（例如，为 LOBE-xxx 分解任务），请遵循以下规范，并检查可用的工具能力。

1. 在标题前加上排序索引

Linear 支持对子问题排序，但工具支持情况各不相同。请检查已发现的创建/更新架构中是否有排序字段，不要假定某个 MCP 工具一定提供此类字段。

变通方法：在标题中标明执行顺序：

[1]     [db]       add schema fields
[2]     [db]       new table + repository
[3]     [service]  business logic layer
[4]     [api]      REST endpoints
[4.1]   [sdk]      client SDK wrapper
[4.1.1] [app]      consumer integration
[4.1.2] [app]      UI surface
[4.2]   [ui]       dashboard page

即使面板调整了顺序，读者也能一眼还原依赖关系图。点分编号 [n.m.k] 应体现父子嵌套关系，使索引与树形结构保持一致。

2. 按逻辑上的父子关系嵌套子问题，而非全部平铺在根问题下

Linear 支持无限层级的子问题。将 8 个或更多同级问题平铺在一个根问题下，很难浏览。应按主要任务与从属任务的逻辑分组：

• 核心服务 → 其 SDK → SDK 的使用方
• 如果某个子问题更适合作为另一子问题的下级，就不要将其设为同级问题

使用已发现的架构创建或移动问题时，设置父级关系（例如，在支持时使用 parentId: "LOBE-xxxx"）。移动父问题不需要重写 blockedBy 关系。

3. 子问题的创建顺序由 blockedBy 决定

blockedBy 要求阻塞项先存在（你需要它的 LOBE ID）。因此：

1. 按拓扑顺序排序 DAG——先处理叶节点（无依赖项），最后处理根节点
2. 第一批创建零依赖项的问题
3. 只有在收集到前序响应中的阻塞项 ID 后，才创建依赖问题
4. blockedBy 仅支持追加；再次传入不会覆盖——可以安全地重新运行

4. 遵守依赖顺序

创建依赖问题前，先收集阻塞项 ID。不要根据工具调用在消息中的显示方式推断它们会并行执行；请使用当前工具支持的执行行为。

5. 让每个子问题的描述完整自洽

每个子问题都应说明：

• 目标（1–2 行）
• 要修改的关键文件
• 具体变更／验收标准
• 依赖项（通过 LOBE-xxxx 链接到阻塞问题）
• 验证步骤

实现者可能只会打开子问题，不会打开父问题——不要依赖只在父问题描述中提供的上下文。

每个问题的完成流程

开始下一个问题前，先完成当前问题的收尾工作；不要将所有 Linear 更新都拖到最后。无需再次询问，即可复用该问题已有的授权来更新状态和发表评论。

1. 完成实现和仓库要求的检查，包括相关测试；遵循仓库 AGENTS.md 的 Quality Check 部分（在 LobeHub 中为 bun run check）。
2. 需要时使用 pr 技能创建 PR。在 PR 正文中加入 Fixes LOBE-123（或 Closes／Resolves），以便 Linear 能关联该 PR，并在合并时关闭问题。
3. PR 等待合并期间，将问题状态更新为 In Review；合并后更新为 Done。无需创建 PR 的工作，在结果和验证均完成后标记为 Done。
4. 主动添加或更新简洁的完成评论，说明最终行为、重要变更、验证结果和 PR 链接。关联 PR 不能替代这份便于阅读的总结。如果已有评论已涵盖相同结果，则不要重复发表评论。