linear-issue

Linear 问题分析

开始处理 Linear 问题 $ARGUMENTS

前置条件

此技能依赖外部工具。继续之前，请确认这些工具可用：

必需：

• Linear MCP（mcp__linear）：必须已连接。没有它，此技能完全无法运行。
• GitHub CLI（gh）：必须已安装并完成身份验证。运行 gh auth status 进行验证。用于获取关联的 PR 和问题。

可选（可优雅降级）：

• Notion MCP（mcp__notion）：仅当问题链接到 Notion 文档时需要。如果不可用，请在摘要中注明 Notion 链接，并告诉用户手动查看。
• Loom transcript 技能（/loom-transcript）：仅当问题包含 Loom 视频时需要。如果不可用，请在摘要中注明 Loom 链接，供用户观看。
• curl：用于下载图片。几乎总是可用；如果缺失，请跳过图片下载并注明。

如果缺少必需工具，请停止并告诉用户继续之前需要配置什么。

说明

请按以下步骤收集有关问题的完整上下文：

1. 从 Linear 获取问题和评论

使用 Linear MCP 工具同时获取问题详情和评论：

• 使用 mcp__linear__get_issue 和问题 ID 获取完整详情，包括附件
• 包含关联关系，以查看阻塞、相关或重复的问题
• 紧接着使用 mcp__linear__list_comments 和问题 ID 获取所有评论

这两次调用应在同一步骤中完成，以便一开始就收集完整上下文。

2. 分析附件和媒体（必做）

重要：此步骤不可跳过。你必须扫描并获取问题描述和所有评论中的全部视觉内容。

截图/图片（始终获取）：

1. 扫描问题描述和所有评论，查找所有图片 URL：
   • <img> 标签
   • Markdown 图片 ![](url)
   • 原始 URL（github.com/user-attachments、imgur.com 等）
2. 对找到的每张图片（无论位于描述还是评论中）：
   • 使用 curl -sL "url" -o /path/to/image.png 下载（GitHub URL 需要跟随重定向），或使用 linear MCP
   • 使用 Read 工具查看下载的文件
   • 详细描述你看到的内容
3. 不要跳过图片——其中常包含错误消息、UI 状态或配置等关键信息

Loom 视频（始终获取文字记录）：

1. 扫描问题描述和所有评论，查找 Loom URL（loom.com/share/...）
2. 对找到的每个 Loom 视频（无论位于描述还是评论中）：
   • 使用 /loom-transcript 技能获取完整文字记录
   • 总结关键要点、时间戳以及演示的问题
3. Loom 视频通常包含仅靠文字无法传达的重要复现步骤和上下文

3. 获取相关上下文

相关 Linear 问题：

• 对关联关系中提到的任何问题（阻塞、被阻塞、相关、重复），使用 mcp__linear__get_issue 获取详情
• 总结这些问题与主问题的关联

GitHub PR 和问题：

• 如果提到了 GitHub 链接，使用 gh CLI 获取 PR/问题详情：
  • 对于拉取请求：gh pr view <number>
  • 对于问题：gh issue view <number>
• 下载附加在问题中的图片：curl -H "Authorization: token $(gh auth token)" -L <image-url> -o image.png

Notion 文档：

• 如果存在 Notion 链接，使用 mcp__notion__notion-fetch 并提供 Notion URL 或页面 ID，以获取文档内容
• 总结相关文档

4. 查看评论

评论已在步骤 1 中获取。请查看评论中的：

• 补充上下文和讨论历史
• 评论中链接的附件或媒体（在步骤 2 中处理）
• 对原始问题描述的澄清或更新

5. 确定受影响的节点（如适用）

判断此问题是否特定于某个 n8n 节点（例如触发器、操作或工具节点）。请留意以下线索：

• 问题标题（例如“Linear trigger”“Slack node”“HTTP Request”）
• 问题描述和评论中提到的节点名称
• 问题上的标签或标记（例如 node:linear、node:slack）
• 显示特定节点配置或错误的截图

如果问题与特定节点有关：

1. 查找节点类型 ID。 使用 Grep 在 packages/frontend/editor-ui/data/node-popularity.json 中搜索节点的显示名称（或相关关键词），以找到准确的节点类型 ID。常见的 ID 模式如下：

   • 核心节点：n8n-nodes-base.<camelCaseName>（例如，“HTTP Request” → n8n-nodes-base.httpRequest）
   • 触发器变体：n8n-nodes-base.<name>Trigger（例如，“Gmail Trigger” → n8n-nodes-base.gmailTrigger）
   • 工具变体：n8n-nodes-base.<name>Tool（例如，“Google Sheets Tool” → n8n-nodes-base.googleSheetsTool）
   • LangChain/AI 节点：@n8n/n8n-nodes-langchain.<camelCaseName>（例如，“OpenAI Chat Model” → @n8n/n8n-nodes-langchain.lmChatOpenAi）

2. 查找节点的受欢迎程度评分。 使用 Grep 在该文件中搜索节点 ID。该评分为 0 到 1 之间的对数尺度值。使用以下阈值进行分类：

   评分	等级	描述	示例
   ≥ 0.8	高	核心／广泛使用的节点，排名前约 5%	HTTP Request（0.98）、Google Sheets（0.95）、Postgres（0.83）、Gmail Trigger（0.80）
   0.4–0.8	中	定期使用的集成	Slack（0.78）、GitHub（0.64）、Jira（0.65）、MongoDB（0.63）
   < 0.4	低	小众或很少使用的节点	Amqp（0.34）、Wise（0.36）、CraftMyPdf（0.33）

   在摘要中注明原始评分和等级（高／中／低）。

3. 如果在受欢迎程度文件中找不到该节点，请注明它可能是社区节点，或是非常新／小众的节点。

6. 评估工作量／复杂度

收集完所有背景信息后，评估修复／实现此问题所需的工作量。使用以下 T 恤尺码：

尺码	大致工作量
XS	≤ 1 小时
S	≤ 1 天
M	2-3 天
L	3-5 天
XL	≥ 6 天

评估时请考虑：

• 变更范围：需要修改多少个文件／软件包？这是单个节点修复，还是涉及多个部分的变更？
• 复杂度：这是简单的参数变更、新的 API 集成、新的凭据类型，还是架构变更？
• 测试：需要多少测试覆盖？是否需要 E2E 测试？
• 风险：这会破坏现有功能吗？是否需要向后兼容？
• 依赖项：是否涉及外部 API 变更、新软件包或跨团队协作？
• 文档：是否需要更新文档、迁移指南或变更日志？

请给出 T 恤尺码，并简要说明估算依据的关键因素。

7. 汇总

提交汇总前，请确认已完成：

• 下载并查看了描述和评论中的所有图片
• 获取了描述和评论中所有 Loom 视频的文字记录
• 通过 gh CLI 获取了所有关联的 GitHub issue/PR
• 列出了该 issue 下的所有评论
• 检查该 issue 是否特定于某个节点；如果是，则查询其受欢迎程度
• 使用 T 恤尺码评估工作量/复杂度

收集完所有背景信息后，请提交一份全面的汇总，包括：

1. Issue 概览：标题、状态、优先级、负责人、标签
2. 描述：完整的 issue 描述，以及评论中的任何澄清
3. 视觉背景：概述截图/视频（说明你在每项中观察到的内容）
4. 受影响的节点（如适用）：节点名称、节点类型 ID（n8n-nodes-base.xxx）、受欢迎程度分数及等级（例如 0.64 — 中等受欢迎程度）
5. 相关 Issue：说明其与其他工作的关联
6. 技术背景：任何 PR、代码引用或文档
7. 工作量估算：T 恤尺码（XS/S/M/L/XL）及理由
8. 后续步骤：根据收集到的所有背景信息提出建议方案

备注

• Issue ID 可以采用以下格式：AI-1975、node-1975，也可以只提供 1975（将进行搜索）
• 如果未提供 Issue ID，请向用户索要