Describe Pr

Describe PR

Generate a pull request description by analyzing the current branch's changes against the main branch.

Process

1. Gather context: Run git log main..HEAD --oneline and git diff main...HEAD --stat to understand all changes
2. Read changed files: Read the key modified files to understand the nature of the changes
3. Identify the problem: Understand why the changes were made — what was wrong, missing, or suboptimal before
4. Summarize the solution: Describe what the PR does to address the problem

Output Format

Output the description inside a fenced ```markdown code block so the user can copy it in one click. Always use this exact structure:

Problems

• [Concise bullet points describing the issues/limitations that existed before this PR]
• [Focus on the "why" — what was wrong, duplicated, missing, or inefficient]

What does this PR do?

• [Concise bullet points describing the changes made]
• [Focus on the "what" — actions taken, not implementation details]
• [Use active verbs: Remove, Add, Introduce, Reuse, Replace, Decouple, etc.]

Rules

• Always write in English: The description is always in English, no matter what language the user's request is in
• Keep it short: The entire description should be scannable in under 30 seconds. Aim for 2-3 bullets per section max
• Stay high-level: Give the gist, not the details — describe changes at the feature/behavior level, not the code level. When in doubt, cut
• Be concise: Each bullet should be 1 line — 2 lines only if absolutely necessary
• No implementation details: Don't mention specific method names, variable names, line numbers, or internal logic
• Never mention testing: No tests, specs, test counts, coverage, or test files — the description covers behavior, not verification
• Problem-first: The Problems section explains the motivation; the solution section explains the action
• Use plain language: Write for reviewers who may not know the codebase deeply
• Group related changes: Don't list every file change — group them by logical concern
• No fluff: Skip phrases like "This PR aims to..." or "In order to improve..."
• Highlight key terms: Use bold or backticks to highlight important domain keywords, statuses, or values that are central to the change (e.g., ACCEPTED, REMOVED). This makes key terms easy to scan for reviewers