create-ol-pull-request

name	create-ol-pull-request
description	Create a pull request in the mitodl organization using their standard PR template. Use this skill when asked to create a PR, open a pull request, or submit changes for review. Guides branch inspection, title/body population, and gh pr create.
license	BSD-3-Clause
metadata	{"category":"process"}

Create a Pull Request (/olpr)

When the user runs /olpr, or asks to open a pull request in a repo with a mitodl remote, guide them through creating a PR using the org's standard pull request template.

Auto-detection

This skill should activate automatically (without /olpr) when:

• The user says "create a PR", "open a pull request", "submit a PR", etc., and
• The current repo has a remote URL containing github.com/mitodl/ (verify with git remote -v).

Step 1 — Inspect the branch and diff

Before prompting the user, gather context automatically:

# Confirm current branch and its upstream
git --no-pager branch --show-current
git --no-pager log --oneline origin/HEAD..HEAD

# Check for an existing open PR on this branch
gh pr view --json url,title,state 2>/dev/null

• If an open PR already exists for the branch, share its URL and stop — do not create a duplicate.
• If there are no commits ahead of the base, warn the user before proceeding.

Step 2 — Determine the base branch

Default to the repo's default branch (usually main). Override if the user specifies a different target.

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

Step 3 — Gather PR metadata

Collect or infer:

Field	How to obtain
Title	Ask the user, or suggest one derived from the branch name / commit messages
Linked tickets	Ask the user for issue numbers (Closes #, Fixes #, or N/A)
Description	Ask what the PR does; summarise from commits if the user says "summarise"
Screenshots	Ask if UI changes are present; skip section if not applicable
Testing notes	Ask how the changes were tested and how a reviewer can validate
Additional context	Ask for reviewer notes, caveats, or checklist items; skip if none
Draft?	Ask if this should be a draft PR (default: no)

Step 4 — Populate the template

Fill in the standard PR template below with the gathered information. Strip HTML comments before passing to gh pr create.

### What are the relevant tickets?
<!-- Closes #<n> | Fixes #<n> | N/A -->

### Description (What does it do?)
<description>

### Screenshots (if appropriate):
<screenshot checklist, or delete section if not applicable>

### How can this be tested?
<testing instructions>

### Additional Context
<reviewer notes, or delete section if not applicable>

Checklist section (uncomment and populate only if there are pre-merge steps):

### Checklist:
- [ ] <step>

Step 5 — Create the PR

gh pr create \
  --repo mitodl/<repo> \
  --base <base-branch> \
  --title "<title>" \
  --body "<filled-in body>" \
  [--draft]

Confirm the PR URL returned by gh pr create and share it with the user.

---

Full PR template (reference)

Source: https://github.com/mitodl/.github/blob/main/.github/pull_request_template.md

### What are the relevant tickets?
<!--- If it fixes an open issue, please link to the issue here. -->
<!--- Closes # --->
<!--- Fixes # --->
<!--- N/A --->

### Description (What does it do?)
<!--- Describe your changes in detail -->

### Screenshots (if appropriate):
<!--- optional - delete if empty --->
- [ ] Desktop screenshots
- [ ] Mobile width screenshots

### How can this be tested?
<!---
Please describe in detail how your changes have been tested.
Include details of your testing environment, any set-up required
(e.g. data entry required for validation) and the tests you ran to
see how your change affects other areas of the code, etc.
Please also include instructions for how your reviewer can validate your changes.
--->

### Additional Context
<!--- optional - delete if empty --->
<!--- Please add any reviewer questions, details worth noting, etc. that will help in
assessing this change.  --->


<!--- Uncomment and add steps to be completed before merging this PR if necessary
### Checklist:
- [ ] e.g. Update secret values in Vault before merging
--->

---

Tips

• Summarise from commits: if the user asks you to write the description, run git --no-pager log --oneline origin/HEAD..HEAD and synthesise a concise summary from the commit messages.
• Strip comments: remove all <!-- ... --> blocks from the body before calling gh pr create to keep the PR clean.
• Screenshots: only include the Screenshots section when the PR touches UI code. Ask the user to attach images after the PR is created if needed.
• Checklist: only uncomment and use the Checklist section when there are explicit pre-merge steps (e.g. Vault secret updates, migration runs). Leave it out otherwise.
• Draft PRs: suggest --draft if the branch is a work-in-progress or the user mentions it isn't ready for review.

Self-contained PRs

Pull requests must be self-contained and self-documenting. Do not reference local files, on-device content, or relative paths that would be inaccessible to reviewers. Instead:

• Reference GitHub issues by their full URL (e.g., https://github.com/mitodl/ol-django/issues/123)
• Reference code files via GitHub URLs, including line numbers for specific references (e.g., https://github.com/mitodl/ol-django/blob/main/apps/course_info/views.py#L45-L52)
• Reference documentation via its public URL (e.g., Django docs, library API docs)
• Reference designs via Figma URLs or other publicly accessible sources
• Include essential context inline when no URL is available. If you need to reference a specific code pattern, configuration, or decision, include the relevant snippets or details directly in the PR body.
• Include test data or fixtures inline when describing testing procedures rather than referencing local files.
• Include error messages or log output directly in the PR description rather than describing them or referencing temporary files.
• Attach screenshots to the PR after creation rather than referencing local image files.

This ensures reviewers can understand and evaluate the changes without needing access to the author's local environment or file system.