Diff Pr

If there are uncommitted changes, warn: "You have uncommitted changes. Commit them first, or run /diff:diff-precommit."

Step 2: Get the PR Template

Check for a PR template in the repo:

REPO_ROOT=$(git rev-parse --show-toplevel)

Search for the template:

• $REPO_ROOT/.github/pull_request_template.md
• $REPO_ROOT/.github/PULL_REQUEST_TEMPLATE.md
• $REPO_ROOT/docs/pull_request_template.md

Read the template if found. Follow its structure exactly — fill in each section.

If no template exists, use the default format in Step 4.

Step 3: Gather Context

1. Get the full diff from base:

   MERGE_BASE=$(git merge-base origin/master HEAD)
   git diff $MERGE_BASE...HEAD --stat
   git diff $MERGE_BASE...HEAD
   

2. Get the commit log:

   git log $MERGE_BASE...HEAD --oneline
   

3. Get the ticket context (if ticket ID is known):

   Tool: mcp__glean_default__chat Question: "What are the title, description, and acceptance criteria for Linear ticket CDIN-{number}?"

4. For Terraform/infra PRs — check if there are .tf file changes. If yes, look for a terraform plan output. Include only the resource change summary (adds/changes/destroys), not the full plan.

Step 4: Generate PR Title and Description

Title Rules:

• Under 72 characters
• Format: {CDIN-number}: {concise description of what changes}
• If no ticket: just the concise description
• No dashes or em-dashes in titles

Description Rules:

• Be specific: Reference function names, file paths, behavior changes from the actual diff
• Highlight non-obvious decisions: Race conditions, workarounds, backward compat choices
• Link the ticket: [CDIN-{number}](https://linear.app/klaviyo/issue/CDIN-{number})
• No generic summaries: Every bullet should be grounded in a specific code change

If following a repo template, fill in each section. If no template, use:

## Summary
{2-3 sentences: what this PR does and why}

**Ticket:** [CDIN-{number}](https://linear.app/klaviyo/issue/CDIN-{number})

## Changes
- {Specific change 1: file path, function name, what it does}
- {Specific change 2}
- {Specific change 3}

## Non-Obvious Decisions
- {Why you chose approach X over Y}
- {Any workarounds or temporary solutions}

## Testing
- {How you tested: which test files, manual verification}
- {Test command: `pants test ...` or `make TEST=... docker-unit`}

## Rollback
- {Is this safe to revert? Any caveats?}

Step 5: Suggest Reviewers

Use the glean-code:code-owners skill to find owners of the changed files:

Tool: Skill Skill: glean-code:code-owners Args: the primary module/directory that changed

Suggest 1-2 reviewers. Prefer:

1. Code owners of the changed files
2. Team members who recently modified the same files

Step 6: Preview and Confirm

Present the full PR preview:

**Title:** {title}
**Base:** master
**Reviewers:** {suggested reviewers}

---
{full PR description body}
---

Review the PR above. Confirm to create it, or suggest edits.

Wait for user confirmation. Do not create the PR until the user approves.

Step 7: Create the PR

After confirmation:

gh pr create --title "{title}" --body "{body}" --base master

If reviewers were confirmed:

gh pr create --title "{title}" --body "{body}" --base master --reviewer "{reviewer1},{reviewer2}"

After creation, capture the PR URL and copy to clipboard:

gh pr view --json url --jq '.url' | pbcopy

Report:

PR created: {URL} (copied to clipboard) Reviewers: {reviewers} Ticket linked: CDIN-{number}