Menu
Analyzes git diff and commit history to write PR title and description based on the project's PR template.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | write-pr |
| version | 0.0.3 |
| category | productivity |
| description | Analyzes git diff and commit history to write PR title and description based on the project's PR template. |
| argument-hint | [base-branch] |
You are a pull request writing expert who transforms code changes into clear, structured PR descriptions. Analyze git history and diffs to produce PR titles and bodies that match the project's existing conventions.
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.
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.
If $ARGUMENTS is provided, use it as the base branch.
Otherwise, auto-detect in this order:
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null — extract branch name (e.g., origin/main → main)main, master, develop exists: git branch -r | grep -E 'origin/(main|master|develop)'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:
git diff <base>...<HEAD>--stat output, identify the file with the most changes per directory/module and read only those representative filesThis 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.mdAlso 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:
<!-- ... -->) in their original positionsIf 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? -->
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).
Title:
PR Body:
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
Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Decide how elaborate to build something (simple vs. robust) and return a concrete, PoC-shaped proposal at that level — not over- or under-engineered, but right-sized. Use whenever someone is building something and the investment level is unclear: "quick or proper?", "MVP vs. real product", "is this over-engineering?", "how should I approach X?", "quick script vs. robust system", "how much architecture?", "how much do I build here?". Fires even without "poc" or "right-size" — any time effort and complexity of what to build are being weighed.
Trace git history of specific code — find when functions, patterns, or files were added, modified, or removed, and explain the intent behind each change.
Turn code changes into a single-file HTML code review report that pairs the diff with context a diff can't show — design decisions, rejected alternatives, tradeoffs, unfinished work — plus prioritized review points. Use when preparing for review after finishing a sizable change, refactor, or feature, or whenever the user asks for a review report, change report, or an HTML summary of their changes.
Turn code, specs, a PR, or the current conversation into a QA test-case list a non-developer can read and run, exported as CSV, a shareable HTML report, or both. Trigger when the user wants QA test cases, a test plan, a QA checklist, or a test-case CSV/HTML (e.g. "write test cases for this", "make a QA list"). Output uses behavior-and-scenario language, never code symbols like function names or file paths. Not for writing or running automated test code (pytest/jest), code review, or test-strategy docs.
Render an interactive HTML board for the user to pick among multiple comparable options side-by-side at once — engineering trade-offs, copy audits, action-item triage, architecture decisions, policy calls. Returns the picks (and optional hold/note flags) as a JSON file the agent can apply.