create-pr
Create pull requests following best practices. Use when opening PRs, writing PR descriptions, or preparing changes for review. Follows conventional commit and PR conventions.
What this skill does
# Create Pull Request
Create pull requests following engineering best practices.
**Requires**: GitHub CLI (`gh`) authenticated and available.
## Prerequisites
Before creating a PR, ensure all changes are committed. If there are uncommitted changes, run the `mpuig-skills:commit` skill first to commit them properly.
```bash
# Check for uncommitted changes
git status --porcelain
```
If the output shows any uncommitted changes (modified, added, or untracked files that should be included), invoke the `mpuig-skills:commit` skill before proceeding.
## Process
### Step 1: Verify Branch State
```bash
# Detect the default branch
BASE=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
# Check current branch and status
git status
git log $BASE..HEAD --oneline
```
Ensure:
- All changes are committed
- Branch is up to date with remote
- Changes are rebased on the base branch if needed
### Step 2: Analyze Changes
Review what will be included in the PR:
```bash
# See all commits that will be in the PR
git log $BASE..HEAD
# See the full diff
git diff $BASE...HEAD
```
Understand the scope and purpose of all changes before writing the description.
### Step 3: Write the PR Description
First, check if the repository has a PR template:
```bash
# Fetch PR template from GitHub
gh repo view --json pullRequestTemplates --jq '.pullRequestTemplates[0].body'
```
If a PR template exists, follow its structure and fill in all required sections. Otherwise, follow this structure:
```markdown
<brief description of what the PR does>
<why these changes are being made - the motivation>
<alternative approaches considered, if any>
<any additional context reviewers need>
```
**Do NOT include:**
- "Test plan" sections
- Checkbox lists of testing steps
- Redundant summaries of the diff
**Do include:**
- Clear explanation of what and why
- Links to relevant issues or tickets
- Context that isn't obvious from the code
- Notes on specific areas that need careful review
### Step 4: Create the PR
```bash
gh pr create --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
<description body here>
EOF
)"
```
**Title format** follows commit conventions:
- `feat(scope): Add new feature`
- `fix(scope): Fix the bug`
- `ref: Refactor something`
## PR Description Examples
### Feature PR
```markdown
Add Slack thread replies for alert notifications
When an alert is updated or resolved, we now post a reply to the original
Slack thread instead of creating a new message. This keeps related
notifications grouped and reduces channel noise.
Previously considered posting edits to the original message, but threading
better preserves the timeline of events and works when the original message
is older than Slack's edit window.
Refs #1234
```
### Bug Fix PR
```markdown
Handle null response in user API endpoint
The user endpoint could return null for soft-deleted accounts, causing
dashboard crashes when accessing user properties. This adds a null check
and returns a proper 404 response.
Found while investigating #5678.
Fixes #5678
```
### Refactor PR
```markdown
Extract validation logic to shared module
Moves duplicate validation code from the alerts, issues, and projects
endpoints into a shared validator class. No behavior change.
This prepares for adding new validation rules in #9999 without
duplicating logic across endpoints.
```
## Issue References
Reference issues in the PR body:
| Syntax | Effect |
|--------|--------|
| `Fixes #1234` | Closes GitHub issue on merge |
| `Refs GH-1234` | Links without closing |
| `Refs #1234` | Links without closing |
## Guidelines
- **One PR per feature/fix** - Don't bundle unrelated changes
- **Keep PRs reviewable** - Smaller PRs get faster, better reviews
- **Explain the why** - Code shows what; description explains why
- **Mark WIP early** - Use draft PRs for early feedback
## Editing Existing PRs
If you need to update a PR after creation, use `gh api` instead of `gh pr edit`:
```bash
# Update PR description
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="$(cat <<'EOF'
Updated description here
EOF
)"
# Update PR title
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f title='new: Title here'
# Update both
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
-f title='new: Title' \
-f body='New description'
```
Note: `gh pr edit` is currently broken due to GitHub's Projects (classic) deprecation.
## References
- [Conventional Commits](https://www.conventionalcommits.org/)
- [GitHub CLI Documentation](https://cli.github.com/manual/)
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.