메뉴
Create Linear tickets or GitHub issues following n8n conventions. Use when the user asks to create a ticket, file a bug, open an issue, or says /create-issue.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/n8n-io/n8n --skill n8n-create-issue명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | n8n:create-issue |
| description | Create Linear tickets or GitHub issues following n8n conventions. Use when the user asks to create a ticket, file a bug, open an issue, or says /create-issue. |
| argument-hint | [linear|github] <description of the issue> |
| compatibility | {"requires":[{"mcp":"linear","description":"Required for creating Linear tickets"},{"cli":"gh","description":"Required for creating GitHub issues. Must be authenticated (gh auth login)"}]} |
Create a Linear ticket or GitHub issue for: $ARGUMENTS
Decide where the issue should be created based on user input:
Verify the Linear MCP is connected before proceeding.
Bug - followed by a description of the symptom (e.g., "Bug - Pin data not updating after workflow edit")Structure the description using markdown headers. Use the appropriate template:
For bugs:
## 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]
For features / enhancements:
## 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:
## 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:
## 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.]
If the user provides screenshots, videos, or screen recordings:
)Always mention in the description when visual evidence was provided, even if it cannot be directly embedded.
| 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:
Guardrails:
Engineering (N8N), AI, NODES, Identity & Access (IAM), Catalysts (CAT), Lifecycle & Governance (LIGO), Cloud Platform, Docs (DOC)NODESAIApply labels from these groups as appropriate:
Type (pick one):
bug — something is brokenfeature — net-new capabilityenhancement — improvement to existing functionalitytech debt — internal quality improvementspike — time-boxed investigationdoc — documentation-only changeArea (pick if applicable):
frontend, backend, performance, testing, infra, DX, Security-TeamSource (pick if applicable):
Internal — created by team membersGitHub — originated from a GitHub issueSentry — originated from error monitoringZammad — originated from supportBucket (pick if applicable):
Credentials, Canvas/Node, RBAC, LangChain nodes, Form Trigger, etc.)Guardrails:
Triage: Pending, Triage: Complete, etc.) — these are managed by triage automationn8n@1.36.0, etc.) — these are managed by release automationdocs-automation labels — these are managed by docs automationOnly 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 |
Gather required fields — if any are missing, ask the user:
Present a preview before creating — show the user:
Wait for user confirmation — do not create until the user approves
Create the ticket using the available Linear MCP issue-creation tool:
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
Verify gh CLI is authenticated: gh auth status
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.
GitHub issues must follow the bug report template structure:
### 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
Guardrails:
closed:incomplete-templateDo not manually apply labels when creating GitHub issues. The triage automation handles labeling:
triage:pending is auto-appliedstatus:in-linear is auto-applied when syncedVerify 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:
n8n-io/n8n)Wait for user confirmation
Create the issue using gh:
gh issue create --repo n8n-io/n8n --title "<title>" --body "$(cat <<'EOF'
<body content>
EOF
)"
Report back with the issue number and URL
When both a Linear ticket and GitHub issue exist for the same problem:
https://linear.app/n8n/issue/<TICKET-ID> in the GitHub issue bodyIf the user creates one and mentions the other exists, offer to add the cross-link.
Load before calling build-workflow. Default path for all single-workflow work: new one-off workflows, existing-workflow edits, verification repairs, and workflow-local data tables. Write or edit a workspace source file, run workflow-sdk validate via workspace_execute_command, then call build-workflow with filePath. When the workflow creates or writes Data Tables, load data-table-manager first, then this skill. Do not load planning or create-tasks first. Load planning only when multiple coordinated workflows or shared cross-task data tables require a dependency-aware task graph.
Debug failed or wrong-output workflow executions using executions tools. Load when the user reports execution failures, unexpected node output, empty parameter values after a successful run, or a node showing a red or failed expression error.
ONLY for coordinated multi-artifact work: multiple workflows with dependencies, shared data-table schema/migration across tasks, or the user explicitly asked to review a plan first. Load create-tasks via load_tool before calling it (search "create tasks" if not visible). Do NOT use for new one-off workflows, single-workflow edits, verification-only requests, or standalone data-table ops — use workflow-builder or data-table-manager instead.