n8n:create-issue

创建问题

为以下内容创建一个 Linear 工单或 GitHub Issue：$ARGUMENTS

所有标题和描述均使用 ASD-STE100 简化技术英语： 使用短句、主动语态，并确保每句话只包含一条指令。

确定目标平台

根据用户输入判断应在哪里创建问题：

• 如果用户提到“Linear”“ticket”，或提供了团队键（例如 AI、NODE、N8N）→ Linear
• 如果用户提到“GitHub”“GH issue”或“open source”→ GitHub
• 如果不明确，询问用户希望使用哪个平台

---

Linear 工单

前提条件

继续操作前，确认 Linear MCP 已连接。

风格指南

标题

• 句首字母大写——仅首词首字母大写（例如，“Add webhook verification to Trello trigger”）
• 描述明确——读者无需打开工单即可理解其范围
• 5–15 个单词——长度足够具体，同时便于快速浏览
• 功能／增强需求使用祈使语气——“Add ...”“Support ...”“Improve ...”
• 缺陷标题——以 Bug - 开头，后接症状描述（例如，“Bug - Pin data not updating after workflow edit”）
• 标题中不包含工单 ID——标识符（AI-1234）会自动分配
• 末尾不加标点

描述

使用 Markdown 标题组织描述。使用适当的模板：

缺陷：

## Description
[Clear explanation of the problem]

## Expected
[What should happen]

## Actual
[What happens instead]

## Attachments
[Screenshots, videos, or screen recordings that illustrate the problem]

## Steps to reproduce
1. [Step-by-step reproduction]

## Additional context
- n8n version: [version]
- Database: [SQLite/PostgreSQL]
- Hosting: [cloud/self-hosted]

功能／增强需求：

## Goal
[What this adds and why: the user problem it solves]

## Background
[Current state and the gap, plus the technical context needed to plan the work: relevant constraints, prior findings, and links to any related investigation.]

## Scope
[Concrete list of what changes. Name the files or areas to create or modify and any existing pattern to follow.]

## Acceptance criteria
[Testable outcomes, including automated tests.]

## Out of scope
[What this explicitly does not cover]

技术债务：

## Summary
[What technical improvement is needed]

## Current state
[What the code/system looks like today and why it's problematic]

## Proposed improvement
[What the improved state should look like]

## Motivation
[Why this matters — maintainability, performance, developer experience, etc.]

## Scope
[What is included / excluded from this work]

技术探索／调查：

## Goal
[What question(s) are we trying to answer]

## Context
[Why this investigation is needed now]

## Questions
1. [Specific question to resolve]

## Expected output
[What deliverable is expected: RFC, PoC, decision document, path matrix, etc.]

## Acceptance criteria
[How we know the spike is done: each question answered, deliverable produced]

附件（截图／视频）

如果用户提供了截图、视频或屏幕录制：

• URL——使用 Markdown 图片语法直接嵌入描述中（![description](url)）
• 文件路径——如果用户提供了本地文件路径，请他们将文件上传到托管服务（例如 GitHub、Imgur），或使用可用的 Linear MCP 附件工具，在创建工单后将文件附加到 Linear 工单
• 对话中粘贴的图片——在工单描述中说明图片展示的内容，并注明用户提供了截图。你无法直接上传二进制数据。

只要提供了视觉证据，就始终在描述中提及，即使无法直接嵌入也要提及。

优先级

值	级别	适用情况
4	低	有更好，但不会影响用户
3	普通	默认值——标准的计划工作
2	高	阻碍其他工作或对用户造成显著影响
1	紧急	导致生产环境故障、存在安全漏洞或造成数据丢失
0	无	尚未评估

约束：

• 默认使用普通（3），除非用户明确提出其他要求
• 除非用户明确说“urgent”“P0”“production down”或“security vulnerability”，否则绝不设置为紧急（1）
• 绝不设置为无（0）——始终评估优先级。如果不确定，使用普通（3）

状态

约束：

• 绝不在 Triage 状态下创建问题——Triage 用于通过自动化流程（GitHub 同步、支持升级）进入的外部报告问题。Agent 创建的工单已有明确背景信息，应跳过 Triage
• 默认设置为 Backlog——问题已确认，但尚未安排到冲刺时使用此状态
• 仅当用户表示工作已安排在当前周期内或应尽快开始时，才使用 Todo
• 创建时绝不设置为 In Progress、Review 或 Done

团队

• 尝试使用可用的 Notion MCP 搜索工具，从 Notion 获取最新的团队职责范围（搜索“areas of responsibility”或类似内容）。根据获取的数据确定最适合处理该问题的团队。
• 如果 Notion MCP 不可用或查找失败，请使用以下常见团队作为备选：Engineering（N8N）、AI、NODES、Identity & Access（IAM）、Catalysts（CAT）、Lifecycle & Governance（LIGO）、Cloud Platform、Docs（DOC）
• 如果根据上下文或 Notion 查找结果无法确定团队，请务必询问用户
• 如果问题特定于某个节点，通常属于 NODES
• 如果涉及 AI/LangChain 节点，通常属于 AI

标签

请酌情从以下分组中应用标签：

类型（选一个）：

• bug — 功能异常
• feature — 全新的功能
• enhancement — 改进现有功能
• tech debt — 内部质量改进
• spike — 限时调查
• doc — 仅涉及文档的更改

领域（适用时选择）：

• frontend、backend、performance、testing、infra、DX、Security-Team

来源（适用时选择）：

• Internal — 由团队成员创建
• GitHub — 源自 GitHub issue
• Sentry — 源自错误监控
• Zammad — 源自支持请求

分类（适用时选择）：

• 使用相关的功能领域分类（例如 Credentials、Canvas/Node、RBAC、LangChain nodes、Form Trigger 等）

约束：

• 务必应用类型标签 — 每个工单都至少需要一个类型标签
• 不要应用分诊状态标签（Triage: Pending、Triage: Complete 等）— 这些由分诊自动化管理
• 不要应用发布标签（[email protected] 等）— 这些由发布自动化管理
• 不要应用 docs-automation 标签 — 这些由文档自动化管理

预估

只有在用户提供预估或明确要求填写时，才设置预估。使用 T 恤尺码：

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

创建工单

1. 收集必填字段 — 如果缺少任何字段，请询问用户：

   • 标题
   • 团队
   • 描述（根据用户输入，使用上述模板起草）

2. 创建前展示预览 — 向用户展示：

   • 标题
   • 团队
   • 状态
   • 优先级
   • 标签
   • 描述（如果内容较长，可缩略展示）

3. 等待用户确认 — 用户批准前不要创建

4. 使用可用的 Linear MCP 工单创建工具创建工单：

   title: <title>
   team: <team name>
   description: <markdown description>
   priority: <priority number>
   state: <status name>
   labels: [<label names>]
   

5. 反馈结果，提供 issue 标识符和 URL

Linear 中绝不可做的事

• 绝不要将 issue 创建为 Triage 状态
• 未经用户明确指示，绝不要设置 Urgent 优先级
• 绝不要应用 分诊状态、发布或 docs-automation 标签
• 除非用户明确要求，否则绝不要设置 负责人
• 除非用户明确要求，否则绝不要设置 周期或 里程碑
• 绝不要创建重复 issue — 如果用户描述的内容可能已经存在，请先使用可用的 Linear MCP issue 搜索工具进行搜索

---

GitHub Issues

前提条件

验证 gh CLI 已通过身份验证：gh auth status

重要背景

n8n GitHub issue 跟踪器（n8n-io/n8n）仅用于错误报告。功能请求和问题会被引导至社区论坛。空白 issue 已禁用 — 必须使用错误模板。

风格指南

标题

• 句首字母大写 — 与 Linear 相同
• 描述具体症状 — 说明哪里异常，而不是你想要什么
• 无需添加前缀 — 不要添加“Bug:”或“Bug Report:”（模板会处理分类）
• 末尾不要加标点

正文

GitHub 问题必须遵循错误报告模板结构：

### Bug Description

[Clear explanation of the bug]

### Steps to Reproduce

1. [Step 1]
2. [Step 2]
3. [Step 3]

### Expected Behavior

[What should happen]

### Debug Info

[If available — output from Help > About n8n > Copy debug information]

### Operating System

[e.g., macOS 14.2, Ubuntu 22.04]

### n8n Version

[e.g., 1.72.1]

### Node.js Version

[e.g., 20.11.0]

### Database

SQLite / PostgreSQL

### Execution Mode

main / queue

### Hosting

n8n cloud / self hosted

注意事项：

• 始终包含复现步骤——缺少复现步骤的问题会被标记为 closed:incomplete-template 并关闭
• 如有调试信息，请一并提供——这对问题分诊至关重要
• 切勿将功能请求提交为 GitHub 问题——请引导用户前往社区论坛，或建议改为创建 Linear 工单

标签

创建 GitHub 问题时，不要手动添加标签。分诊自动化会处理标签：

• 自动添加 triage:pending
• 同步后自动添加 status:in-linear

创建问题

1. 确认这是一个错误——如果用户描述的是功能请求，请告知他们 GitHub 问题仅用于错误报告，并建议其他方式（Linear 工单或社区论坛）

2. 使用上述模板起草问题，并根据用户提供的信息填写字段

3. 创建前展示预览，向用户显示：

   • 标题
   • 正文（内容较长时可适当缩短）
   • 仓库（默认：n8n-io/n8n）

4. 等待用户确认

5. 使用 gh 创建问题：

   gh issue create --repo n8n-io/n8n --title "<title>" --body "$(cat <<'EOF'
   <body content>
   EOF
   )"
   

6. 反馈结果，提供问题编号和 URL

GitHub 相关的禁忌事项

• 切勿将功能请求提交为 GitHub 问题
• 切勿创建缺少复现步骤的问题
• 切勿手动添加标签——由自动化处理
• 除非用户明确指定，否则切勿在 n8n-io/n8n 以外的仓库中创建问题

---

交叉链接

当同一问题同时存在 Linear 工单和 GitHub 问题时：

• Linear → GitHub：将 GitHub 问题 URL 作为链接附件添加到 Linear 工单
• GitHub → Linear：在 GitHub 问题正文中添加 https://linear.app/n8n/issue/<TICKET-ID>

如果用户创建了其中一项并提到另一项已存在，请主动提出添加交叉链接。