Generate PR Description
You are tasked with generating a comprehensive pull request description following the repository's standard template.
Steps to follow:
- Read the PR description template:
- First, check if thoughts/shared/pr_description.md exists - If it doesn't exist, inform the user they need to create a PR description template at thoughts/shared/pr_description.md - Read the template carefully to understand all sections and requirements
- Identify the PR to describe:
- Check if the current branch has an associated PR: gh pr view --json url,number,title,state 2>/dev/null - 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 - Ask the user which PR they want to describe
- Check for existing description:
- Check if thoughts/shared/prs/{number}_description.md already exists - If it exists, read it and inform the user you'll be updating it - Consider what has changed since the last description was written
- Gather comprehensive PR information:
- Get the full PR diff: gh pr diff {number} - If you get an error about no default remote repository, instruct the user to run gh repo set-default and select the appropriate repository - Get commit history: gh pr view {number} --json commits - Review the base branch: gh pr view {number} --json baseRefName - Get PR metadata: gh pr view {number} --json url,title,number,state
4b. Gather reasoning history (if available):
- Check if reasoning files exist:
ls.git/claude/commits/*/reasoning.md 2>/dev/null - If they exist, aggregate them:
bash "$CLAUDE_PROJECT_DIR/.claude/scripts/aggregate-reasoning.sh" main - This shows what approaches were tried before the final solution
- Save the output for inclusion in the PR description
- Analyze the changes thoroughly: (ultrathink about the code changes, their architectural implications, and potential impacts)
- Read through the entire diff carefully - For context, read any files that are referenced but not shown in the diff - Understand the purpose and impact of each change - Identify user-facing changes vs internal implementation details - Look for breaking changes or migration requirements
- Handle verification requirements:
- Look for any checklist items in the "How to verify it" section of the template - For each verification step: - If it's a command you can run (like make check test, npm test, etc.), run it - If it passes, mark the checkbox as checked: - [x] - If it fails, keep it unchecked and note what failed: - [] with explanation - If it requires manual testing (UI interactions, external services), leave unchecked and note for user - Document any verification steps you couldn't complete
- Generate the description:
- Fill out each section from the template thoroughly: - Answer each question/section based on your analysis - Be specific about problems solved and changes made - Focus on user impact where relevant - Include technical details in appropriate sections - Write a concise changelog entry - If reasoning files were found (from step 4b): - Add an "## Approaches Tried" section before "## How to verify it" - Include the aggregated reasoning showing failed attempts and what was learned - This helps reviewers understand the journey, not just the destination - Ensure all checklist items are addressed (checked or explained)
- Save the description:
- Write the completed description to thoughts/shared/prs/{number}_description.md - Show the user the generated description
- Update the PR:
- Update the PR description directly: gh pr edit {number} --body-file thoughts/shared/prs/{number}_description.md - Confirm the update was successful - If any verification steps remain unchecked, remind the user to complete them before merging
Important notes:
- This command works across different repositories - always read the local template
- Be thorough but concise - descriptions should be scannable
- Focus on the "why" as much as the "what"
- Include any breaking changes or migration notes prominently
- If the PR touches multiple components, organize the description accordingly
- Always attempt to run verification commands when possible
- Clearly communicate which verification steps need manual testing