2ykwang Write PR
Turn the current branch's changes into a PR title and body that match the project's existing conventions. Analyze git history and diffs for intent, not just file names.
Use this skill when
- Writing or drafting a pull request description for the current branch
- Generating a PR title that matches the project's commit/PR style
- Filling in a PR template based on actual code changes
Do not use this skill when
- The request is to actually open or push a pull request
- There are no commits ahead of the base branch
- The user only wants a commit message, not a PR description
This skill is read-only. Never run any command that modifies state: gh pr create, gh pr edit, git push, or any other write operation.
Context
The user wants a ready-to-use PR title and body based on what changed in the current branch. Focus on intent and impact, not raw diff output. Respect the project's existing PR style.
Instructions
Step 1: Detect Base Branch
If $ARGUMENTS is provided, use it as the base branch.
Otherwise, auto-detect in this order:
- Run
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null— extract branch name (e.g.,origin/main→main) - If that fails, check which of
main,master,developexists:git branch -r | grep -E 'origin/(main|master|develop)' - Use the first match found
Step 2: Collect Change Information
Run these commands in order:
git log <base>..<HEAD> --oneline
git diff <base>...<HEAD> --stat
git diff <base>...<HEAD> --shortstat
Use --shortstat output (e.g., 12 files changed, 340 insertions(+), 50 deletions(-)) to determine diff size:
- If changed files ≤ 20 AND insertions+deletions ≤ 500: read the full diff with
git diff <base>...<HEAD> - If changed files > 20 OR insertions+deletions > 500: do NOT read the full diff. From the
--statoutput, identify the file with the most changes per directory/module and read only those representative files
Step 3: Find PR Template
This step is mandatory. Do not skip or assume the file does not exist.
Attempt to read all paths below in parallel using a file read tool:
.github/PULL_REQUEST_TEMPLATE.md.github/pull_request_template.mddocs/pull_request_template.mdPULL_REQUEST_TEMPLATE.md
Also check if .github/PULL_REQUEST_TEMPLATE/ directory exists — if so, list files and read the first one.
Use the first path that successfully returns content.
If a template file is successfully read:
- Use its structure exactly as-is for the PR body
- Preserve all sections, headings, and HTML comments (
<!-- ... -->) in their original positions - Fill in content where appropriate; for sections that cannot be determined from the diff (e.g., Screenshots, Related Issues), leave the original placeholder or HTML comment intact — do not delete or summarize them
- Do not reorder, merge, or omit any section
If all paths fail (file not found): use this default structure:
## Summary
<!-- What does this PR do and why? -->
## Changes
<!-- Key changes made -->
## Test Plan
<!-- How was this tested? -->
Step 4: Identify PR Title Style
Run:
gh pr list --state merged --limit 10 --json title 2>/dev/null
If gh returns results, analyze the title patterns (e.g., feat: ..., [PROJ-123] ..., Fix: ...).
If gh fails for any reason (not installed, auth error, not a GitHub repo), fall back to:
git log --oneline -20
Extract the dominant pattern from commit messages.
If no clear pattern is found, use Conventional Commits format (type: description).
Step 5: Write PR Content
Title:
- If the style detected in Step 4 is clear and consistent: produce 1 title
- If the style is ambiguous or mixed: produce 2–3 title candidates, clearly labeled
PR Body:
- Use the template structure from Step 3
- Fill each section based on the change analysis from Step 2
- Focus on why the change was made, not just what files changed
- Flag these explicitly if present in the diff:
- Breaking changes (API/interface changes, removed fields)
- New dependencies added
- Architecture or structural changes
- Do not paste raw diff or file lists into the body
- For sections that cannot be filled (e.g., Screenshots, Demo, Related Issues): keep the original HTML comment or placeholder from the template — do not delete the section
Output Format
Present the output in this order:
Title
<single best title>
(If ambiguous, list alternatives labeled Alt 1, Alt 2)
PR Body
<filled-in PR body — exact template structure preserved>
Branch:
<base>←<current>· Commits: N · Files changed: N