summary
Skill262 starsChanged 2 months agoApache-2.0View on GitHub
Generate a concise implementation summary for a PR description
We split this skill into the rules it gives an agent
20 rules. 0 are common, 11 are distinctive, and 9 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Read AGENTS.md first. It is the canonical project guide for this repository.
- Distinctive: line 13
Run git diff main...HEAD --stat and git log main..HEAD --oneline to understand all changes on this branch
- Distinctive: line 14
Read the changed files to understand what was implemented and why
- Distinctive: line 16
Write a summary suitable for a GitHub PR description
- Very specific: line 22
Do NOT use any headings (#, ##, ###, etc.) — structure the summary with bold labels and line breaks instead
- Very specific: line 23
Use bold for section labels (e.g., What:, Why:, Changes:)
- Distinctive: line 24
Use backtick-wrapped inline code for file names, config keys, commands, and identifiers
- Very specific: line 25
Use markdown bullet points (-) for listing changes
- Distinctive: line 26
Use numbered lists for verification steps
- Very specific: line 27
Use text for hyperlinks when referencing issues or external resources
- Very specific: line 28
Start with What: — a one-line statement explaining the change
- Very specific: line 29
Follow with Why: — 2-3 sentences max explaining the motivation
- Very specific: line 31
If there are new tests, add Tests: with one line describing coverage
- Distinctive: line 33
Keep the total summary under 30 lines
- Distinctive: line 34
Do not repeat file paths or class names unnecessarily
- Distinctive: line 36
Write in present tense, active voice
- Distinctive: line 40
Do NOT print the summary to the conversation
- Very specific: line 41
Only save it to the file and tell the user where it was saved: "Summary saved to plans/<branch-name>-summary.md"
- Very specific: line 45
Use headings (#, ##, ###) anywhere in the summary
- Distinctive: line 46
Use tables or badges
“Common” is measured: kept by at least 6 in 10 of the 9 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
Generate a concise implementation summary for a PR description.
Read AGENTS.md first. It is the canonical project guide for this repository.
Steps:
- First, run the
/docsskill to ensure documentation is up to date with the branch changes - Run
git diff main...HEAD --statandgit log main..HEAD --onelineto understand all changes on this branch - Read the changed files to understand what was implemented and why
- Get the current branch name:
git rev-parse --abbrev-ref HEAD - Write a summary suitable for a GitHub PR description
- Save the raw markdown summary (without the wrapping code fence) to
plans/<branch-name>-summary.md, replacing any/in the branch name with-
Summary format rules:
- The summary must be GitHub-flavored markdown that renders nicely in a PR description
- Do NOT use any headings (
#,##,###, etc.) — structure the summary with bold labels and line breaks instead - Use
**bold**for section labels (e.g.,**What:**,**Why:**,**Changes:**) - Use backtick-wrapped inline code for file names, config keys, commands, and identifiers
- Use markdown bullet points (
-) for listing changes - Use numbered lists for verification steps
- Use
[text](url)for hyperlinks when referencing issues or external resources - Start with
**What:**— a one-line statement explaining the change - Follow with
**Why:**— 2-3 sentences max explaining the motivation - Include
**Changes:**— key changes as bullet points (no nested bullets) - If there are new tests, add
**Tests:**with one line describing coverage - End with
**How to verify:**— concrete steps as a numbered list - Keep the total summary under 30 lines
- Do not repeat file paths or class names unnecessarily
- Focus on behavior changes, not implementation details
- Write in present tense, active voice
Output rules:
- Do NOT print the summary to the conversation
- Only save it to the file and tell the user where it was saved: "Summary saved to
plans/<branch-name>-summary.md"
Do NOT:
- Use headings (
#,##,###) anywhere in the summary - Use tables or badges
- List every single file changed
- Include generic boilerplate like "This PR adds..."
- Add emojis
- Over-explain things that are obvious from the diff
- Print the summary content in the conversation output
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- isas1/skills★ 210same name
- saksham10arora-dotcom/everything-claude-codex★ 24same name
- yarikleto/claude-teacher-plugin★ 9same name
- geneontology/go-skills★ 1same name
- robo311/devflow★ 1same name
- timsvoice/skills★ 1same name
- Dev-PGVAA/skills★ 0same name
- kys42/claude-skills★ 0same name
- postproxy/postproxy-claude-plugin★ 0same name
- TechHU-GS/cc-discipline★ 0same 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 repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- address-reviewSkill
- commitSkill
- docsSkill
- implementSkill
- issueSkill
- lintSkill
- sink-paritySkill
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.