n8n:create-issue

イシューを作成

次の内容について、Linear のチケットまたは GitHub のイシューを作成します：$ARGUMENTS

タイトルと説明はすべて、ASD-STE100 簡易テクニカル英語で記述します： 短い文を使い、能動態にし、各文に指示を1つだけ含めます。

作成先を決定

ユーザーの入力に基づいて、イシューを作成する場所を決定します：

• ユーザーが「Linear」、「ticket」と言うか、チームキー（例：AI、NODE、N8N）を指定した場合 → Linear
• ユーザーが「GitHub」、「GH issue」、「open source」と言う場合 → GitHub
• 曖昧な場合は、どのプラットフォームを使うかユーザーに尋ねてください

---

Linear チケット

前提条件

続行する前に、Linear MCP が接続されていることを確認します。

スタイルガイド

タイトル

• 文頭のみ大文字 — 最初の単語だけを大文字にします（例：「Trello trigger に webhook 検証を追加」）
• 説明的 — チケットを開かなくても、読者が対象範囲を理解できるようにします
• 5～15語 — 具体的でありながら、ざっと確認しやすい長さにします
• 機能／拡張では命令形 — 「追加する…」、「サポートする…」、「改善する…」
• バグのタイトル — Bug - を先頭に付け、その後に症状を記述します（例：「Bug - ワークフロー編集後にピン留めしたデータが更新されない」）
• タイトルにチケット 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 同期、サポートエスカレーション）経由で登録される外部報告のイシュー用です。エージェントが作成するチケットは状況が把握されているため、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 が担当である可能性が高いです

ラベル

該当するグループからラベルを適用してください。

種類（1 つ選択）：

• 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 など）。

ガードレール：

• 必ず種類のラベルを適用してください — すべてのチケットに少なくとも 1 つ必要です
• トリアージ状態のラベル（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. 課題識別子と URL を報告します

Linear で絶対にしてはいけないこと

• Triage ステータスで課題を作成しないでください
• ユーザーから明示的な指示がない限り、Urgent の優先度を設定しないでください
• トリアージ状態、リリース、docs-automation のラベルを適用しないでください
• ユーザーから明示的に求められない限り、担当者を設定しないでください
• ユーザーから明示的に求められない限り、サイクルやマイルストーンを設定しないでください
• 重複する課題を作成しないでください — ユーザーの説明が既存の課題と重複する可能性がある場合は、利用可能な Linear MCP の課題検索ツールで先に検索してください

---

GitHub の課題

前提条件

gh CLI が認証済みであることを確認してください：gh auth status

重要なコンテキスト

n8n の GitHub 課題トラッカー（n8n-io/n8n）では、バグのみを受け付けています。機能リクエストや質問はコミュニティフォーラムに案内されます。空の課題は無効になっているため、バグ用テンプレートを使用してください。

スタイルガイド

タイトル

• 文頭のみ大文字 — Linear と同様です
• 症状がわかる説明 — 何が壊れているかを記述し、何を望んでいるかは記述しません
• 接頭辞は不要 — 「Bug:」や「Bug Report:」を追加しないでください（分類はテンプレートで行います）
• 末尾に句読点を付けないでください

本文

GitHub の issue は、必ずバグ報告テンプレートの構成に従う必要があります。

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

ガードレール：

• 必ず再現手順を含めてください — 再現手順がない issue は closed:incomplete-template としてクローズされます
• 可能であればデバッグ情報を含めてください — トリアージに不可欠です
• 機能リクエストを GitHub の issue として登録しないでください — ユーザーをコミュニティフォーラムに案内するか、代わりに Linear チケットの作成を提案してください

ラベル

GitHub の issue を作成するときに、ラベルを手動で適用しないでください。トリアージの自動化によってラベルが付与されます。

• triage:pending は自動的に適用されます
• 同期時に status:in-linear が自動的に適用されます

issue の作成

1. バグかどうかを確認する — ユーザーが機能リクエストを説明している場合、GitHub の issue はバグ専用であることを伝え、代替手段（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> を追加する

ユーザーが一方を作成し、もう一方が存在すると伝えた場合は、相互リンクの追加を提案してください。