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 の変更
• * 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/ にある、現在のブランチのチケット ID に一致する計画ファイルを探します（例：ブランチが scdekov/PAY-1234-some-feature の場合は、.claude/plans/PAY-1234.md を確認します）。 計画ファイルがある場合は、折りたたみ可能な <details> セクションとして PR の説明に含めるかどうか、ユーザーに確認します（下記の「計画セクション」を参照）。 ユーザーが明示的に承認した場合に限り、計画を含めます。

3. セキュリティ修正の場合は、先に進む前に、公開されているすべての成果物を監査します（下記の「セキュリティ修正」を参照）。

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

   • タイプ：どのような種類の変更ですか？
   • スコープ：どのパッケージ／領域に影響しますか？
   • サマリー：変更によって何が行われますか？

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

   git push -u origin HEAD
   

6. .github/pull_request_template.md のテンプレートを使って、gh CLI で PR を作成します：

   gh pr create --draft --title "<type>(<scope>): <summary>" --body "$(cat <<'EOF'
   ## Summary
   
   <Describe what the PR does and how to test. Photos and videos are recommended.>
   
   ## Related Linear tickets, Github issues, and Community forum posts
   
   
   
   
   ## Review / Merge checklist
   
   - [ ] PR title and summary are descriptive. ([conventions](../blob/master/.github/pull_request_title_conventions.md))
   - [ ] [Docs updated](https://github.com/n8n-io/n8n-docs) or follow-up ticket created.
   - [ ] Tests included.
   - [ ] PR Labeled with `release/backport` (if the PR is an urgent fix that needs to be backported)
   EOF
   )"
   

PR 本文のガイドライン

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

サマリーセクション

• PR の内容を説明します
• 変更をテストする方法を説明します
• UI の変更にはスクリーンショット／動画を含めます

関連リンクセクション

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

チェックリスト

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

• 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

変更履歴エントリーなし

refactor(core): Simplify error handling (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].+[^.]$

主な検証ルール：

• タイプは許可されたタイプのいずれかである必要があります
• スコープは任意ですが、指定する場合は括弧で囲む必要があります
• 破壊的変更を示す感嘆符はコロンの前に置きます
• サマリーは大文字で始める必要があります
• サマリーの末尾にピリオドを付けてはいけません

計画セクション

.claude/plans/ に一致する計画ファイルがあり、ユーザーがその記載を承認した場合は、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、テスト名、コードコメントのいずれにも、脆弱性を示唆する内容が含まれていないこと。