How do I install the Pr Creation skill?

Run npx skillmds@latest add gitextensions/pr-creation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pr Creation safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pr Creation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pr Creation free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pr Creation?

gitextensions (@gitextensions) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Creation by gitextensions — Agent Skill

Name: Pr Creation
Author: gitextensions

Pr Creation

**EXECUTION (runbook) SKILL** — Prepare a Git Extensions change for a pull request so it passes CI. USE FOR: "create a PR", "get this ready to push", pre-commit/pre-push checklist, writing a conventional-commit message. DO NOT USE FOR: designing the change itself or explaining code. Triggers: "prepare a PR", "ready to commit", "pre-PR checklist", "write the commit message".

File contents

PR Creation (runbook)

A deterministic checklist to make a change merge-ready. Do the steps in order; STOP on any failure.

Prechecks

Confirm you're on a feature branch (not master) with a descriptive name.
Confirm the working tree contains only intended changes (git status).

Build & test (gates)

Build clean: dotnet build /v:q — no errors, no new analyzer/StyleCop warnings.
Run the associated tests locally — MANDATORY before any push. Identify the tests covering your change and run them (dotnet test <project> --filter "FullyQualifiedName~<Type>"), then run the affected project(s) in full. All green. NEVER push untested changes and let CI be the first run — it wastes CI compute and slows feedback. If some path can't be exercised locally (e.g. an arch-specific case), state explicitly what was and wasn't verified. See testing-guide.

Localization gate (MUST if UI changed)

If you added/changed any form, control, menu/toolbar item, or TranslationString: run .\update-loc.cmd from the repo root and stage the regenerated English.xlf. CI fails if it's stale. See translation-system.

Commit

Use Conventional Commits (e.g. feat:, fix:, docs:, perf:, refactor:).
If any file under src/app/GitExtensions.Extensibility/ changed, note the plugin interface version impact in the commit message.
Create a new commit (do not amend published commits).

Postchecks (STOP conditions)

NEVER leave fixup! / squash! commits on the branch — the git workflow blocks merge. Autosquash locally.
Ensure the CLA is signed (the cla-check workflow gates it).
Files MUST be CRLF and satisfy .editorconfig/StyleCop.
Do not use --no-verify or disable CI checks to force a pass — fix the cause.

Do NOT push unless explicitly asked

Prepare the commit(s); only run git push when the user explicitly requests it.

---name: pr-creationdescription: **EXECUTION (runbook) SKILL** — Prepare a Git Extensions change for a pull request so it passes CI. USE FOR: "create a PR", "get this ready to push", pre-commit/pre-push checklist, writing a conventional-commit message. DO NOT USE FOR: designing the change itself or explaining code. Triggers: "prepare a PR", "ready to commit", "pre-PR checklist", "write the commit message".---# PR Creation (runbook)A deterministic checklist to make a change merge-ready. Do the steps in order; STOP on any failure.## Prechecks1. Confirm you're on a feature branch (not `master`) with a descriptive name.2. Confirm the working tree contains only intended changes (`git status`).## Build & test (gates)3. **Build clean:** `dotnet build /v:q` — no errors, no new analyzer/StyleCop warnings.4. **Run the associated tests locally — MANDATORY before any push.** Identify the tests covering your change and run them (`dotnet test <project> --filter "FullyQualifiedName~<Type>"`), then run the affected project(s) in full. All green. **NEVER** push untested changes and let CI be the first run — it wastes CI compute and slows feedback. If some path can't be exercised locally (e.g. an arch-specific case), state explicitly what was and wasn't verified. See [testing-guide](../../copilot-docs/L2-core-platform/testing-guide.md).## Localization gate (MUST if UI changed)5. If you added/changed any form, control, menu/toolbar item, or `TranslationString`: run `.\update-loc.cmd` from the repo root and stage the regenerated [English.xlf](../../../src/app/GitUI/Translation/English.xlf). **CI fails if it's stale.** See [translation-system](../../copilot-docs/L2-core-platform/translation-system.md).## Commit6. Use **Conventional Commits** (e.g. `feat:`, `fix:`, `docs:`, `perf:`, `refactor:`).7. If any file under `src/app/GitExtensions.Extensibility/` changed, **note the plugin interface version impact** in the commit message.8. Create a **new** commit (do not amend published commits).## Postchecks (STOP conditions)- **NEVER** leave `fixup!` / `squash!` commits on the branch — the `git` workflow blocks merge. Autosquash locally.- Ensure the CLA is signed (the `cla-check` workflow gates it).- Files MUST be CRLF and satisfy `.editorconfig`/StyleCop.- Do **not** use `--no-verify` or disable CI checks to force a pass — fix the cause.## Do NOT push unless explicitly askedPrepare the commit(s); only run `git push` when the user explicitly requests it.

Frequently asked questions