File a pull request on GitHub with a structured body, linked issues, and acceptance criteria. Use when the user says "file a PR", "open a PR", "create a PR", or wants to submit a feature branch for review.
Create a well-structured GitHub PR from the current feature branch. Gather
context from the branch, commits, linked issues, and plan files, then file
the PR with a single gh pr create call.
Before building the PR, look for local guidelines that override or extend this skill's defaults:
# PR template — if present, use it as the body skeleton instead of the default template
cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null \
|| cat .github/pull_request_template.md 2>/dev/null \
|| cat docs/pull_request_template.md 2>/dev/null \
|| cat PULL_REQUEST_TEMPLATE.md 2>/dev/null
# Contributing guide — scan for PR-specific rules
cat CONTRIBUTING.md 2>/dev/null | head -200
If a PR template exists, use it as the body structure. Fill in each section from the gathered context. Only fall back to the default template below when no repo template is found.
If a CONTRIBUTING.md exists, scan it for:
npm run lint")master")Incorporate any project-specific requirements into the PR body and title. When the repo's conventions conflict with this skill's defaults, the repo wins.
git rev-parse --abbrev-ref HEAD # feature branch
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' # base (usually main)
If the branch isn't pushed yet, push it first:
git push -u origin <branch>
git log --oneline main..<branch> — understand what changed.#N references. Run gh issue view <N> --json title,body for the linked issue..plans/<N>-<slug>.md exists for the linked issue, read the acceptance criteria from it.git diff --stat main..<branch> — summarize files changed.Use the repo's PR template if one was found in step 1. Otherwise, use this default template:
## Closes #<N>
<1-2 sentence summary of what this PR delivers.>
### What's in this PR
<Concise description of the implementation. Use bullet points, tables, or
short paragraphs — whatever fits the change. Cover:>
- What was built
- Key design decisions
- Notable APIs or types introduced
### Tests
<What was validated before filing. Include the actual commands and results
so reviewers can reproduce without guessing.>
- **Lint**: `<command>` — pass / N issues
- **Unit tests**: `<command>` — N/N passing
- **Manual checks**: <any ad-hoc verification performed>
### Acceptance criteria
- [x] Criterion 1
- [x] Criterion 2
- ...
Guidelines:
## Closes #N line must be the first line so GitHub auto-links.[x] if the implementation satisfies them (it should, or the PR isn't ready).Use conventional commit style matching the primary change type, unless the repo's CONTRIBUTING.md or PR template specifies a different convention:
type(scope): short imperative description
feat, fix, chore, docs, refactor, test — infer from the commits.store, agents, rpc-client).gh pr create \
--title "<title>" \
--body-file - \
--base <base> \
--head <branch> <<'EOF'
<body>
EOF
Report the resulting PR URL to the user.
Co-Authored-By trailer in the PR body.