create-pull-request

CREATE-PULL-REQUEST — Pull Request Creation Skill

Purpose: operational rulebook for drafting the title and description of a Pull Request (or Merge Request) grounded in the repository's actual git diff — always following first the template the repository itself defines, and only in its absence the improved default template in this file.

Golden rule: the repository's template wins. This file is the default, never an override. If the repo defines its own PR template, you fill that one and do not mix it with the one here.

---

0. How to Use This File

1. Before writing anything, determine the real scope of the changes in git (§3, Step 1): the description must be anchored to the diff, not to memory.
2. Look for the repo's template (§3, Step 2). If it exists: use it exactly as it is. If not: use the default template in §4 (copy its shape, don't improvise).
3. Fill in only what you can verify — from the diff, from commands you ran, or from what the user said explicitly. Anything unverifiable is omitted or marked as pending. It is never invented.
4. Deliver per §3, Step 6: the result is always saved as a numbered Markdown file in the .pr-suggestions/ folder, and the PR is never opened on your own.

---

1. Non-Negotiables

• Never fabricate issue numbers, file paths, changes, test results, executed commands, screenshots, or breaking-change claims without evidence. A Closes #123 that doesn't come from the repo or the user is a serious error.
• The repo's template always wins. If the repository defines its own PR template, or its CONTRIBUTING.md specifies the format, follow that. This file is the default for repos with no stated convention, not an override.
• Every "Change" listed must exist in the actual diff. Describing a change that was never made is fabrication — each bullet under Changes made must map to a real behavioral/functional difference in the diff.
• Never report tests you did not run. Write only results whose output you read in the session. If not run, write Not run — pending in CI and leave the checkbox unchecked.
• No AI co-authorship. No Co-Authored-By: <AI> or any mention of this kind in the PR body.
• No placeholders in the final output. An empty section is removed (no dangling [complete] or <!-- ... -->); an empty bullet is deleted.
• Use the repository's language. Write the description in the repo's dominant language (documentation, commit history, previous PR titles). One language per PR; never mix.
• Never reinterpret already established facts. If a commit says fix(auth): ..., the PR reflects exactly that; don't rewrite it as something broader or different to "sound better."
• Always write the PR description to a Markdown file in .pr-suggestions/. The description is never delivered only in the terminal or saved anywhere else; the folder (and file) is created if missing.
• Number every PR file sequentially. Files are PR-001.md, PR-002.md, … — one per suggestion, never overwritten and never reused. The highest number is always the most recent PR created.
• Never constrain paragraph width. No manual line wrapping/breaks inside paragraphs (e.g. hard-wrapping at 80 columns); write each paragraph as a single continuous line and let the renderer wrap it.
• Always suggest a branch name. Every PR description includes a proposed branch name (§3, Step 3), following the repo's own naming convention when one is detectable, or the <type>/<scope>-<short-description> kebab-case default otherwise. Never skip it, and never invent one unrelated to the actual change.