n8n-create-pr

# Create Pull Request Creates GitHub PRs with titles that pass n8n's `check-pr-title` CI validation. ## PR Title Format ``` <type>(<scope>): <summary> ``` ### Types (required) | Type | Description | Changelog | |------------|--------------------------------------------------|-----------| | `feat` | New feature | Yes | | `fix` | Bug fix | Yes | | `perf` | Performance improvement | Yes | | `test` | Adding/correcting tests | No | | `docs` | Documentation only | No | | `refactor` | Code change (no bug fix or feature) | No | | `build` | Build system or dependencies | No | | `ci` | CI configuration | No | | `chore` | Routine tasks, maintenance | No | ### Scopes (optional but recommended) - `API` - Public API changes - `benchmark` - Benchmark CLI changes - `core` - Core/backend/private API - `editor` - Editor UI changes - `engine` - New workflow execution engine v2 (@n8n/engine package) - `* Node` - Specific node (e.g., `Slack Node`, `GitHub Node`) ### Summary Rules - Use imperative present tense: "Add" not "Added" - Capitalize first letter - No period at the end - No ticket IDs (e.g., N8N-1234) - Add `(no-changelog)` suffix to exclude from changelog ## Steps 1. **Check current state**: ```bash git status git diff --stat git log origin/master..HEAD --oneline ``` 2. **Check for implementation plan**: Look for a plan file in the repository plan directories (`.claude/plans/` or `.agents/plans/` when present) that matches the current branch's ticket ID (e.g. if branch is `scdekov/PAY-1234-some-feature`, check for `PAY-1234.md`). If a plan file exists, ask the user whether they want to include it in the PR description as a collapsible `<details>` section (see Plan Section below). Only include the plan if the user explicitly approves. 3. **If this is a security fix**, audit every public-facing artifact before proceeding (see Security Fixes below). 4. **Analyze changes** to determine: - Type: What kind of change is this? - Scope: Which package/area is affected? - Summary: What does the change do? 5. **Push branch if needed**: ```bash git push -u origin HEAD ``` 6. **Create PR** using gh CLI. Read `.github/pull_request_template.md` as the body structure, then populate each section with actual content before creating the PR: - **Summary**: describe what the PR does - **How to test**: describe how to test the changes. Include an example workflow if appropriate - **Related tickets**: add the Linear ticket URL (`https://linear.app/n8n/issue/[TICKET-ID]`) and any GitHub issue links - **Checklist**: keep as-is from the template - Add a "🤖 PR Summary generated by AI" at the end of the body ```bash gh pr create --draft --title "<type>(<scope>): <summary>" --body "$(cat <<'EOF' <populated body based on pull_request_template.md> EOF )" ``` ## PR Body Guidelines Based on `.github/pull_request_template.md`: Write the PR body in ASD-STE100 Simplified Technical English: use short sentences, the active voice, and one instruction for each sentence. ### Summary Section - Describe what the PR does - Include screenshots/videos for UI changes ### How to test Section - Explain how to test the changes - Include an example workflow if appropriate - If the feature is gated in a default n8n instance (requires a non-default module via `N8N_ENABLED_MODULES`, an enterprise license, a feature flag, or similar), note which env vars/license are needed so the tester can deploy a correctly configured instance ### Related Links Section - Link to Linear ticket: `https://linear.app/n8n/issue/[TICKET-ID]` - Link to GitHub issues using keywords to auto-close: - `closes #123` / `fixes #123` / `resolves #123` - Link to Community forum posts if applicable ### Checklist All items should be addressed before merging: - The human author of the PR has checked the "I have seen this code, I have run this code, and I take responsibility for this code." checkbox - PR title follows conventions - Docs updated or follow-up ticket created - Tests included (bugs need regression tests, features need coverage) - `release/backport` label added if urgent fix needs backporting ## Examples ### Feature in editor ``` feat(editor): Add workflow performance metrics display ``` ### Bug fix in core ``` fix(core): Resolve memory leak in execution engine ``` ### Node-specific change ``` fix(Slack Node): Handle rate limiting in message send ``` ### Breaking change (add exclamation mark before colon) ``` feat(API)!: Remove deprecated v1 endpoints ``` ### No changelog entry ``` refactor(core): Simplify error handling (no-changelog) ``` ### No scope (affects multiple areas) ``` chore: Update dependencies to latest versions ``` ## Validation The PR title must match this pattern: ``` ^(feat|fix|perf|test|docs|refactor|build|ci|chore|revert)(\([a-zA-Z0-9 ]+( Node)?\))?!?: [A-Z].+[^.]$ ``` Key validation rules: - Type must be one of the allowed types - Scope is optional but must be in parentheses if present - Exclamation mark for breaking changes goes before the colon - Summary must start with capital letter - Summary must not end with a period ## Plan Section If a matching plan file was found in a repository plan directory and the user has approved including it, add a collapsible section at the end of the PR body (after the checklist, before `EOF`): ```markdown <details> <summary>Implementation plan</summary> <!-- paste plan file contents here --> </details> ``` ## Security Fixes **This repo is public.** Never expose the attack vector in any public artifact. Describe **what the code does**, not what threat it prevents. | Artifact | BAD | GOOD | |---|---|---| | Branch | `fix-sql-injection-in-webhook` | `fix-webhook-input-validation` | | PR title | `fix(core): Prevent SSRF` | `fix(core): Validate outgoing URLs` | | Commit msg | `fix: prevent denial of service` | `fix: add payload size validation` | | PR body | *"attacker could trigger SSRF…"* | *"validates URL protocol and host"* | | Linear ref | URL with slug (leaks title) | URL without slug or ticket ID only | | Test name | `'should prevent SQL injection'` | `'should sanitize query parameters'` | **Before pushing a security fix, verify:** no branch name, commit, PR title, PR body, Linear URL, test name, or code comment hints at the vulnerability. **When in doubt, check the Linear issue for possible extra precautions**