Atlas / Skills / n8n-io / Create Pr

Create PrCAUTION

skills/n8n-io/create-pr

Agent skill by n8n-io · ai · apis · automation · Audited 2026-10-21

Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.

Verdict

CAUTION

Grade

Trust score

89 /100

Version

—

Hosts

—

License

NOASSERTION

Stars

208,209

Overview

Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations.

Read from source at commit 99524b0df8e9OBSERVED · 2026-10-21

What it tells the agent

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: n8n:create-pr
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
- `engine` - New workflow execution engine v2 (@n8n/engine package & engine-v2 module in cli)
- `* 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, unless the type already excludes it

## 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
   - **Why**: explain why the change is needed (see Why below)
   - **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

   Before you create the PR, proofread the body with these checks. Rewrite
   each sentence that fails a check:
   1. The Summary and the Why together are under the word budget. If not,
      first remove the details that the reviewer reads in the diff, then
      shorten the Why.
   2. Each sentence names who does what: a component, a process, or a person
      as the subject, with a plain technical verb.
   3. Each domain term has a plain definition where it first appears.
   4. Each sentence is true for the diff.

   When a later commit changes a fact in the body, update 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 for a reviewer who does not know this area of the code. The reviewer
must understand the change before they open the diff. Use ASD-STE100
Simplified Technical English: short sentences, active voice.
1. Keep the Summary and the Why together under about 200 words. A small PR
   needs much less.
2. Define each domain term in plain words where it first appears. Do not use
   a ticket ID or an internal name as an explanation.
3. Leave out details that the reviewer reads in the diff: error cases, status
   codes, renamed fields, the order of calls, file lists, test names. Mention
   one only when it changes behaviour that a reviewer could miss. Also leave
   out what reviewers already know (framework behaviour).
4. Use plain technical verbs, not metaphors ("passes the value", not
   "hands the value" or "lets the value through").

### Summary: what the PR does
1. Start with one to three sentences of background for a reader who is new to
   the area. Then state what the PR does.
2. Write **prose** about behaviour, not a list of code edits. Name a class or
   a function when it represents an essential/core concept and it helps
   the reader to navigate the change.
3. If the PR changes no product code, say so in the first sentence
   (for example: "This PR only adds tests.").
4. Do not justify the change here. The justification goes in the Why.
5. Include screenshots or videos for UI changes.

### Why: the reasoning
Always fill the `## Why` section. The Summary and the core of the
Why are what the reviewer needs most. Keep the core short:
1. Do not repeat the Summary.
2. State the problem or the constraint that makes t

Trust audit

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

Layer	What it checks	Result
L0	Provenance & inventory	WARN
L1	Static analysis of the code	PASS
L2	Instruction surface (what it tells the agent)	PASS
L3	Class-specific surface	PASS
L4	Behavioural (sandbox)	SKIPPED

What the source does

Filesystem: none-observed
Network: declared (2 observation(s))
Shell: none-observed
Dependencies: pinned
Secrets in source: none-found