dkarter/dotfiles/open-pr

Tool preference

• Prefer GitHub MCP for GitHub operations when available
• Use gh CLI as the fallback for GitHub operations
• Use Bash for local git commands such as status, diff, log, commit, and push

Gather context

1. Get the base branch (usually main or master)
2. Get the diff: git diff <base>...HEAD
3. Get commit messages: git log <base>...HEAD --format="%s"
4. Read changed files to understand the broader context

Commit uncommitted changes

1. Run git status to check for uncommitted changes
2. If changes exist, commit them before proceeding

Write PR description

First, check whether the repository has a PR template. Look in these common locations:

• .github/pull_request_template.md
• .github/PULL_REQUEST_TEMPLATE.md
• .github/PULL_REQUEST_TEMPLATE/*.md

If a template exists, use it as the PR body format and fill it in using the conversation context and git context - but keep it concise!

If no template exists, use this fallback template:

# Motivation
 
[1-2 sentences: what this PR does and why]
 
# Summary of Changes
 
-[Key change 1]
-[Key change 2]
-[Key change 3]
 
# Testing
 
[How would a human reviewer verify the change from a user perspective when possible - concise bullet point instructions]
 
# Dependencies/Special Considerations
 
[only if there are any list them - e.g. other prs that need to be merged, manual
steps that need to be taken - otherwise say "none"]

Guidelines:

• Lead with a concise summary of what the PR does
• Explain the "why" before the "how"
• Use the conversation context to inform the description
• Include before/after comparisons for UI or performance changes
• Be concise, direct and to the point use explain-simply skill to keep technical descriptions easy to understand
• for the Testing Instructions section always prefer instructions for manual testing of how a human would verify the change manually by interacting with the app rather than a list of commands you ran - the list of commands is not helpful. If the change is not user facing at all you can describe how to test it more technically.
• Use the "humanizer" skill to improve writing
• IMPORTANT: always keep the pr in DRAFT mode - only a human should be allowed take a PR out of draft mode

Create the PR

1. Write a short PR title (max 52 characters) - it should always be a in conventional commit style

• For PDQ repositories that require a ticket, use <type>: <description> [<TICKET-ID>]; the bracketed ticket MUST be the final element, e.g. fix: guard last enabled shard [PLT-4261].

1. Ensure the branch is pushed:

``bash git push -u origin HEAD ``

1. Create the PR as a draft, preferring GitHub MCP when available and gh CLI otherwise

``bash gh pr create --draft --title "<title>" --body "<body>" ``

1. After creating the PR, open it in the browser with open <pr-url>