n8n:create-pr

プルリクエストを作成

n8n の check-pr-title CI 検証に合格するタイトルで GitHub PR を作成します。

PR タイトルの形式

<type>(<scope>): <summary>

種類（必須）

種類	説明	変更履歴
feat	新機能	あり
fix	バグ修正	あり
perf	パフォーマンスの改善	あり
test	テストの追加・修正	なし
docs	ドキュメントのみ	なし
refactor	コードの変更（バグ修正や機能追加を伴わないもの）	なし
build	ビルドシステムまたは依存関係の変更	なし
ci	CI の設定	なし
chore	定常作業、メンテナンス	なし

スコープ（任意ですが、推奨）

• API - パブリック API の変更
• benchmark - ベンチマーク CLI の変更
• core - コア／バックエンド／プライベート API
• editor - エディター UI の変更
• engine - 新しいワークフロー実行エンジン v2（@n8n/engine パッケージおよび cli の engine-v2 モジュール）
• * Node - 特定のノード（例：Slack Node、GitHub Node）

概要のルール

• 命令形の現在形を使います：「Added」ではなく「Add」
• 先頭の文字を大文字にします
• 末尾にピリオドを付けません
• チケット ID は含めません（例：N8N-1234）
• 変更履歴から除外する場合は、種類ですでに除外されていない限り、末尾に (no-changelog) を追加します

手順

1. 現在の状態を確認します：

   git status
   git diff --stat
   git log origin/master..HEAD --oneline
   

2. 実装計画を確認します：リポジトリの計画ディレクトリ（.claude/plans/ または .agents/plans/ がある場合）で、現在のブランチのチケット ID に一致する計画ファイルを探します（例：ブランチが scdekov/PAY-1234-some-feature の場合は、PAY-1234.md を確認します）。 計画ファイルがある場合は、折りたたみ可能な <details> セクションとして PR の説明に含めるか、ユーザーに確認します（「計画セクション」を参照）。 ユーザーが明示的に承認した場合にのみ、計画を含めます。

3. セキュリティ修正の場合は、作業を進める前に、ユーザー向けの成果物をすべて監査します（「セキュリティ修正」を参照）。

4. 変更を分析し、以下を判断します：

   • 種類：どのような種類の変更ですか？
   • スコープ：どのパッケージ／領域に影響しますか？
   • 概要：変更によって何ができますか？

5. 必要に応じてブランチをプッシュします：

   git push -u origin HEAD
   

6. gh CLI を使って PR を作成します。.github/pull_request_template.md を本文の構成として読み込み、PR を作成する前に各セクションへ実際の内容を記入します：

   • Summary：PR の内容を説明します
   • Why：変更が必要な理由を説明します（「理由」を参照）
   • How to test：変更のテスト方法を説明します。適切な場合は、ワークフローの例を含めます
   • Related tickets：Linear のチケット URL（https://linear.app/n8n/issue/[TICKET-ID]）と、関連する GitHub issue のリンクを追加します
   • Checklist：テンプレートの内容をそのまま残します
     • 本文の末尾に「🤖 PR Summary generated by AI」を追加します

   PR を作成する前に、以下の観点で本文を校正します。チェックに合格しない文は、それぞれ書き直します。

   1. Summary と Why を合わせた語数が上限内であること。超えている場合は、まずレビュアーが差分で確認できる詳細を削り、その後 Why を短くします。
   2. 各文で、コンポーネント、プロセス、または人を主語にし、誰が何をするかを明示します。また、平易で技術的な動詞を使います。
   3. 各ドメイン用語は、最初に登場する箇所で平易に定義します。
   4. 各文の内容が差分と一致していることを確認します。

   後続のコミットによって本文の事実が変わった場合は、本文を更新します。

   gh pr create --draft --title "<type>(<scope>): <summary>" --body "$(cat <<'EOF'
   <populated body based on pull_request_template.md>
   EOF
   )"
   

PR 本文のガイドライン

.github/pull_request_template.md に基づきます。

この分野のコードに詳しくないレビュアーに向けて書いてください。レビュアーは、差分を開く前に変更内容を理解できる必要があります。ASD-STE100 の簡易テクニカル英語を使用してください。短い文と能動態を使います。

1. Summary と Why は合わせて約 200 語以内にします。小さな PR では、さらに短くしてください。
2. 各ドメイン用語は、初めて登場したときに平易な言葉で定義してください。説明にチケット ID や内部名を使わないでください。
3. レビュアーが差分で確認できる詳細（エラーケース、ステータスコード、名前を変更したフィールド、呼び出し順、ファイル一覧、テスト名）は省略してください。レビュアーが見落とす可能性のある動作の変更に関わる場合のみ、記載してください。また、レビュアーがすでに知っていること（フレームワークの動作）も省略してください。
4. 比喩ではなく、平易な技術用語の動詞を使ってください（「値を渡します」とし、「値を手渡します」や「値を通します」としないでください）。

Summary：PR の内容

1. この分野に初めて触れる読者に向けて、背景を 1～3 文で説明します。その後、PR の内容を述べてください。
2. コード編集の一覧ではなく、動作について文章で説明してください。クラスや関数が重要な中核概念を表し、変更内容を理解する助けになる場合は、その名前を記載してください。
3. PR でプロダクトコードを変更しない場合は、最初の文でその旨を述べてください（例：「この PR ではテストのみを追加します。」）。
4. ここでは変更の理由を説明しないでください。理由は Why に記載します。
5. UI の変更には、スクリーンショットまたは動画を含めてください。

Why：理由

## Why セクションは必ず記入してください。レビュアーにとって最も重要なのは Summary と Why の要点です。要点は簡潔にしてください。

1. Summary を繰り返さないでください。
2. 既存のコードでは対応できない問題や制約を説明してください。
3. 許容される未対応事項がある場合や、既存のコードパスを変更する場合は、別の短い段落で説明してください。

レビュアーから質問が出る可能性がある場合に限り、却下した代替案を記載してください。代替案ごとに 1～2 文を使い、具体的な不採用理由を述べてください。実装していない代替案は条件文で記述してください。代替案の説明は、合計で Why の要点より短くしてください。

How to test セクション

• 変更のテスト方法を説明してください。
• 適切な場合は、ワークフローの例を含めてください。
• デフォルトの n8n インスタンスでは機能が無効になっている場合（N8N_ENABLED_MODULES によるデフォルト以外のモジュール、エンタープライズライセンス、機能フラグなどが必要な場合）は、テスターが適切に設定されたインスタンスをデプロイできるよう、必要な環境変数やライセンスを記載してください。

Related Links セクション

• Linear チケットへのリンク：https://linear.app/n8n/issue/[TICKET-ID]
• 自動クローズに使うキーワードを含めて GitHub の Issue にリンクしてください。
  • closes #123 / fixes #123 / resolves #123
• 該当する場合は、コミュニティフォーラムの投稿にリンクしてください。

チェックリスト

マージ前にすべての項目に対応してください。

• PR の作成者本人が、「このコードを確認し、実行し、このコードに責任を持つことを承知しています。」のチェックボックスにチェックを入れている
• PR のタイトルが規約に従っている
• ドキュメントが更新されているか、フォローアップチケットが作成されている
• テストが含まれている（バグ修正には回帰テスト、機能にはテストカバレッジが必要）
• 緊急修正のバックポートが必要な場合は、release/backport ラベルが追加されている

例

エディターの機能

feat(editor): Add workflow performance metrics display

コアのバグ修正

fix(core): Resolve memory leak in execution engine

ノード固有の変更

fix(Slack Node): Handle rate limiting in message send

破壊的変更（コロンの前に感嘆符を追加）

feat(API)!: Remove deprecated v1 endpoints

変更履歴の項目なし

feat(core): Experimental feature not enabled yet (no-changelog)

スコープなし（複数の領域に影響）

chore: Update dependencies to latest versions

検証

PR のタイトルは次のパターンに一致する必要があります。

^(feat|fix|perf|test|docs|refactor|build|ci|chore|revert)(\([a-zA-Z0-9 ]+( Node)?\))?!?: [A-Z].+[^.]$

主な検証ルール：

• Type は許可された値のいずれかである必要があります。
• Scope は省略可能ですが、指定する場合は括弧で囲む必要があります。
• 破壊的変更を示す感嘆符は、コロンの前に付けます。
• Summary は大文字で始める必要があります。
• Summary の末尾にピリオドを付けないでください。

Plan セクション

リポジトリのプランディレクトリに一致するプランファイルが見つかり、ユーザーがその掲載を承認した場合は、PR 本文の末尾（チェックリストの後、EOF の前）に折りたたみ可能なセクションを追加してください。

<details>
<summary>Implementation plan</summary>



</details>

セキュリティ修正

このリポジトリは公開されています。 公開される成果物に攻撃経路を決して露出させないでください。 防止する脅威ではなく、コードが何をするかを説明してください。

成果物	悪い例	良い例
ブランチ	fix-sql-injection-in-webhook	fix-webhook-input-validation
PR タイトル	fix(core): Prevent SSRF	fix(core): Validate outgoing URLs
コミットメッセージ	fix: prevent denial of service	fix: add payload size validation
PR の本文	「攻撃者が SSRF を引き起こす可能性がある…」	「URL のプロトコルとホストを検証します」
Linear の参照	スラッグ付き URL（タイトルが漏れる）	スラッグなしの URL、またはチケット ID のみ
テスト名	'should prevent SQL injection'	'should sanitize query parameters'

セキュリティ修正をプッシュする前に確認してください： ブランチ名、コミット、PR タイトル、 PR の本文、Linear の URL、テスト名、コードコメントのいずれにも、脆弱性を示唆する記述がないこと。

判断に迷った場合は、追加の予防策がないか Linear の issue を確認してください