← ClaudeAtlas

pull-requestcreatelisted

Create a pull request, merge request, or change request with proper formatting and content guidelines. Invoke when the user wants to create, open, or submit a PR, MR, or CR, including after committing changes.
bendrucker/claude · ★ 16 · Code & Development · score 76
Install: claude install-skill bendrucker/claude
# Create Pull Request ## Context - Remote URL: !`git remote get-url origin` - Review bot: !`bun ${CLAUDE_PLUGIN_ROOT}/scripts/detect-bot.ts` - PR Template: !`bun ${CLAUDE_PLUGIN_ROOT}/scripts/pr-template.ts` !`bun ${CLAUDE_PLUGIN_ROOT}/scripts/git-context.ts` !`bun ${CLAUDE_PLUGIN_ROOT}/scripts/contributing.ts` ## Title - Check the log in the context above to determine the repo's commit style: - **subject** (default): `${subject}: ${summary}` (e.g., `api: add timeout to request`) - **conventional**: `${type}: ${summary}` (e.g., `fix: add timeout to request`) - Name the primary change. If the title needs a serial comma, it's naming several changes. Name the shared theme or the largest change, and put the rest in the body. - Keep under 50 characters. Cut scope rather than truncating words. - Use imperative mood, lowercase except proper nouns ## Body Lead with intent: why the change exists, the decisions a reviewer can't reconstruct from the diff, and how you know it works. Don't restate what the diff, the git log, or the status checks show. Review the session for content that never reached the code (rejected alternatives, scope changes, test observations) and state each as a self-contained decision, never as a delta against a plan the reviewer hasn't seen. - Open with a bare verb ("Adds", "Fixes", "Removes") when the change is self-evident, or with the problem when it needs justifying. Don't restate the title. - Default to prose. Write a small PR as one paragraph w