PR Description Writer

When the user wants a PR description, gather context from git and produce a structured doc.

Workflow

1. Detect the base branch (default: main):

```bash

BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed s@^refs/remotes/origin/@@) || BASE=main

```

1. Gather commits, diff stat, and file list:

```bash

git log --oneline $BASE..HEAD

git diff --stat $BASE..HEAD

git diff --name-only $BASE..HEAD

```

1. For non-trivial changes, look at the actual diff for the most-changed files:

```bash

git diff $BASE..HEAD -- <file>

```

1. Draft the PR description in this structure.

Template

# <Title — under 70 chars, imperative mood>

## Summary

2-3 sentences. What changed and why. Lead with the user-facing or system-level effect, not implementation.

## Motivation

What problem this solves. Link the issue/ticket if there is one. If no issue, state the user complaint or metric that triggered this.

## Approach

High-level shape of the change. Mention any non-obvious decisions:
- Why this approach over the alternatives considered.
- Any new dependencies introduced.
- Migrations or schema changes (if any).

## Test plan

- [ ] <Specific scenario 1 — how to verify>
- [ ] <Specific scenario 2>
- [ ] Edge cases: <what could break>

## Risk

- Backward compat: <breaking? deprecation path?>
- Rollback plan: <how to undo if it goes wrong>
- Data: <any data migrations, irreversible operations>

## Screenshots / examples

<Only if UI change. Drop screenshots inline.>

Style rules

• Title: under 70 chars, imperative ("Add X" not "Added X" or "Adding X").
• Summary: lead with effect, not "this PR does...".
• Test plan: actionable checkboxes a reviewer can run, not vague "tested locally".
• Risk: mandatory section. If truly low-risk, write "None — pure refactor, all tests pass".

Anti-patterns

• Don't list every file changed. The diff already shows that.
• Don't copy-paste commit messages into the summary. Synthesize.
• Don't skip the risk section. "What could go wrong?" is the most important question for a reviewer.

Output

Return the final markdown ready to paste into a GitHub/GitLab PR. If the user uses gh CLI, offer to call gh pr create --title "..." --body "..." directly.