pr-content（公关内容）

PR Content

Generate ready-to-paste Pull Request content (Title + Description) based on branch changes.

Title and Description are output as separate copy-ready blocks because GitHub has two different input fields.

Context Reuse (Step 0)

See _shared/context-reuse.md for the context reuse protocol.

If DIFF_CONTEXT or RAW_DIFF is already provided, use it directly to save time and tokens.

Gather Change Context (Step 1)

See _shared/branch-diff-gathering.md for branch diff collection details.

Use branch-level diff as primary source (compare current branch against base branch). This gives you the full picture of what's changing in the PR.

Determine PR Type (Step 2)

Select one primary type based on change intent:

• feat: new feature
• fix: bug fix
• perf / refactor: optimization or refactor
• docs / chore: docs or maintenance

The type drives the PR description structure (different types need different sections).

Generate Title (Step 3)

Format: <type>: <brief description>

Keep title concise and specific. Focus on what changed, not how you analyzed it.

Generate Description by Type (Step 4)

See _shared/pr-heading-map.md for the complete heading map.

Why fixed headings matter:

• Consistent headings help teams quickly scan PRs and find relevant sections
• Automated tools and scripts often parse PR descriptions by heading text
• Team members know exactly where to look for specific information (e.g., "where's the testing info?")

Use the exact heading text from the map (no synonyms) and keep the exact order. This consistency is what makes the headings useful.

Quick reference:

Type: feat

• 中文: ### 概述 → ### 改动说明 → ### 使用方式
• English: ### Summary → ### Changes → ### Usage

Type: fix

• 中文: ### 问题描述 → ### 复现步骤(optional) → ### 修复方式 → ### 测试说明
• English: ### Problem → ### Steps to Reproduce(optional) → ### Solution → ### Testing

Type: perf/refactor

• 中文: ### 概述 → ### 改动说明 → ### 效果(optional)
• English: ### Summary → ### Changes → ### Impact(optional)

Type: docs/chore

• 中文: ### 概述 → ### 改动说明
• English: ### Summary → ### Changes

Language and Output Format (Step 5)

See _shared/bilingual-output.md for bilingual output rules.

Default: output both 简体中文 and English versions (semantically aligned, not word-for-word translation).

Each language version must be independently written in its respective language — not one version copied and relabeled.

If user explicitly requests single language, output only that language.

Output structure:

• PR Title and PR Description in separate code blocks (they go into different GitHub input fields)
• For bilingual output, each language gets its own independent code blocks
• Language label (中文 / English) appears immediately above each code block

Before Finalizing (Step 6)

Quick verification:

• Type is clear and matches the actual changes
• Headings follow the type-specific map (see _shared/pr-heading-map.md)
• In bilingual mode, each language has its own code blocks
• All claims are grounded in the actual diff

If something doesn't look right, adjust and regenerate.

Output Template

PR Title

中文

<type>: <brief description>

English

<type>: <brief description>

PR Description

中文

### <fixed-section-heading>
- <fact>

English

### <fixed-section-heading>
- <fact>

Example

PR Title

中文

fix: 防止认证 token 刷新竞态

English

fix: prevent auth token refresh race

PR Description

中文

### 问题描述
- 并发 refresh 请求可能覆盖有效 token。

### 修复方式
- 串行化 refresh 流程，并为 401 边界场景增加重试保护。

### 测试说明
- 增加 refresh 竞态场景的回归测试。

English

### Problem
- concurrent refresh requests could overwrite valid tokens.

### Solution
- serialize refresh flow and add retry guard for 401 edge cases.

### Testing
- add regression tests for refresh race scenarios.

Conventions

• Mention base branch only as internal baseline for analysis, not in PR summary narrative
• Keep statements grounded in actual branch diffs and commits
• Prefer concrete change highlights over generic wording