create-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Issue

创建工单/议题

Create a Linear ticket or GitHub issue for: $ARGUMENTS

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

Determine Target

确定目标平台

Decide where the issue should be created based on user input:

If the user says "Linear", "ticket", or provides a team key (e.g., AI, NODE, N8N) → Linear
If the user says "GitHub", "GH issue", or "open source" → GitHub
If ambiguous, ask the user which platform they want

根据用户输入决定议题的创建平台：

如果用户提到“Linear”、“ticket”或提供团队密钥（如AI、NODE、N8N）→ Linear
如果用户提到“GitHub”、“GH issue”或“开源”→ GitHub
如果信息不明确，询问用户选择哪个平台

Linear Tickets

Linear工单

Prerequisites

前置条件

Verify the Linear MCP is connected before proceeding.

在操作前请确认Linear MCP已连接。

Style Guide

风格指南

Title

标题

Sentence case — capitalize only the first word (e.g., "Add webhook verification to Trello trigger")
Descriptive — a reader should understand the scope without opening the ticket
5–15 words — long enough to be specific, short enough to scan
Imperative mood for features/enhancements — "Add ...", "Support ...", "Improve ..."
Bug titles — prefix with
```
Bug -
```
followed by a description of the symptom (e.g., "Bug - Pin data not updating after workflow edit")
No ticket IDs in titles — the identifier (AI-1234) is assigned automatically
No trailing punctuation

句首大写格式 — 仅首字母大写（例如：“为Trello触发器添加Webhook验证”）
描述清晰 — 读者无需打开工单即可了解范围
5-15个单词 — 长度足够具体，同时便于快速浏览
功能/优化类使用祈使语气 — “添加...”、“支持...”、“改进...”
Bug标题 — 前缀为
```
Bug -
```
，后跟症状描述（例如：“Bug - 编辑工作流后固定数据未更新”）
标题中不包含工单ID — 标识符（如AI-1234）会自动分配
末尾无标点符号

Description

描述

Structure the description using markdown headers. Use the appropriate template:

For bugs:

markdown

undefined

使用Markdown标题结构化描述内容，选择合适的模板：

Bug类：

markdown

undefined

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

复现步骤

[Step-by-step reproduction]

[分步复现步骤]

Additional context

额外信息

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


**For features / enhancements:**

```markdown

n8n版本: [版本号]
数据库: [SQLite/PostgreSQL]
部署方式: [云托管/自托管]


**功能/优化类：**

```markdown

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]


**For tech debt:**

```markdown

[明确说明本工单不包含的内容（如有需要）]


**技术债务类：**

```markdown

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]


**For spikes / investigations:**

```markdown

[此项工作包含/不包含的内容]


**调研类：**

```markdown

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

undefined

[预期的交付物——如RFC、PoC、决策文档等]

undefined

Attachments (Screenshots / Videos)

附件（截图/视频）

If the user provides screenshots, videos, or screen recordings:

URLs — embed directly in the description using markdown image syntax (
```
![description](url)
```
)
File paths — if the user provides a local file path, ask them to upload it to a hosting service (e.g., GitHub, Imgur) or use
```
mcp__linear-server__create_attachment
```
to attach it to the Linear ticket after creation
Pasted images in conversation — describe what the image shows in the ticket description and note that a screenshot was provided. You cannot upload binary data directly.

Always mention in the description when visual evidence was provided, even if it cannot be directly embedded.

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

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

无论是否能直接嵌入，都要在描述中提及已收到视觉证据。

Priority

优先级

Value	Level	When to use
4	Low	Nice-to-have, no user impact
3	Normal	Default — standard planned work
2	High	Blocks other work or affects users significantly
1	Urgent	Production-breaking, security vulnerability, data loss
0	None	Not yet assessed

Guardrails:

Default to Normal (3) unless the user explicitly states otherwise
Never set Urgent (1) unless the user explicitly says "urgent", "P0", "production down", or "security vulnerability"
Never set None (0) — always make a priority assessment. If unsure, use Normal (3)

优先级值	优先级等级	适用场景
4	低	锦上添花，无用户影响
3	正常	默认选项——标准计划内工作
2	高	阻碍其他工作或对用户有显著影响
1	紧急	生产环境故障、安全漏洞、数据丢失
0	未评估	尚未评估

注意事项：

默认设置为正常（3） 除非用户明确说明
切勿设置为紧急（1） 除非用户明确提及“紧急”、“P0”、“生产环境故障”或“安全漏洞”
切勿设置为未评估（0） — 必须进行优先级评估。若不确定，使用正常（3）

Status

状态

Guardrails:

Never create issues in Triage status — Triage is for externally-reported issues that enter through automated pipelines (GitHub sync, support escalation). Agent-created tickets have known context and should skip triage
Default to Backlog — use this when the issue is acknowledged but not yet planned for a sprint
Use Todo only when the user indicates the work is planned for the current cycle or should be picked up soon
Never set In Progress, Review, or Done at creation time

注意事项：

切勿在Triage状态下创建议题 — Triage状态用于通过自动化管道提交的外部报告（如GitHub同步、支持工单升级）。由Agent创建的工单已有明确上下文，应跳过Triage
默认设置为Backlog — 当议题已确认但尚未排入迭代计划时使用
仅当用户表明工作已排入当前周期或即将启动时 使用Todo状态
创建时切勿设置为In Progress、Review或Done状态

Team

团队

Try to fetch up-to-date team areas of responsibility from Notion using
```
mcp__notion__notion-search
```
(search for "areas of responsibility" or similar). Use the fetched data to determine the best team for the issue.
If Notion MCP is unavailable or the lookup fails, fall back to these common teams:
```
Engineering
```
(N8N),
```
AI
```
,
```
NODES
```
,
```
Identity & Access
```
(IAM),
```
Catalysts
```
(CAT),
```
Lifecycle & Governance
```
(LIGO),
```
Cloud Platform
```
,
```
Docs
```
(DOC)
Always ask the user which team if not obvious from context or the Notion lookup
If the issue is node-specific, it likely belongs to
```
NODES
```
If it involves AI/LangChain nodes, it likely belongs to
```
AI
```

尝试通过Notion获取最新的团队职责范围 使用
```
mcp__notion__notion-search
```
（搜索“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
```
团队

Labels

Always apply a type label — every ticket needs at least a type
Do not apply triage-state labels (
```
Triage: Pending
```
,
```
Triage: Complete
```
, etc.) — these are managed by triage automation
Do not apply release labels (
```
n8n@1.36.0
```
, etc.) — these are managed by release automation
Do not apply
docs-automation
labels — these are managed by docs automation

从以下分组中按需应用标签：

类型（选一个）：

```
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状态标签（如
```
Triage: Pending
```
,
```
Triage: Complete
```
等）—— 这些标签由Triage自动化管理
切勿应用版本标签（如
```
n8n@1.36.0
```
等）—— 这些标签由发布自动化管理
切勿应用
docs-automation
标签 — 这些标签由文档自动化管理

Estimates

工作量估算

Only set an estimate if the user provides one or explicitly asks for one. Use t-shirt sizes:

Size	Value	Approximate effort
XS	1	≤ 1 hour
S	2	≤ 1 day
M	3	2–3 days
L	4	3–5 days
XL	5	≥ 6 days

仅当用户提供估算或明确要求时设置估算值。使用T恤尺码表示：

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

Creating the Ticket

创建工单

Gather required fields — if any are missing, ask the user:
- Title
- Team
- Description (draft one from the user's input using the templates above)
Present a preview before creating — show the user:
- Title
- Team
- Status
- Priority
- Labels
- Description (abbreviated if long)
Wait for user confirmation — do not create until the user approves

Create the ticket using

mcp__linear-server__save_issue

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

Report back with the issue identifier and URL

收集必填字段 — 若有缺失，询问用户：
- 标题
- 所属团队
- 描述（根据用户输入使用上述模板生成草稿）
创建前展示预览 — 向用户展示：
- 标题
- 所属团队
- 状态
- 优先级
- 标签
- 描述（过长时可缩写）
等待用户确认 — 获得用户批准后再创建

使用
mcp__linear-server__save_issue
创建工单：

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

反馈结果 — 提供工单标识符和链接

Things to Never Do (Linear)

Linear工单的禁止操作

Never create issues in Triage status
Never set Urgent priority without explicit user instruction
Never apply triage-state, release, or docs-automation labels
Never set assignee unless the user explicitly asks
Never set a cycle or milestone unless the user explicitly asks
Never create duplicate issues — if the user describes something that sounds like it may exist, search first with
```
mcp__linear-server__list_issues
```

切勿在Triage状态下创建议题
除非用户明确指示，否则切勿设置紧急优先级
切勿应用Triage状态、版本或docs-automation标签
除非用户明确要求，否则切勿设置经办人
除非用户明确要求，否则切勿设置迭代周期或里程碑
切勿创建重复议题 — 如果用户描述的内容可能已存在，先使用
```
mcp__linear-server__list_issues
```
搜索

GitHub Issues

GitHub议题

Prerequisites

前置条件

Verify

gh

CLI is authenticated:

gh auth status

确认

gh

CLI已认证：执行

gh auth status

Important Context

重要说明

The n8n GitHub issue tracker (

n8n-io/n8n

) is bug-only. Feature requests and questions are redirected to the community forum. Blank issues are disabled — the bug template must be used.

n8n的GitHub议题追踪器（

n8n-io/n8n

）仅接受Bug报告。功能请求和问题请转至社区论坛。空白议题已禁用——必须使用Bug模板。

Style Guide

风格指南

Title

标题

Sentence case — same as Linear
Descriptive of the symptom — what is broken, not what you want
No prefixes required — do not add "Bug:" or "Bug Report:" (the template handles categorization)
No trailing punctuation

句首大写格式 — 与Linear工单要求一致
清晰描述症状 — 说明问题是什么，而非需求
无需前缀 — 不要添加“Bug:”或“Bug Report:”（模板会自动分类）
末尾无标点符号

Body

正文

GitHub issues must follow the bug report template structure:

markdown

undefined

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

markdown

undefined

Bug Description

Bug描述

[Clear explanation of the bug]

[清晰说明Bug情况]

Steps to Reproduce

复现步骤

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

[步骤1]
[步骤2]
[步骤3]

Expected Behavior

预期行为

[What should happen]

[应该发生的情况]

Debug Info

调试信息

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

[如果有——从帮助>关于n8n>复制调试信息获取]

Operating System

操作系统

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

[例如：macOS 14.2, Ubuntu 22.04]

n8n Version

n8n版本

[e.g., 1.72.1]

[例如：1.72.1]

Node.js Version

Node.js版本

[e.g., 20.11.0]

[例如：20.11.0]

Database

数据库

SQLite / PostgreSQL

Execution Mode

执行模式

main / queue

Hosting

部署方式

n8n cloud / self hosted


**Guardrails:**
- **Always include reproduction steps** — issues without them get closed as `closed:incomplete-template`
- **Include debug info if available** — this is critical for triage
- **Never file feature requests as GitHub issues** — redirect the user to the community forum or suggest creating a Linear ticket instead

n8n云托管 / 自托管


**注意事项：**
- **必须包含复现步骤** — 无复现步骤的议题会被标记为`closed:incomplete-template`并关闭
- **如果有调试信息请包含** — 这对问题排查至关重要
- **切勿在GitHub议题中提交功能请求** — 引导用户前往社区论坛或建议创建Linear工单

Labels

Creating the Issue

创建议题

Verify it's a bug — if the user describes a feature request, inform them that GitHub issues are bug-only and suggest alternatives (Linear ticket or community forum)
Draft the issue using the template above, filling in fields from the user's input
Present a preview before creating — show the user:
- Title
- Body (abbreviated if long)
- Repository (default:
```
n8n-io/n8n
```
  )
Wait for user confirmation

Create the issue using

gh

bash

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

Report back with the issue number and URL

确认是Bug报告 — 如果用户描述的是功能请求，告知用户GitHub议题仅接受Bug报告，并提供替代方案（Linear工单或社区论坛）
使用上述模板生成议题草稿，根据用户输入填充字段
创建前展示预览 — 向用户展示：
- 标题
- 正文（过长时可缩写）
- 仓库（默认：
```
n8n-io/n8n
```
  ）
等待用户确认

使用
gh
创建议题：

bash

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

反馈结果 — 提供议题编号和链接

Things to Never Do (GitHub)

GitHub议题的禁止操作

Never file feature requests as GitHub issues
Never create issues without reproduction steps
Never manually apply labels — let automation handle it
Never create issues in repositories other than n8n-io/n8n unless the user explicitly specifies

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

Cross-Linking

交叉链接

When both a Linear ticket and GitHub issue exist for the same problem:

Linear → GitHub: Add the GitHub issue URL as a link attachment on the Linear ticket
GitHub → Linear: Add
```
https://linear.app/n8n/issue/<TICKET-ID>
```
in the GitHub issue body

If the user creates one and mentions the other exists, offer to add the cross-link.

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

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

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