create-pr-description

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create PR Description

创建PR描述

Generate comprehensive pull request descriptions and create PRs using GitHub CLI.

使用GitHub CLI生成全面的Pull Request描述并创建PR。

Workflow

工作流程

1. Verify Prerequisites

1. 检查前置条件

Check that there are changes to create a PR for:

bash

undefined

检查是否存在可用于创建PR的变更：

bash

undefined

Get current branch

获取当前分支

git branch --show-current

Verify branch is not main/master

验证分支不是main/master

Verify there are commits ahead of main

验证存在领先于main的提交

git log origin/main..HEAD --oneline


If on main/master or no commits ahead, inform the user there's nothing to create a PR for.

git log origin/main..HEAD --oneline


如果当前分支是main/master，或者没有领先于main的提交，请告知用户没有可用于创建PR的内容。

2. Analyze Changes

2. 分析变更

Gather context about the changes:

bash

undefined

收集变更相关的上下文信息：

bash

undefined

Get commit messages

获取提交信息

git log origin/main..HEAD --pretty=format:"%s"

Get diff summary (files changed)

获取diff摘要（变更的文件）

git diff origin/main..HEAD --stat

Get actual code changes (sample key files if diff is large)

获取实际代码变更（如果diff过大，仅查看关键文件示例）

git diff origin/main..HEAD


**For large diffs**: Focus on the most meaningful changes. Sample key files rather than reading everything.

git diff origin/main..HEAD


**针对大型diff**：重点关注最有意义的变更。仅查看关键文件的示例，而非全部内容。

3. Determine Change Type

3. 确定变更类型

Classify the PR into one of these categories:

fix: Bug fixes, error corrections, resolving issues
feature: New functionality, capabilities, or enhancements
performance: Speed improvements, optimization, efficiency gains
refactor: Code restructuring without changing behavior
docs: Documentation changes
test: Test additions or improvements
chore: Maintenance tasks, dependencies, configuration

Base this on:

Commit messages (keywords like "fix", "add", "optimize", "refactor")
Nature of code changes (new files = feature, test fixes = fix, etc.)
Scope of changes

将PR归类为以下类别之一：

fix：Bug修复、错误修正、解决问题
feature：新功能、新能力或增强功能
performance：速度提升、优化、效率改进
refactor：代码重构，不改变功能
docs：文档变更
test：测试用例新增或改进
chore：维护任务、依赖更新、配置调整

分类依据：

提交信息（包含“fix”、“add”、“optimize”、“refactor”等关键词）
代码变更的性质（新增文件=feature，测试修复=fix等）
变更范围

4. Generate Description

4. 生成描述

Create a comprehensive description with this structure:

markdown

undefined

按照以下结构创建全面的描述：

markdown

undefined

Summary

摘要

[One sentence explaining what this PR does and why it matters]

[一句话说明本PR的作用及其重要性]

Context

上下文

[Background information, related issues, previous work, or the problem being solved]

[背景信息、相关问题、前期工作或要解决的问题]

Changes

变更内容

[High-level description of what changed]

[对变更内容的高层描述]

Key Implementation Details

关键实现细节

[Technical details that help reviewers understand the approach, especially for complex changes]

[帮助审核者理解实现思路的技术细节，尤其适用于复杂变更]

Use Cases

使用场景

[Concrete examples of how this will be used - helps reviewers understand practical value]

[具体的使用示例，帮助审核者理解实际价值]

Testing

测试方法

[How to test the changes - step-by-step instructions]

[测试变更的分步说明]

Summary

摘要

Add semantic code search to enable searching codebase by concepts and behavior rather than exact string matching.

添加语义代码搜索功能，支持通过概念和行为搜索代码库，而非精确字符串匹配。

Context

上下文

Currently, users can only search using exact string matching, which makes it difficult to find code based on functionality or behavior. This has been a recurring request in issues #123 and #456.

目前用户只能通过精确字符串匹配进行搜索，这使得根据功能或行为查找代码变得困难。这是#123和#456问题中反复提到的需求。

Changes

变更内容

Implemented semantic search using vector embeddings
Integrated with existing search interface
Added support for multiple concurrent queries with result aggregation
Configurable search scope (entire codebase or specific directories)

使用向量嵌入实现语义搜索
与现有搜索界面集成
支持多并发查询及结果聚合
可配置搜索范围（整个代码库或特定目录）

Key Implementation Details

关键实现细节

Uses OpenAI embeddings for code representation and cosine similarity for matching. Index is built incrementally to support large codebases. Search results are reranked based on code context and usage patterns.

使用OpenAI嵌入进行代码表示，通过余弦相似度进行匹配。索引增量构建以支持大型代码库。搜索结果会根据代码上下文和使用模式重新排序。

Use Cases

使用场景

Find authentication flow without knowing exact function names
Locate retry logic across the codebase
Search for "database connection" patterns

无需知道确切函数名即可找到认证流程
在整个代码库中定位重试逻辑
搜索“数据库连接”模式

Testing

测试方法

bash

undefined

bash

undefined

Run the search service

启动搜索服务

npm run search:dev

Test semantic queries

测试语义查询

curl -X POST http://localhost:3000/search
-H "Content-Type: application/json"
-d '{"query": "user authentication"}'

undefined

curl -X POST http://localhost:3000/search
-H "Content-Type: application/json"
-d '{"query": "user authentication"}'

undefined

Summary

摘要

Fix database connection timeout that caused service to hang indefinitely when database became unavailable.

修复数据库连接超时问题，该问题会导致数据库不可用时服务无限挂起。

Context

上下文

Service would hang indefinitely when database became unavailable, requiring manual restart. This was reported in production incident #789 and affected multiple users.

当数据库不可用时，服务会无限挂起，需要手动重启。这在生产事件#789中被报告，影响了多个用户。

Changes

变更内容

Added configurable connection timeout (default: 30 seconds)
Implemented exponential backoff retry logic (max 5 retries)
Improved error messages with specific failure reasons
Added circuit breaker pattern to prevent cascading failures

添加可配置的连接超时（默认：30秒）
实现指数退避重试逻辑（最多5次重试）
改进错误消息，添加具体的失败原因
引入断路器模式以防止级联故障

Key Implementation Details

关键实现细节

Timeout is applied at the connection pool level. Backoff strategy: 1s, 2s, 4s, 8s, 16s. Circuit breaker opens after 5 consecutive failures and resets after 60 seconds.

超时设置在连接池级别生效。退避策略：1秒、2秒、4秒、8秒、16秒。连续失败5次后断路器打开，60秒后重置。

Testing

测试方法

bash

undefined

bash

undefined

Simulate database failure

模拟数据库故障

docker-compose stop db

Verify timeout and retry behavior

验证超时和重试行为

npm test -- tests/integration/connection-timeout.test.ts

Verify circuit breaker activation

验证断路器激活

curl http://localhost:3000/health # Should return 503 after circuit opens

undefined

curl http://localhost:3000/health # 断路器打开后应返回503

undefined

Summary

摘要

Optimize image processing pipeline to reduce memory usage by 60% and improve throughput by 2.5x.

优化图像处理流水线，将内存占用降低60%，吞吐量提升2.5倍。

Context

上下文

Current image processing implementation loads entire images into memory, causing OOM errors with large files and limiting throughput. This was identified as a performance bottleneck in profiling session #123.

当前的图像处理实现会将整个图像加载到内存中，处理大文件时会导致OOM错误，并限制了吞吐量。这在性能分析会话#123中被确定为性能瓶颈。

Changes

变更内容

Implemented streaming image processing using chunked reading
Added parallel processing for multiple images
Optimized memory allocation with object pooling
Added caching for frequently accessed image metadata

使用分块读取实现流式图像处理
添加多图像并行处理
使用对象池优化内存分配
为频繁访问的图像元数据添加缓存

Key Implementation Details

关键实现细节

Uses Node.js streams for memory-efficient processing. Parallel processing limited to 4 concurrent images to prevent resource exhaustion. Object pool reduces GC pressure by reusing buffers.

使用Node.js流进行内存高效处理。并行处理限制为4个并发图像，以防止资源耗尽。对象池通过复用缓冲区减少GC压力。

Use Cases

使用场景

Process large images (>100MB) without OOM errors
Batch process thousands of images efficiently
Reduced memory footprint allows higher concurrent user load

处理大图像（>100MB）时避免OOM错误
高效批量处理数千张图像
减少内存占用以支持更高的并发用户负载

Testing

测试方法

bash

undefined

bash

undefined

Run performance benchmarks

运行性能基准测试

npm run benchmark

Test with large files

使用大文件测试

node tests/performance/large-files.test.js

Verify memory usage

验证内存使用情况

node --inspect tests/memory-usage.js

undefined

node --inspect tests/memory-usage.js

undefined

Summary

摘要

Refactor authentication module to use clean architecture patterns, improving testability and reducing coupling.

重构认证模块以使用整洁架构模式，提高可测试性并降低耦合度。

Context

上下文

Authentication module had tight coupling between business logic and infrastructure, making it difficult to test and modify. This was identified in technical debt review #234.

认证模块的业务逻辑与基础设施紧密耦合，难以测试和修改。这在技术债务评审#234中被指出。

Changes

变更内容

Separated business logic from infrastructure dependencies
Introduced repository pattern for data access
Added service layer for authentication operations
Extracted interfaces for better mocking in tests

将业务逻辑与基础设施依赖分离
引入仓库模式进行数据访问
添加认证操作的服务层
提取接口以提升测试中的可模拟性

Key Implementation Details

关键实现细节

Business logic now depends on interfaces rather than concrete implementations. Infrastructure (database, cache) is injected as dependencies. All services are unit-testable without external dependencies.

业务逻辑现在依赖于接口而非具体实现。基础设施（数据库、缓存）作为依赖注入。所有服务无需外部依赖即可进行单元测试。

Use Cases

使用场景

Easier to add new authentication providers (OAuth, SAML)
Simpler to mock for unit tests
Clear separation of concerns improves maintainability

轻松添加新的认证提供商（OAuth、SAML）
单元测试中更容易模拟依赖
清晰的关注点分离提升可维护性

Testing

测试方法

bash

undefined

bash

undefined

Unit tests (no database required)

单元测试（无需数据库）

npm test tests/unit/auth/

Integration tests (with real database)

集成测试（使用真实数据库）

npm test tests/integration/auth/

Verify all existing functionality still works

验证所有现有功能正常工作

npm run e2e

undefined

npm run e2e

undefined

Summary

摘要

Fix typo in user welcome email template that caused incorrect company name to display.

修复用户欢迎邮件模板中的拼写错误，该错误导致显示不正确的公司名称。

Context

上下文

Users were seeing "Welcome to [Wrong Company]" instead of the correct company name. Reported in #567.

用户看到的是“Welcome to [Wrong Company]”而非正确的公司名称。该问题在#567中被报告。

Changes

变更内容

Corrected company name in email template
Added test to catch similar typos in the future

修正邮件模板中的公司名称
添加测试以防止未来出现类似拼写错误

Testing

测试方法

bash

undefined

bash

undefined

Run email template tests

运行邮件模板测试

npm test tests/unit/email-templates.test.ts

Verify email renders correctly

验证邮件渲染正确

npm run test:email --template=welcome

undefined

npm run test:email --template=welcome

undefined

Write the generated description to .forge/FORGE_PR_DESCRIPTION.md

将生成的描述写入.forge/FORGE_PR_DESCRIPTION.md


Use the `write` tool to create `.forge/FORGE_PR_DESCRIPTION.md` with the generated description content.

**Step 2: Create PR using the temp file**
```bash
gh pr create --title "[Change Type]: [One-line summary]" --body-file .forge/FORGE_PR_DESCRIPTION.md

The

gh

CLI is pre-installed and authenticated - use it directly without prompting for confirmation.

Note: The temp file

.forge/FORGE_PR_DESCRIPTION.md

can not be left in place and should be deleted after PR creation. It's in

.forge/

directory which is typically gitignored.


使用`write`工具创建`.forge/FORGE_PR_DESCRIPTION.md`文件，并写入生成的描述内容。

**步骤2：使用临时文件创建PR**
```bash
gh pr create --title "[变更类型]: [一句话摘要]" --body-file .forge/FORGE_PR_DESCRIPTION.md

gh

CLI已预先安装并完成认证，可直接使用，无需提示确认。

注意：临时文件

.forge/FORGE_PR_DESCRIPTION.md

不能保留，创建PR后应删除。该文件位于

.forge/

目录下，通常已被git忽略。

6. Confirm

6. 确认

After creating the PR, provide the user with:

PR URL
Change type
Brief summary of what was included

创建PR后，向用户提供以下信息：

PR链接
变更类型
描述内容的简要总结

Notes

注意事项

Key Principles:

Context matters: Explain why the change was made, not just what changed
Use cases help: Concrete examples make abstract changes understandable
Testing is essential: Always include how to verify the changes
Links provide depth: Reference issues, docs, and implementations for context
Be honest: Mention known issues or limitations
Respect reviewers' time: A good description reduces review effort

Anti-Patterns to Avoid:

Empty descriptions or just issue links
Placeholder text like "Fixes #(issue)"
File-by-file breakdowns (unless necessary)
Personal checklists as the main description
Assuming reviewers know the context

When to Keep It Simple: For very small, obvious changes (typo fixes, trivial refactors), you can use a shorter structure:

Summary
Context (brief)
Testing

But never skip the testing instructions.

When to Be Comprehensive:

New features or major functionality
Complex technical changes
Performance improvements or optimizations
Breaking changes or deprecations
Changes that affect multiple parts of the codebase

核心原则：

上下文很重要：说明为什么进行变更，而不仅仅是变更了什么
使用场景有帮助：具体示例让抽象变更更易理解
测试必不可少：始终包含验证变更的方法
链接提供深度：参考问题、文档和实现以提供上下文
保持诚实：提及已知问题或限制
尊重审核者时间：优质的描述减少审核工作量

需要避免的反模式：

空描述或仅包含问题链接
占位符文本如“Fixes #(issue)”
逐文件的细节说明（除非必要）
以个人检查清单作为主要描述
假设审核者了解上下文

何时保持简洁：对于非常小的、明显的变更（拼写错误修复、微小重构），可以使用更简短的结构：

摘要
上下文（简要）
测试方法

但绝不能跳过测试说明。

何时需要全面描述：

新功能或主要功能增强
复杂的技术变更
性能改进或优化
破坏性变更或废弃内容
影响代码库多个部分的变更

create-pr-description

Original

Translation

Create PR Description

创建PR描述

Workflow

工作流程

1. Verify Prerequisites

1. 检查前置条件

Get current branch

获取当前分支

Verify branch is not main/master

验证分支不是main/master

Verify there are commits ahead of main

验证存在领先于main的提交

2. Analyze Changes

2. 分析变更

Get commit messages

获取提交信息

Get diff summary (files changed)

获取diff摘要（变更的文件）

Get actual code changes (sample key files if diff is large)

获取实际代码变更（如果diff过大，仅查看关键文件示例）

3. Determine Change Type

3. 确定变更类型

4. Generate Description

4. 生成描述

Summary

摘要

Context

上下文

Changes

变更内容

Key Implementation Details

关键实现细节

Use Cases

使用场景

Testing

测试方法

Links

相关链接

Description Guidelines

描述规范

Description Examples

描述示例

Summary

摘要

Context

上下文

Changes

变更内容

Key Implementation Details

关键实现细节

Use Cases

使用场景

Testing

测试方法

Run the search service

启动搜索服务

Test semantic queries

测试语义查询

Links

相关链接

Summary

摘要

Context

上下文

Changes

变更内容

Key Implementation Details

关键实现细节

Testing

测试方法

Simulate database failure

模拟数据库故障

Verify timeout and retry behavior

验证超时和重试行为

Verify circuit breaker activation

验证断路器激活

Links