sriram veeraghanta
f1d567accc
* chore: add Claude Code skills for PR descriptions and release notes * chore(skills): update release-notes branches to canary->master and example version to v1.3.0 * chore(skills): address PR review comments - pr-description: infer base branch from PR metadata, fix Improvement wording, reference template's screenshot placeholder verbatim - release-notes: add `text` language to unlabeled fenced code block
2.8 KiB
name, description, user_invocable
| name | description | user_invocable |
|---|---|---|
| pr-description | Generate a PR description following the project's GitHub PR template. Analyzes the current branch's changes against the base branch to produce a complete, filled-out PR description. | true |
PR Description Generator
Generate a pull request description based on the project's PR template at .github/pull_request_template.md.
Steps
-
Determine the base branch: Prefer the PR's actual
baseRefName(viagh pr view <PR> --json baseRefName) when a PR exists. Otherwise default by intent — feature PRs targetpreview, release PRs targetmaster. If still ambiguous, ask the user. -
Analyze changes: Run the following to understand what changed:
git log <base>...HEAD --onelineto see all commits on this branchgit diff <base>...HEAD --statto see which files changedgit diff <base>...HEADto read the actual diff (use--no-color)- If the diff is very large, focus on the most important files first
-
Fill out the PR template with the following sections:
Description
Write a clear, concise summary of what the PR does and why. Focus on the "what" and "why", not line-by-line changes. Mention any important implementation decisions.
Type of Change
Check the appropriate box(es) based on the changes:
- Bug fix (non-breaking change which fixes an issue)
- Feature (non-breaking change which adds functionality)
- Improvement (non-breaking change that improves existing functionality)
- Code refactoring
- Performance improvements
- Documentation update
Screenshots and Media
Leave this section for the user to fill in, preserving the existing placeholder comment from
.github/pull_request_template.mdverbatim rather than introducing different text.Test Scenarios
Based on the code changes, suggest specific test scenarios that should be verified. Be concrete (e.g., "Navigate to project settings and verify the new toggle works") rather than generic.
References
- If commit messages or branch name reference a work item identifier (e.g.,
WEB-1234), include it - If the user provides a linked issue, include it
- If Sentry issue links or IDs (e.g.,
SENTRY-ABC123, Sentry URLs) were mentioned earlier in the conversation, include them as references
-
Output format: Print the filled-out markdown template so the user can copy it directly. Do NOT wrap it in a code fence — output the raw markdown.
Guidelines
- Keep the description concise but informative
- Use bullet points for multiple changes
- Focus on user-facing impact, not implementation details
- If the branch has a Plane work item ID in its name (e.g.,
WEB-1234), reference it - Don't fabricate test scenarios that aren't relevant to the actual changes