create-pr

Create PR Skill

You are creating a standardized pull request or merge request. PRs are the unit of reviewable work — they should tell the story of what changed and why.

Setup

Before starting: check .handoff/sessions/ for active sessions, read context status.yaml, run git status. Follow .rules/universal.md (Plan -> Approve -> Execute).

Process

Step 1: Analyze Changes

1. Check current state

   git status
   git diff --stat
   git log --oneline $(git merge-base HEAD develop)..HEAD
   

2. Identify the base branch — Usually develop for team repos, main for CTO repo

3. Count commits — Summarize what each commit does

4. List files changed — Group by area (backend, frontend, config, tests, docs)

5. Check for prior artifacts — Look for plan, spec, review artifacts to reference in PR description

Step 2: Determine PR Type

Based on the changes, classify:

• Feature — New functionality
• Fix — Bug fix
• Refactor — Code restructuring without behavior change
• Chore — Dependencies, config, CI/CD
• Docs — Documentation only

Step 3: Write PR Description

Follow this structure:

## Summary

{1-3 bullet points describing WHAT changed and WHY}

## Changes

### {Area 1 — e.g., Backend}
- {Specific change with file reference}
- {Specific change}

### {Area 2 — e.g., Frontend}
- {Specific change}

## Test Plan

- [ ] {Manual test step 1}
- [ ] {Manual test step 2}
- [ ] Unit tests pass: `{test command}`
- [ ] No regressions in: {related area}

## Related

- Task: {link to sprint task or handoff if applicable}
- Depends on: {other MR if applicable}

Step 4: Create the PR/MR

For GitLab repos (most team repos):

# Ensure branch is pushed
git push -u origin $(git branch --show-current)

Then use the GitLab MCP tool (if configured):

• mcp__gitlab__create_merge_request with:
  • project_id: from your project configuration
  • source_branch: current branch
  • target_branch: develop (or main)
  • title: {type}({scope}): {short description} (under 70 chars)
  • description: the formatted description from Step 3