---
title: "Create Pull Request"
description: "Creates GitHub PRs with titles that pass n8n's `check-pr-title` CI validation."
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/skill-1097
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:47:05.787Z
license: CC-BY-4.0
attribution: "Create Pull Request — Claudary (https://claudary.paisolsolutions.com/skills/skill-1097)"
---

# Create Pull Request
Creates GitHub PRs with titles that pass n8n's `check-pr-title` CI validation.

## Overview

---
description: Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
allowed-tools: Bash(git:*), Bash(gh:*), Read, Grep, Glob
---

# 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
- `* 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 `.claude/plans/`
   that matches the current branch's ticket ID (e.g. if branch is
   `scdekov/PAY-1234-some-feature`, check for `.claude/plans/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 and how to test it
   - **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`:

### Summary Section
- Describe what the PR does
- Explain how to test the changes
- Include screenshots/videos for UI changes

### 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 `.claude/plans/` 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**

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/skill-1097) · https://claudary.paisolsolutions.com