| name | describe-pr |
| description | Generate a PR description from the repo template, save it under flow/prs/, and update the live PR. Explicit-only; run only when invoked via /describe-pr or the user asks to describe a PR. |
| disable-model-invocation | true |
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:
- Check if
.github/PULL_REQUEST_TEMPLATE.md exists (standard GitHub location)
- If it doesn't exist, use a standard PR template with Summary, Changes, Test Plan, and Checklist sections
- Read the template carefully to understand all sections and requirements
-
Identify the PR to describe:
- Check if the current branch has an associated PR:
tracker pr-current --json url,number,title,state 2>/dev/null
- If no PR exists for the current branch, or if on main/master, list open PRs:
tracker pr-list-open
- Ask the user which PR they want to describe
-
Check for existing description:
- Check if
flow/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:
tracker pr-diff {number}
- On GitHub: 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:
tracker pr-view {number} --json commits
- Review the base branch:
tracker pr-view {number} --json baseRefName
- Get PR metadata:
tracker pr-view {number} --json url,title,number,state
-
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 template
- For each verification step:
- If it's a command you can run (like
uv run pytest, 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
- Ensure all checklist items are addressed (checked or explained)
-
Save the description:
- Write the completed description to
flow/prs/{number}_description.md
- Show the user the generated description
-
Update the PR:
- Update the PR description directly:
tracker pr-edit-body {number} flow/prs/{number}_description.md
- Confirm the update was successful
- If any verification steps remain unchecked, remind the user to complete them before merging
-
Transition linked work-item states (if PR is linked to issues / work items):
- Get linked work-item ids:
tracker pr-closing-issues {number}
- For each linked work item:
tracker set-state <id> pr-submitted in-progress
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
