write-pr-description
Skill2 starsChanged 8 months agoApache-2.0View on GitHub
Write or improve a GitHub pull request description. Use when the user asks to "write a PR description", "improve the PR description", "update the PR body", or provides a PR URL and asks for a better description. Keywords: PR description, pull request summary, PR body, PR writeup.
12 other projects use a version of this.
Adopted by
Most recently taken up by
- warpdotdev/common-skillstheir own version, first seen Oct 20, 2026
- ericmasiello/skillstheir own version, first seen Oct 20, 2026
- GGGODLIN/gggodlin-cc-harnesstheir own version, first seen Oct 20, 2026
- gspencergoog/skillstheir own version, first seen Oct 16, 2026
- zhouycheng/skillstheir own version, first seen Oct 13, 2026
- databricks/databricks-sdk-goword for word, first seen Oct 13, 2026
Used with
Projects with it also use grill-with-docs, grill-me and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MicrosoftSkillgrill-with-docs
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Also in 3 projects that use this
GoogleSkillgrill-me
A relentless interview to sharpen a plan or design.
Also in 4 projects that use this
NVIDIASkillresearch
Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.
Also in 3 projects that use this
- GoogleSkill
tdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 3 projects that use this
Other versions12 projects use a version of this.
Word for word · 1
- databricks/databricks-sdk-go★ 84100% same
Edited · 0
None found.
Wrote their own version · 11
- GitbookIO/gitbook★ 29ksame name
- Agenta-AI/agenta★ 4.9ksame name
- warpdotdev/common-skills★ 630same name
- tbhb/vale-ai-tells★ 118same name
- GGGODLIN/gggodlin-cc-harness★ 73same name
- gspencergoog/skills★ 2same name
- drown0315/flutter_pilot★ 1same name
- MaheshAwasare/claude-skills-pro★ 1same name
- yuvalshimoni/skills★ 1same name
- zhouycheng/skills★ 1same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository3 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/00-claude-context.mdcCursor rule
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 5 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 11 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 38
Before writing, answer these questions internally:
- Distinctive: line 50
Are there behavioral changes?: If not, say so explicitly — this reassures reviewers.
- Very specific: line 55
Use the structure defined in .github/PULL_REQUEST_TEMPLATE.md as the template.
- Distinctive: line 63
Be specific: Instead of "improves extensibility", say "allows internal tools to compose their own auth chain from individual credential …
- Distinctive: line 66
Use backticks for code references.
- Distinctive: line 67
State non-changes explicitly: If the PR is a refactor with no behavioral change, say "No behavioral changes.
- Very specific: line 76
Use the GitHub MCP tools or gh CLI to update the PR body with the new description.
“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Write PR Description
Generate a structured PR description that explains why the change exists, not just what files were touched.
When to use
- The user provides a PR URL and asks to write or improve its description.
- The user asks to draft a PR description for the current branch.
- An agent needs to open a PR and wants a high-quality description.
Workflow
Phase 1: Gather context
Collect all the information needed to understand the change:
- Read the PR metadata — title, current description, author, branch name.
- Read the full diff — understand every file changed, every function added or removed, every signature change. Do not skip files.
- Read surrounding code when needed — if the diff modifies an interface or a struct, read the full file to understand how the change fits into the existing architecture.
- Check for linked issues or docs — the PR or commit messages may reference issues, design docs, or RFCs that explain motivation.
Phase 2: Analyze the change
Before writing, answer these questions internally:
- What was the status quo before this PR? What limitation, bug, or missing capability existed?
- Why is this change needed now? What concrete problem does it solve? Who benefits?
- What are the key design decisions? Why was this approach chosen over alternatives?
- What is the new API surface? Any new public types, functions, or configuration options?
- What are the architectural changes? How does the internal structure change? What moves where? What gets refactored?
- Are there behavioral changes? If not, say so explicitly — this reassures reviewers.
Phase 3: Write the description
Use the structure defined in .github/PULL_REQUEST_TEMPLATE.md as the
template. The tone should be direct and technical. Write for a reviewer who is
familiar with the codebase but has not seen this change before.
Key principles:
- Lead with why, not what. The diff already shows the what. The description should explain the reasoning that is not visible in the code.
- Be specific. Instead of "improves extensibility", say "allows internal tools to compose their own auth chain from individual credential strategies".
- Name things. Reference actual types, functions, files, and config fields. Use backticks for code references.
- State non-changes explicitly. If the PR is a refactor with no behavioral change, say "No behavioral changes. Existing users are unaffected." This is valuable information for reviewers.
- Keep the summary to one or two sentences. It should be scannable.
- Use the motivation section to tell a story. What was the problem? Why couldn't it be solved before? What does this PR unlock?
Phase 4: Update the PR
Use the GitHub MCP tools or gh CLI to update the PR body with the new
description. Confirm with the user before pushing if unsure.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.