describe_pr
starsforks
How to install describe_pr?
parcadei/continuous-claude-v3/describe_pr
$npx -y skills add parcadei/Continuous-Claude-v3 --skill describe_prGenerate comprehensive PR descriptions following repository templates
SKILL.md
| 1 | # Generate PR Description |
| 2 | |
| 3 | You are tasked with generating a comprehensive pull request description following the repository's standard template. |
| 4 | |
| 5 | ## Steps to follow: |
| 6 | |
| 7 | 1. **Read the PR description template:** |
| 8 | - First, check if `thoughts/shared/pr_description.md` exists |
| 9 | - If it doesn't exist, inform the user they need to create a PR description template at `thoughts/shared/pr_description.md` |
| 10 | - Read the template carefully to understand all sections and requirements |
| 11 | |
| 12 | |
| 13 | 2. **Identify the PR to describe:** |
| 14 | - Check if the current branch has an associated PR: `gh pr view --json url,number,title,state 2>/dev/null` |
| 15 | - If no PR exists for the current branch, or if on main/master, list open PRs: `gh pr list --limit 10 --json number,title,headRefName,author` |
| 16 | - Ask the user which PR they want to describe |
| 17 | |
| 18 | 3. **Check for existing description:** |
| 19 | - Check if `thoughts/shared/prs/{number}_description.md` already exists |
| 20 | - If it exists, read it and inform the user you'll be updating it |
| 21 | - Consider what has changed since the last description was written |
| 22 | |
| 23 | 4. **Gather comprehensive PR information:** |
| 24 | - Get the full PR diff: `gh pr diff {number}` |
| 25 | - If you get an error about no default remote repository, instruct the user to run `gh repo set-default` and select the appropriate repository |
| 26 | - Get commit history: `gh pr view {number} --json commits` |
| 27 | - Review the base branch: `gh pr view {number} --json baseRefName` |
| 28 | - Get PR metadata: `gh pr view {number} --json url,title,number,state` |
| 29 | |
| 30 | 4b. **Gather reasoning history (if available):** |
| 31 | - Check if reasoning files exist: `ls .git/claude/commits/*/reasoning.md 2>/dev/null` |
| 32 | - If they exist, aggregate them: `bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main` |
| 33 | - This shows what approaches were tried before the final solution |
| 34 | - Save the output for inclusion in the PR description |
| 35 | |
| 36 | 5. **Analyze the changes thoroughly:** (ultrathink about the code changes, their architectural implications, and potential impacts) |
| 37 | - Read through the entire diff carefully |
| 38 | - For context, read any files that are referenced but not shown in the diff |
| 39 | - Understand the purpose and impact of each change |
| 40 | - Identify user-facing changes vs internal implementation details |
| 41 | - Look for breaking changes or migration requirements |
| 42 | |
| 43 | 6. **Handle verification requirements:** |
| 44 | - Look for any checklist items in the "How to verify it" section of the template |
| 45 | - For each verification step: |
| 46 | - If it's a command you can run (like `make check test`, `npm test`, etc.), run it |
| 47 | - If it passes, mark the checkbox as checked: `- [x]` |
| 48 | - If it fails, keep it unchecked and note what failed: `- [ ]` with explanation |
| 49 | - If it requires manual testing (UI interactions, external services), leave unchecked and note for user |
| 50 | - Document any verification steps you couldn't complete |
| 51 | |
| 52 | 7. **Generate the description:** |
| 53 | - Fill out each section from the template thoroughly: |
| 54 | - Answer each question/section based on your analysis |
| 55 | - Be specific about problems solved and changes made |
| 56 | - Focus on user impact where relevant |
| 57 | - Include technical details in appropriate sections |
| 58 | - Write a concise changelog entry |
| 59 | - **If reasoning files were found (from step 4b):** |
| 60 | - Add an "## Approaches Tried" section before "## How to verify it" |
| 61 | - Include the aggregated reasoning showing failed attempts and what was learned |
| 62 | - This helps reviewers understand the journey, not just the destination |
| 63 | - Ensure all checklist items are addressed (checked or explained) |
| 64 | |
| 65 | 8. **Save the description:** |
| 66 | - Write the completed description to `thoughts/shared/prs/{number}_description.md` |
| 67 | - Show the user the generated description |
| 68 | |
| 69 | 9. **Update the PR:** |
| 70 | - Update the PR description directly: `gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md` |
| 71 | - Confirm the update was successful |
| 72 | - If any verification steps remain unchecked, remind the user to complete them before merging |
| 73 | |
| 74 | ## Important notes: |
| 75 | - This command works across different repositories - always read the local template |
| 76 | - Be thorough but concise - descriptions should be scannable |
| 77 | - Focus on the "why" as much as the "what" |
| 78 | - Include any breaking changes or migration notes prominently |
| 79 | - If the PR touches multiple components, organize the description accordingly |
| 80 | - Always attempt to run verification commands when possible |
| 81 | - Clearly communicate which verification steps need manual testing |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
