create-issue

创建 Issue

为以下内容创建 Linear 工单或 GitHub issue：$ARGUMENTS

确定目标平台

根据用户输入，决定在哪里创建 issue：

• 如果用户提到“Linear”、“工单”或提供团队标识（例如 AI、NODE、N8N）→ Linear
• 如果用户提到“GitHub”、“GH issue”或“开源”→ GitHub
• 如果不明确，询问用户希望使用哪个平台

---

Linear 工单

前置条件

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

风格指南

标题

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

描述

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

Bug：

## 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]

功能/增强项：

## Summary
[One-paragraph overview of what this adds or changes]

## Problem
[What limitation or gap exists today]

## Proposed solution
[How it should work — technical approach if known]

## Out of scope
[Explicitly note what this does NOT cover, if helpful]

技术债：

## 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 are we trying to answer]

## Context
[Why this investigation is needed now]

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

附件（截图/视频）

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

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

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

优先级

值	级别	适用场景
4	低	可有可无，不影响用户
3	普通	默认值——常规计划工作
2	高	阻碍其他工作或对用户造成显著影响
1	紧急	生产环境故障、安全漏洞、数据丢失
0	无	尚未评估

注意事项：

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

状态

注意事项：

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

团队

• 尝试使用 mcp__notion__notion-search 从 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 问题
• 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. 使用 mcp__linear-server__save_issue 创建工单：

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

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

Linear 中绝不可做的事

• 绝不在 Triage 状态下创建问题
• 未经用户明确指示，绝不设置 Urgent 优先级
• 绝不应用 分诊状态、发布或 docs-automation 标签
• 除非用户明确要求，否则绝不设置 受指派人
• 除非用户明确要求，否则绝不设置 周期或 里程碑
• 绝不创建重复问题——如果用户描述的内容似乎可能已经存在，请先使用 mcp__linear-server__list_issues 搜索

---

GitHub 问题

前提条件

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

重要背景

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

风格指南

标题

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

正文

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

### 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

创建 Issue

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

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

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

   • 标题
   • 正文（较长时可缩略）
   • 仓库（默认：n8n-io/n8n）

4. 等待用户确认

5. 使用 gh 创建 Issue：

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

6. 向用户反馈 Issue 编号和 URL

绝不可执行的操作（GitHub）

• 绝不将功能请求作为 GitHub Issue 提交
• 绝不在没有复现步骤的情况下创建 Issue
• 绝不手动应用标签 — 由自动化处理
• 除非用户明确指定，否则绝不在 n8n-io/n8n 以外的仓库中创建 Issue

---

交叉链接

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

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

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