pr-description-file

Create a PR description Markdown file from git history and diff between HEAD and a target branch provided by the user.

Required Input

• Target branch/ref (for example: main, develop, release/5.6.0, origin/release/5.6.0).

Ask for missing target branch/ref when it cannot be resolved locally.

No-Script Workflow

1. Resolve branch context and range.

• Run git rev-parse --abbrev-ref HEAD.
• Resolve target ref in this order: refs/heads/<target>, refs/remotes/origin/<target>, exact ref.
• Run git merge-base <target-ref> HEAD.
• Define comparison range as <merge-base>..HEAD.

2. Load changes into context.

• Run git log --reverse --pretty=format:'%h %s' <range>.
• Run git diff --stat <range>.
• Run git diff -U1 <range> and inspect added/changed behavior.

3. Write output file.

• Create PR_DESCRIPTION.md in repo root unless user requested another path.
• Fill the template exactly.

Output Template

Use this exact structure:

# [Type]: Brief Description of Changes (e.g., [Feature]: Added User Profile Screen)

**Related Issue/Ticket:** Link to Jira/Asana/Trello ticket, e.g., [PROJECT-123]

**Estimated Review Time**: 5-10 minutes

---

### Description of Changes

* **What was done:**
    * *High-level, user-facing summary of what changed. Describe outcomes and observable behavior only, as if explaining to a non-engineer stakeholder. NEVER name a property, class, type, method, function, file, module, or path here, and never include any code identifier. All such detail belongs under "Technical Details".*
* **Why it was done:**
    * *Explain the problem this PR solves. Include only for bugfix/refactor when reason is non-obvious.*

---

### Technical Details

* [Minimal key implementation points with technical details, like file/entities/methods references.]

---

### How to Test

* **Steps to reproduce:**
    1.  *Step 1.*
    2.  *Step 2.*
* **Expected behavior:**
    * *Describe what should happen after following the steps.*
* **Screenshots / Video (if applicable):**
    * [Add links or screenshots here]

---

### Pre-Merge Checklist
* [ ] Code adheres to our **Coding Guidelines**.
* [ ] New/changed features are covered by tests (if applicable).
* [ ] All existing tests pass successfully.
* [ ] No new **warnings** in Xcode.
* [ ] Changes tested on a physical device.

---

### Optional Notes

* [Any additional comments, questions for the reviewer, etc.]

### How to review
* Code Review Guidelines

Quality Rules

• Preserve natural sentence casing in title and bullets.
• Prefer 3-6 meaningful bullets total across Description + Technical Details.
• Avoid generic filler like "updated files" or "various fixes".
• "What was done" must stay strictly non-technical. No code identifiers (property, class, type, method, or function names), no file paths, no module names — describe only the observable, user-facing outcome. Every technical specific goes under "Technical Details" instead. If a bullet mentions a symbol or a file, it is in the wrong section.
• If range is empty, explicitly state no commits found and stop before writing a misleading PR.