create-issue

Issue の作成

次の内容の Linear チケットまたは GitHub issue を作成します：$ARGUMENTS

作成先の決定

ユーザーの入力に基づいて、issue の作成先を決定します。

• ユーザーが「Linear」「ticket」と言うか、チームキー（例：AI、NODE、N8N）を指定した場合 → Linear
• ユーザーが「GitHub」「GH issue」「open source」と言う場合 → GitHub
• あいまいな場合は、どちらのプラットフォームを希望するかユーザーに確認してください

---

Linear チケット

前提条件

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

スタイルガイド

タイトル

• 文頭のみ大文字 — 最初の単語だけを大文字にします（例：「Trello トリガーに 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]

機能／拡張の場合：

## 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）を使用します

ステータス

ガードレール：

• トリアージのステータスで issue を作成しないでください — トリアージは、GitHub 同期やサポートへのエスカレーションなど、自動化されたパイプラインから入る外部報告の issue に使用します。エージェントが作成するチケットには既知のコンテキストがあるため、トリアージをスキップします
• バックログをデフォルトにします — issue が認識されているものの、まだスプリントに計画されていない場合に使用します
• ユーザーが、現在のサイクルで計画済み、または早急に着手すべき作業だと示した場合に限り、Todo を使用します
• 作成時に進行中、レビュー、完了に設定しないでください

チーム

• Notion の mcp__notion__notion-search を使って、最新のチーム担当領域を取得してください（「areas of responsibility」などで検索）。取得した情報をもとに、issue に最適なチームを判断します
• Notion MCP を利用できない場合や、検索に失敗した場合は、次の一般的なチームを使用します：Engineering（N8N）、AI、NODES、Identity & Access（IAM）、Catalysts（CAT）、Lifecycle & Governance（LIGO）、Cloud Platform、Docs（DOC）
• コンテキストや Notion の検索結果から明らかでない場合は、必ずユーザーにチームを確認してください
• ノード固有の issue は、NODES に属する可能性が高いです
• AI／LangChain ノードに関する issue は、AI に属する可能性が高いです

ラベル

必要に応じて、以下のグループからラベルを適用します。

種類 (1 つ選択):

• 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. チケットを作成する — mcp__linear-server__save_issue を使用します:

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

5. 報告する — issue の識別子と URL を伝えます

決して行わないこと (Linear)

• Triage ステータスで issue を作成しない
• ユーザーの明示的な指示なしに Urgent 優先度を設定しない
• triage-state、release、docs-automation のラベルを適用しない
• ユーザーが明示的に求めない限り assignee を設定しない
• ユーザーが明示的に求めない限り cycle や milestone を設定しない
• 重複する issue を作成しない — 既に存在する可能性があると思われる内容をユーザーが説明した場合は、まず mcp__linear-server__list_issues で検索してください

---

GitHub Issues

前提条件

gh CLI が認証されていることを確認します: gh auth status

重要なコンテキスト

n8n の GitHub issue トラッカー (n8n-io/n8n) は バグ専用 です。機能リクエストや質問は コミュニティフォーラム に誘導されます。空の issue は無効化されています — バグテンプレートを使用する必要があります。

スタイルガイド

タイトル

• センテンスケース — 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> を追加します

ユーザーがどちらか一方を作成し、もう一方がすでに存在すると伝えた場合は、相互リンクの追加を提案します。