git-pull-request（git 拉取请求）

Git Pull Request Message Convention

This skill automates the analysis of commit logs to save time and ensure consistent PR documentation according to team conventions.

When to Use This Skill

Activate this skill when the user:

• Requests PR creation ("Write a PR for me," "Generate PR content").
• Needs a summary of work between branches or specific commits ("[Hash] to latest").
• Has completed work in features/*, hotfix/*, or develop branches and is ready to merge.

How to Generate Pull Request Content

Step 1: Environment & Branch Analysis

The agent identifies the current environment and determines the target parent branch.

1. Check Current Branch: git branch --show-current
2. Determine Parent Branch: Current Branch Parent Branch Description features/* main (or develop) Feature branches PR to main/develop. hotfix/* main Hotfixes PR directly to main. Others main Default target is main.

Step 2: Extract Changes

Analyze the differences between the parent branch and the current branch.

• Commit Log Analysis:

- git log --oneline <parent-branch>..<current-branch> - git log --format="%h|%s|%b" <parent-branch>..<current-branch>

• File Diff Analysis:

- git diff --name-status <parent-branch>..<current-branch> - git diff --stat <parent-branch>..<current-branch>

Step 3: Parse and Categorize Commits

Map commits to PR categories based on Gitmojis and Types.

Gitmoji Mapping:

Always check this: gitmoji | An emoji guide for your commit messages

Type Analysis:

• feat → Features
• fix → Fixes
• refactor → Refactoring
• chore → Chores
• perf → Performance
• docs → Documentation
• test → Test.

Step 4: Generate PR Content

Apply the template from .github/PULL_REQUEST_TEMPLATE.md or the internal guide. Generate Review Points by identifying complex logic or potential side effects in the code changes.

Step 5: Finalize and Save PR Content

Since Git itself does not support PR creation, the agent should save the finalized content to a file for easy access.

1. Review: Present the generated content to the user.
2. Save: Write the content to a file (e.g., PULL_REQUEST.md) in the project root or a temporary directory.
3. Instruction: Provide the user with instructions on how to use this file (e.g., "Copy this to GitHub" or "Use gh pr create -F PULL_REQUEST.md").

Guidelines

• Accuracy: Ensure commit hashes and messages strictly match the actual git log.
• Selective Sections: Only include sections that are relevant. Omit sections like "Related Issues," "Breaking Changes," or "Screenshots" entirely if they do not apply. Do not leave empty headers or "N/A".
• Insightful Review Points: Go beyond simple summaries; explain the "Why" behind decisions (e.g., trade-offs, library choices) and highlight critical logic.
• User Preference: If a user manually specifies a parent branch or commit range, override the automatic detection logic.

PR Template Structure (Output Standard)

The agent must output the PR using the following Markdown structure. Sections marked with (Optional) should be omitted if not applicable.

# Pull Request

## 🔗 Related Issues (Optional: Omit if none)

- Closes #123
- Fixes [JIRA-456]

## 📋 PR Title Rule

<gitmoji> <type>(<scope>): <subject>

## 🎯 Summary

<!-- Explain the purpose of the change and "Why" it was done -->

## ⚠️ Breaking Changes (Optional: Omit if none)

<!-- List compatibility issues only if they exist -->

## 📸 Screenshots (Optional: Omit if no UI changes)

<!-- Include only for UI/UX changes -->

## 💡 Review Points

<!-- Focus on critical logic, trade-offs, and decision background -->

## ✨ Changes

### 🚀 Features / 🐛 Fixes / ⚡ Performance / ♻️ Refactoring & Chores

- [x] Change description (commit_hash)

## 🛠️ Test & Verification

- [ ] Test Case 1: ...
- [ ] Test Case 2: ...

## ✅ Checklist

- [ ] PR title follows conventions
- [ ] Self-review performed
- [ ] Tests added/updated
- [ ] Documentation updated

Constraints & Warnings

1. Git Repository Required: This skill only functions within a valid Git environment.
2. Branch Naming: Incorrect branch naming (not following features/* etc.) may lead to incorrect parent branch detection.
3. Manual Review: Always advise the user to review the generated content before final submission.