# Create Pull Request

> Create a GitHub Pull Request for Mapsui — covering title prefix conventions, PR type label selection, and the correct tool to use. Load this skill when you are ready to open a pull request.

- Skill: `mapsui/create-pull-request` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mapsui/create-pull-request`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mapsui/create-pull-request/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mapsui (https://skillmd.com/u/mapsui)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mapsui/create-pull-request

---


# Creating a Pull Request in Mapsui

Use this skill when you are ready to open a pull request. It covers the title format, label selection, and the tool to use.

---

## 0 — Verify the branch is ready (do this first)

> **Committing and pushing is always the user's responsibility.** Per the Copilot instructions: *never run `git commit`, `git push`, or any destructive git command unless the user explicitly asks.*

Before calling `mcp_github_create_pull_request`, verify that the expected changes are actually on the remote branch. Run:

```ps
git log origin/<branch> --oneline -10
```

and compare with what was implemented in this session. **If the branch on the remote does not contain the expected commits, stop and ask the user to push before continuing.**

### Warning signs that the user may not have pushed yet

- The most recent commit on the remote branch belongs to a completely different topic (e.g., work in this session was a bug fix, but the top commit on the remote is an old refactoring).
- The user just said something like "I created a new branch" — they may have created it locally without pushing.
- `git status` shows "Your branch is ahead of 'origin/…' by N commits".
- The remote branch does not exist at all (`git ls-remote --heads origin <branch>` returns nothing).

When in doubt, ask: *"Have you pushed your changes to the remote branch?"*

---

## 1 — Tool to use

Always create pull requests via **`github-pull-request_create_pull_request`** (the VS Code GitHub Pull Requests extension tool).  
Do **not** use `gh pr create` or any other CLI command.

> `mcp_github_create_pull_request` (the GitHub MCP server tool) may fail with "Permission Denied" depending on the token scope. If it does, fall back to `github-pull-request_create_pull_request` and tell the user which tool was actually used.

After creating the PR, add the PR type label via the `gh` CLI:
```ps
gh pr edit <number> --repo Mapsui/Mapsui --add-label "<label>"
```

---

## 2 — Title format

```
<prefix>: <short imperative summary>
```

- Use the **imperative mood** ("Add support for X", not "Added support for X").  
- Keep it concise — ideally under 72 characters.  
- The prefix is lowercase; the rest of the title uses sentence case.

### Prefix → PR type label mapping

| Title prefix | PR type label | When to use |
|---|---|---|
| `fix:` | `PR type: 🐛 Fix` | A bug fix or patch for existing functionality |
| `feat:` | `PR type: 🚀 Feature` | A new capability or enhancement that users benefit from |
| `refactor:` | `PR type: ♻️ Refactor` | Internal restructuring that doesn't change behavior or add features |
| `update:` | `PR type: 📦 Update` | Updates to third-party libraries, SDKs, NuGet packages |
| `perf:` | `PR type:⚡Performance` | A change that measurably improves speed, memory, or resource usage |
| `chore:` | `PR type: 🛠️ Chore` | Internal changes that don't affect end users (code cleanup, build tweaks) |
| `ci:` | `PR type: ⚙️ Infrastructure` | Changes to CI/CD pipelines, deployment scripts, config files, tooling |
| `sample:` | `PR type: 🧪 Sample` | Adding or updating a sample |
| `test:` | `PR type: ✅ Tests` | Adding or improving unit, integration, or regression tests without changing production code |
| `docs:` | `PR type: 📝 Documentation` | Changes to user guides, README, API docs, etc. |

> **Note on `feat:` vs `feature:`** — Use `feat:` (the conventional commits standard, dominant in .NET projects). Do not use `feature:`.

---

## 3 — Required fields

When calling `mcp_github_create_pull_request`, always provide:

| Field | Guidance |
|---|---|
| `title` | `<prefix>: <summary>` as above |
| `body` | Describe *what* changed, *why*, and reference any related issues with `Fixes #NNN` or `Relates to #NNN` |
| `labels` | The matching "PR type" label from the table above |
| `base` | `main` (the default branch) |
| `draft` | `false` unless the work is explicitly incomplete |

---

## 4 — Secondary labels

In addition to the "PR type" label, you may apply additional labels as appropriate:

| Label | When |
|---|---|
| `☢️ Experimental` | PR touches any `Mapsui.Experimental.*` package |
| `bug 🐛` | Companion to a bug report (issue side); not the same as `PR type: 🐛 Fix` |
| `documentation` | Supplementary docs label (distinct from PR type) |

These are **optional** and supplementary — they do not replace the PR type label.

---

## 5 — Release notes

The `release.yml` file categorises PRs by their "PR type" label for automated GitHub release notes. Choosing the correct label ensures the PR appears in the right section of the changelog.

| Release section | Label |
|---|---|
| 🐛 Fixes | `PR type: 🐛 Fix` |
| 🚀 Features | `PR type: 🚀 Feature` |
| ♻️ Refactor | `PR type: ♻️ Refactor` |
| 📦 Updates | `PR type: 📦 Update` |
| ⚡ Performance | `PR type:⚡Performance` |
| 🛠️ Chore | `PR type: 🛠️ Chore` |
| ⚙️ Infrastructure | `PR type: ⚙️ Infrastructure` |
| 🧪 Samples | `PR type: 🧪 Sample` |
| ✅ Tests | `PR type: ✅ Tests` |
| 📝 Documentation | `PR type: 📝 Documentation` |
| 💩 Other Changes | (catch-all for PRs with no recognised PR type label) |

---

## 6 — Example

A PR that fixes the tofu square rendering bug in vector tile street labels:

```
fix: DrawTextOnPath renders tofu square between words in street labels
```

- Labels: `PR type: 🐛 Fix`, `☢️ Experimental`  
- Body: describes root cause, references `Fixes #3346`  
- Base branch: `main`