| name | pr |
| description | Open or update a draft PR for the current branch. Use when: create PR, open PR, draft PR, pull request, prepare for review. |
Draft PR Creator
Creates or updates a draft pull request for the current branch.
Usage
/pr - Create draft PR for current branch (or update if one exists)
/pr <url> - Update existing PR description
Workflow
1. Ensure feature branch and commit
NEVER commit to main unless the user explicitly requests it.
git branch --show-current
git status
If on main, create and switch to a feature branch before doing anything else:
git checkout -b <type>/<short-name>
Branch naming follows the PR type prefix:
feat/ — new features
fix/ — bug fixes
refactor/ — refactoring
test/ — test additions
chore/ — maintenance
docs/ — documentation
Derive the branch name from the commit history or changes (e.g., feat/spawn-and-observe).
After ensuring you're on a feature branch, check for uncommitted changes. If there are staged or unstaged changes, commit them using conventional commit format:
git add <relevant files>
git commit -m "<type>: <description>"
Only proceed to the next step once all changes are committed on a feature branch.
2. Gather context
git log main..HEAD --oneline
git diff main...HEAD --stat
2.5. Identify source issue
If the PR was created from a /tdd <issue> workflow, you already have the issue number in context. Otherwise, check the branch name or commit messages for issue references.
If an issue is identified, it will be linked in the PR body using a GitHub closing keyword (see template below). When the PR is merged, GitHub automatically closes the linked issue and marks it as "completed".
3. Check if PR already exists
gh pr view --json number,title,body 2>/dev/null
4. Write PR description
Use the template below. Keep it concise and natural.
5a. If NO existing PR - Create draft PR
gh pr create --draft --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
5b. If PR already exists - Update description
gh pr edit --title "<title>" --body "$(cat <<'EOF'
<updated body>
EOF
)"
Report the PR URL to the user when done.
PR Title Format
<type>: <short description>
Types: feat:, fix:, refactor:, test:, chore:, docs:
Rules:
- Lowercase after prefix
- Present tense imperative ("add" not "added")
- Under 70 characters
PR Body Template
Closes #<issue_number>
## Summary
1-2 paragraphs explaining what this does and why.
## Changes
- Highlight 1
- Highlight 2
- Highlight 3
## Testing
- [ ] `mix test` passes
- [ ] `mix dialyzer` passes
- [ ] `mix smoke` passes
Omit the Closes #... line if there is no source issue.
Style
- Fluid prose in Summary - natural writing, not robotic
- 2-3 bullet points in Changes - highlights only, not a file list
- No file lists - GitHub shows that in "Files changed"
Pipeline
/tdd <issue_url> -> /review-pr -> /pr -> merge