write-pr
Skill1 starsChanged 8 days agoMITView on GitHub
Use when you write or materially update a pull request body. The body states the change, the evidence and the merge risk. It does not review or merge.
8 other projects use a version of this.
Adopted by
Most recently taken up by
- adhamhaithameid/write-skillstheir own version, first seen Nov 8, 2026
- LeonardiFranco/skillstheir own version, first seen Nov 8, 2026
- hcaiano/skillstheir own version, first seen Oct 13, 2026
- ypxing/coding-crewtheir own version, first seen Oct 13, 2026
- MoonshotAI/kimi-codetheir own version, first seen Oct 8, 2026
- tldraw/tldrawtheir own version, first seen Oct 8, 2026
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- tldraw/tldraw★ 51ksame name
- MoonshotAI/kimi-code★ 8.2ksame name
- hcaiano/skills★ 3same name
- drewdrewthis/claude-skills★ 2same name
- jalbarrang/skills★ 2same name
- adhamhaithameid/write-skills★ 1same name
- LeonardiFranco/skills★ 1same name
- ypxing/coding-crew★ 1same name
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 repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apply-architectureSkill
- bootstrapSkill
- clarify-intentSkill
- code-reviewSkill
- map-workSkill
- plan-workSkill
- releaseSkill
- tdd-loopSkill
- triageSkill
- write-adrSkill
- writing-checkSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 10 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 7 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use when you write a pull request body, or when a material change makes the body wrong.
- Distinctive: line 22
Update the body after a material change to the implementation.
- Distinctive: line 26
Use the sections below. Keep each section as short as the change allows.
- Distinctive: line 31
Use one issue for one pull request.
- Distinctive: line 39
Add a small visual only when it makes the change easier to see.
- Distinctive: line 56
When tests prove the behavior, list those tests in Evidence.
- Distinctive: line 62
Consider the merge risk for every pull request.
- Distinctive: line 64
When the risk is low, write one short sentence and name how to undo the change.
- Distinctive: line 66
When the risk is not low, name the blast radius, compatibility, migration, rollback and mitigation.
- Distinctive: line 71
Put the issue link in this section.
“Common” is measured: kept by at least 6 in 10 of the 7 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 a pull request
Use when you write a pull request body, or when a material change makes the body wrong.
This skill governs the text of the pull request. It does not decide who may open the pull request. It does not give a verdict. It does not merge. Those rules stay in code review and review and merge.
Read writing. Use writing-check on the body.
When to refresh
Update the body after a material change to the implementation. Update it again before review.
Sections
Use the sections below. Keep each section as short as the change allows. Remove a section that would be empty.
The title is a conventional commit of 50 characters or fewer. See version control. Use one issue for one pull request. Link the issue. See review and merge.
Summary
State what changed and why it matters. Name the people who are affected, such as users or developers. Describe the behavior. Do not describe only the files.
Add a small visual only when it makes the change easier to see. You can use a diff sketch, pseudocode, a call tree, a file tree, a diagram or a screenshot. Do not require a visual for a trivial change. A trivial change can omit the visual.
Evidence
Separate three kinds of statement.
- Verified: you ran the check, or you read a result for this change. Give the result.
- Unverified: you did not run the check. Say so.
- Known risk: a risk that remains. Name it.
Name each required check that did not run as NOT RUN. Do not say that a check passed unless the result says that it passed.
A documentation-only change can have no test. Say why no test is needed.
When tests prove the behavior, list those tests in Evidence. Review and merge requires that list.
Risk and rollback
Consider the merge risk for every pull request.
When the risk is low, write one short sentence and name how to undo the change.
When the risk is not low, name the blast radius, compatibility, migration, rollback and mitigation. Do not use that long form when the risk is low.
References
Put the issue link in this section. Add any other link the reader needs. If the issue link is already in another section and you have no other link, remove this section.
Examples
These examples show the shape. They are not repository facts.
Small documentation change
Summary: The install page names the current release branch. A reader can follow the branch without a second document.
Evidence: No test. The change is documentation. The project check is NOT RUN.
Risk and rollback: Low risk. Revert this pull request.
References: Closes #12.
Tested code fix
Summary: A failed call runs at most three times. Before the change, the call retried with no limit. Callers receive the error after the third run.
Evidence: Verified: a test failed because the call retried past the third attempt. The same test passed after the limit. The project check passed. Unverified: this change was not run on a production host.
Risk and rollback: Low risk. Revert this pull request. The old retry behavior returns.
References: Closes #18.
High-risk change
Summary: The public client method gains a required argument. Existing callers do not compile until they pass the argument.
Evidence: Verified: the unit tests passed after the callers in this repository were updated. The migration check failed on one external example, and the failure is recorded. Unverified: the project check is NOT RUN. Known risk: callers outside this repository still use the old method.
Risk and rollback: The blast radius is every external caller of the method. Migration: each caller adds the argument. Rollback: revert this pull request before other projects release a version that calls the new method. Mitigation: the changelog names the argument and the old call.
References: Closes #24. See the versioning page.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.