Menu
Generate a structured PR description from staged git changes when the user asks to create, write, or draft a pull request description
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Pins and manages per-project Flutter SDK versions with FVM (Flutter Version Management). Use when the project has or needs a .fvmrc or .fvm/ directory, when contributors need a reproducible Flutter SDK, when installing FVM, pinning or switching the Flutter version, wiring FVM into VS Code or Android Studio, configuring CI to honor .fvmrc, or troubleshooting "wrong Flutter version" symptoms.
End-to-end review pipeline — creates a handoff, generates a review (self-review or paste-ready for another provider), then offers to fix findings. Use when you want to review your changes before pushing.
Build a competitive positioning matrix and strategy canvas when the user asks to analyze competitors, compare products, or assess competitive landscape
Audit project dependencies for risk when the user asks to check dependencies, audit packages, review dependency health, check for vulnerabilities, or assess supply chain risk
Analyze product metrics and identify trends when the user asks to review metrics, analyze KPIs, or assess product health
Audit a feature for WCAG 2.1 AA compliance using POUR principles when the user asks to check accessibility, audit a11y, or verify WCAG compliance
| name | create-pr-description |
| description | Generate a structured PR description from staged git changes when the user asks to create, write, or draft a pull request description |
| author | chalk |
| version | 1.0.0 |
| metadata-version | 3 |
| allowed-tools | Read, Glob, Grep, Bash |
| argument-hint | [optional: PR title or linked issue number] |
| read-only | false |
| destructive | false |
| idempotent | false |
| open-world | true |
| user-invocable | true |
| tags | git, pr, documentation |
Generate a comprehensive, reviewer-friendly pull request description by analyzing staged git changes, commit history, and project conventions. The output is a ready-to-paste PR body that explains the "why" behind every change.
Read project context — Check for .chalk/docs/engineering/ files, especially PR conventions, coding style, and architecture docs. If a conventions file exists, follow its PR template. If not, use the default structure below.
Gather git context — Run these commands to understand the change:
git diff --cached --stat for an overview of changed filesgit diff --cached for the full staged diffgit log --oneline -10 for recent commit contextgit branch --show-current for the branch name$ARGUMENTS contains an issue number, read the issue details if accessibleAnalyze the diff — Before writing anything, categorize the changes:
Determine change type and scope — This shapes the description tone:
Write the PR description — Use the structure defined in the Output section. Every section must add value; omit sections that genuinely do not apply rather than filling them with "N/A".
Output the description — Print the full PR description in a markdown code block so the user can copy it. If the user has a PR already open, suggest the gh pr edit command to update it.
## Summary
<!-- 1-2 sentences. What does this PR do and why? -->
## Motivation
<!-- Why is this change needed? Link to the problem, user feedback, or product requirement. -->
<!-- If fixing a bug: what was the broken behavior? What triggers it? -->
## Changes
<!-- Group changes by concern. Use sub-headers for large PRs. -->
### <Concern 1, e.g., "API Layer">
- Change description with enough context to understand without reading the diff
### <Concern 2, e.g., "Database">
- Change description
## Testing
<!-- What was tested? How can a reviewer verify? -->
- [ ] Unit tests added/updated
- [ ] Manual testing performed (describe steps)
- [ ] Edge cases considered: <list them>
## Screenshots
<!-- For UI changes only. Remove this section if no UI changes. -->
<!-- Before/after screenshots or screen recordings -->
## Reviewer Notes
<!-- Where should the reviewer start reading? -->
<!-- What's the trickiest part of this change? -->
<!-- Any concerns or tradeoffs you want a second opinion on? -->
## Related Issues
<!-- Use closing keywords: Fixes #123, Closes #456, Resolves #789 -->
<!-- Or just references: Related to #123, Part of #456 -->
---
### Checklist
- [ ] Tests pass locally (`npm test` / `pytest` / equivalent)
- [ ] No new console errors or warnings
- [ ] Accessibility checked (if UI changes)
- [ ] Documentation updated (if behavior changes)
- [ ] Migration tested (if schema changes)
- [ ] Feature flag configured (if gradual rollout)
auth.ts". Good: "Added token refresh retry logic to handle intermittent auth failures."