n8n:linear-issue

Linear Issue Analysis

开始处理 Linear 工单 $ARGUMENTS

前提条件

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

必需：

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

可选（可降级处理）：

• Notion MCP：仅当工单链接到 Notion 文档时才需要。如果不可用，请在摘要中注明 Notion 链接，并告知用户手动查看。
• Loom transcript skill：仅当工单包含 Loom 视频时才需要。如果不可用，请在摘要中注明 Loom 链接，供用户查看。
• curl：用于下载图片。通常都可用；如果缺少，请跳过图片下载并注明。

如果缺少必需工具，请停止并告知用户继续之前需要进行哪些设置。

说明

按照以下步骤收集有关工单的完整上下文：

1. 从 Linear 获取工单和评论

使用当前运行环境中可用的 Linear MCP 工具，同时获取工单详情和评论：

• 按 ID 获取工单，以查看包括附件在内的完整详情
• 包含关联信息，以查看阻塞、相关或重复的工单
• 紧接着获取该工单 ID 的所有评论

这两项调用应在同一阶段一起执行，以便提前收集完整上下文。

2. 检查私密/安全工单（必须在进行任何其他操作前执行）

获取工单后，立即检查其标签：

1. 查看工单返回的标签。

2. 如果存在标签 n8n-private： a. 运行 git remote -v（通过 Bash）列出所有已配置的远程仓库。 b. 如果任意远程仓库 URL 包含不带 -private 后缀的 n8n-io/n8n（即指向公开仓库），请立即停止并告知用户：

   此工单标记为 n8n-private，必须在私有仓库的干净克隆中进行开发。

   你的一个或多个远程仓库指向公开的 n8n-io/n8n 仓库。不允许混用远程仓库——你必须在 n8n-io/n8n-private 的单独本地克隆中工作，且不能包含对公开仓库的任何引用。 完整流程请参阅：https://www.notion.so/n8n/Processing-critical-high-security-bugs-vulnerabilities-in-private-2f45b6e0c94f803da806f472111fb1a5

   显示此消息后不要继续执行任何后续步骤。

3. 如果不存在该标签，或所有远程仓库都只指向 n8n-io/n8n-private，则正常继续。

3. 分析附件和媒体（必须执行）

重要：此步骤不可省略。你必须扫描并获取工单描述和所有评论中的全部视觉内容。

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

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 skill 获取完整文字稿
   • 总结关键要点、时间戳以及演示的问题
3. Loom 视频通常包含仅靠文字无法传达的关键复现步骤和上下文

4. 获取相关上下文

相关 Linear 问题：

• 对于关联中提及的任何问题（阻塞、被阻塞、相关、重复），请使用 Linear MCP 问题获取工具
• 总结这些问题与主要问题的关联

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 链接，请使用 Notion MCP 获取工具，通过 Notion URL 或页面 ID 获取文档内容
• 总结相关文档

5. 查看评论

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

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

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

判断此问题是否针对某个特定的 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. 查询节点的受欢迎程度分数——先检查是否有 Flaky 评估（见下文），否则使用受欢迎程度文件：

   首选：检查 Linear 评论中 Flaky 的评估。 Flaky 是一个自动分流 Agent，会在评论中发布问题分析。在步骤 1 中已获取的评论里，查找作者名为“Flaky”（或作者名中包含“Flaky”）的评论——不要重新获取评论。如果找到了，请直接从 Flaky 的分析中提取受欢迎程度分数和级别，并使用这些值。

   备用方案（没有 Flaky 评论时）： 从 packages/frontend/editor-ui/data/node-popularity.json 中查找节点的受欢迎程度分数。使用 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）

   在摘要中注明原始分数和级别（高／中／低），并说明分数来自 Flaky 还是受欢迎程度文件。

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

7. 评估工作量/复杂度

首选：检查 Linear 评论中 Flaky 给出的工作量估算。 在步骤 1 已获取的评论中搜索 Flaky 的评论——不要重新获取。如果找到，直接从中提取工作量/复杂度估算，并将其作为评估结果。

备用方案（如果没有 Flaky 的评论）： 收集完所有背景信息后，评估修复/实现该问题所需的工作量。使用以下 T 恤尺码：

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

评估时，请考虑：

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

给出 T 恤尺码，并简要说明促成该估算的关键因素。注明该估算来自 Flaky 还是你自己的评估。

8. 呈现摘要

呈现前，请确认已完成以下事项：

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

收集完所有背景信息后，呈现一份全面的摘要，包括：

1. Issue 概览：标题、状态、优先级、负责人、标签
2. 描述：完整的问题描述，以及评论中的任何澄清
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，请向用户索要