GitHub pull requests
Hard rules
- Never create a PR without an explicit user request
- A finished branch, plan, task, or job is not permission to create a PR
- Permission applies to one PR action; autonomous mode does not waive the gate
- Never include co-authors, AI attribution, or generated-by footers
- Never rewrite history before a PR: no
git rebase, commit --amend,
push --force, or --force-with-lease; push the branch as-is
Repository conventions
- Read target repository instructions and contribution docs
- Use the repository PR template when present
- Load
git-commit-message in pr-title mode to compose the title
- Detect the default base branch from the remote unless the user chose one
git-commit-message owns title format and scope inference. This skill adds no
merge-model convention.
Source of truth
- Build PR content from the complete branch diff and commit range against the
resolved base
- Count commits in the branch range before composing the PR
- For a one-commit branch, use that commit's subject and body as the PR title
and body without shortening or rewriting them
- A repository template may place the commit body inside required sections, but
preserve its wording and complete every required section
- For a multi-commit branch, treat individual commits, plans, and initial file
lists as incomplete summaries
- Detect uncommitted changes; they are not part of the PR
- Detect unpushed commits and whether the branch has an upstream
- Refresh branch, base, remote, diff, and push state before generating commands
Content
- Title for a one-commit branch: use the commit subject unchanged
- Title for a multi-commit branch: imperative, no more than 70 characters, and
lowercase after the colon
- Body with template: fill it without dropping required sections
- Body without template: use concise prose, bullets, or both
- Prefer a bullet when it conveys the same fact with fewer words
- Paragraphs: no more than 25 words each
- First paragraph: state only context that is clearer than a bullet
- Second paragraph: add only mandatory, important information not captured in
the first paragraph or bullets
- Never add a second paragraph for padding, hedging, or unnecessary explanation
- Third paragraph: add only mandatory, important information not captured in the
first two paragraphs or bullets
- Put one blank line between paragraphs and before the bullet list
- Keep bullet items consecutive, without blank lines between them
- Bullets: no more than 10 words
- State each fact once: in prose or a bullet, never both
- Describe only the merge-ready final state. Omit temporary status, pending
work, and anything expected to change or be removed before merge
- Omit standard, expected, or self-evident information
- Unless the user explicitly requests it, omit testing probes, strategies,
commands, validation methods, and validation results
- Standard Markdown only: no em-dashes or curly quotes
- Draft status: plain "create PR" means draft; ready requires an explicit
request
- Issue links: use repository conventions and closing keywords only for issues
this PR resolves
No-template body example:
Explain why the change matters and its impact.
- Describe reviewer-relevant behavior
- Call out important constraints or decisions
- Fixes #123
Include only relevant bullets. Use Fixes #123 for resolved issues and
Related: #123 for non-closing links, and Closes #123 for superseded PRs.
Workflow
- Resolve current branch, remote, upstream, base branch, and draft status
- Read the full
git diff <base>...HEAD and git log <base>..HEAD, then count
commits in that range
- Inspect uncommitted and unpushed state
- For one commit, reuse its subject and body; for multiple commits, load
git-commit-message in pr-title mode and compose from the complete branch
- Apply the repository template when present without shortening reused commit
content
- Show the exact title, body, upstream push command, and PR creation command
- Get approval before pushing or creating the PR
- After approval, run the shown commands with the title and body unchanged
- Pass multiline body content through
--body-file -
- Add
--draft unless the user explicitly requested a ready PR
- Return the PR URL from
gh pr create
Use a quoted heredoc to preserve multiline Markdown:
gh pr create --draft --base "main" --title "PR title" --body-file - <<'EOF'
- Describe the user-visible change
- Explain why the change matters
EOF
Replace example values with resolved values in actual commands. Shell-quote all
dynamic values for the active shell. Regenerate commands if the branch state or
content changes.
Compose-only requests
Return the title and body without pushing or creating a PR.
1---2name: create-pull-request3description: Compose and create GitHub pull requests with `gh` using the target repository's title, template, base-branch, and draft conventions. Load on explicit user intent to open, create, draft, or compose a pull request.4---56# GitHub pull requests78## Hard rules910- Never create a PR without an explicit user request11- A finished branch, plan, task, or job is not permission to create a PR12- Permission applies to one PR action; autonomous mode does not waive the gate13- Never include co-authors, AI attribution, or generated-by footers14- Never rewrite history before a PR: no `git rebase`, `commit --amend`,15 `push --force`, or `--force-with-lease`; push the branch as-is1617## Repository conventions18191. Read target repository instructions and contribution docs202. Use the repository PR template when present213. Load `git-commit-message` in `pr-title` mode to compose the title224. Detect the default base branch from the remote unless the user chose one2324`git-commit-message` owns title format and scope inference. This skill adds no25merge-model convention.2627## Source of truth2829- Build PR content from the complete branch diff and commit range against the30 resolved base31- Count commits in the branch range before composing the PR32- For a one-commit branch, use that commit's subject and body as the PR title33 and body without shortening or rewriting them34- A repository template may place the commit body inside required sections, but35 preserve its wording and complete every required section36- For a multi-commit branch, treat individual commits, plans, and initial file37 lists as incomplete summaries38- Detect uncommitted changes; they are not part of the PR39- Detect unpushed commits and whether the branch has an upstream40- Refresh branch, base, remote, diff, and push state before generating commands4142## Content4344- Title for a one-commit branch: use the commit subject unchanged45- Title for a multi-commit branch: imperative, no more than 70 characters, and46 lowercase after the colon47- Body with template: fill it without dropping required sections48- Body without template: use concise prose, bullets, or both49- Prefer a bullet when it conveys the same fact with fewer words50- Paragraphs: no more than 25 words each51- First paragraph: state only context that is clearer than a bullet52- Second paragraph: add only mandatory, important information not captured in53 the first paragraph or bullets54- Never add a second paragraph for padding, hedging, or unnecessary explanation55- Third paragraph: add only mandatory, important information not captured in the56 first two paragraphs or bullets57- Put one blank line between paragraphs and before the bullet list58- Keep bullet items consecutive, without blank lines between them59- Bullets: no more than 10 words60- State each fact once: in prose or a bullet, never both61- Describe only the merge-ready final state. Omit temporary status, pending62 work, and anything expected to change or be removed before merge63- Omit standard, expected, or self-evident information64- Unless the user explicitly requests it, omit testing probes, strategies,65 commands, validation methods, and validation results66- Standard Markdown only: no em-dashes or curly quotes67- Draft status: plain "create PR" means draft; ready requires an explicit68 request69- Issue links: use repository conventions and closing keywords only for issues70 this PR resolves7172No-template body example:7374```markdown75Explain why the change matters and its impact.7677- Describe reviewer-relevant behavior78- Call out important constraints or decisions79- Fixes #12380```8182Include only relevant bullets. Use `Fixes #123` for resolved issues and83`Related: #123` for non-closing links, and `Closes #123` for superseded PRs.8485## Workflow86871. Resolve current branch, remote, upstream, base branch, and draft status882. Read the full `git diff <base>...HEAD` and `git log <base>..HEAD`, then count89 commits in that range903. Inspect uncommitted and unpushed state914. For one commit, reuse its subject and body; for multiple commits, load92 `git-commit-message` in `pr-title` mode and compose from the complete branch935. Apply the repository template when present without shortening reused commit94 content956. Show the exact title, body, upstream push command, and PR creation command967. Get approval before pushing or creating the PR978. After approval, run the shown commands with the title and body unchanged989. Pass multiline body content through `--body-file -`9910. Add `--draft` unless the user explicitly requested a ready PR10011. Return the PR URL from `gh pr create`101102Use a quoted heredoc to preserve multiline Markdown:103104```bash105gh pr create --draft --base "main" --title "PR title" --body-file - <<'EOF'106- Describe the user-visible change107- Explain why the change matters108EOF109```110111Replace example values with resolved values in actual commands. Shell-quote all112dynamic values for the active shell. Regenerate commands if the branch state or113content changes.114115## Compose-only requests116117Return the title and body without pushing or creating a PR.
carlos-algms