Skip to content

[copilot]:Improve the copilot guide #10952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Rbb666 merged 1 commit into from
Nov 18, 2025
Merged

[copilot]:Improve the copilot guide #10952

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
175 changes: 160 additions & 15 deletions .github/copilot-instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,8 @@ RT-Thread is a real-time operating system (RTOS) for embedded devices. When work

RT-Thread 是一个面向嵌入式设备的实时操作系统（RTOS）。在处理 RT-Thread 代码时，请遵循以下指南以确保高质量的贡献。

**When reviewing Pull Requests (PRs), you MUST check all items in the PR Review Checklist section and provide feedback according to the PR Review Instructions. / 在审查 Pull Request (PR) 时，必须检查 PR 审查清单部分中的所有项目，并根据 PR 审查指令提供反馈。**

## Code Review Guidelines / 代码审查指南

### Language Requirements / 语言要求
Expand All @@ -26,21 +28,162 @@ When reviewing code, provide feedback in **both English and Chinese** to ensure
- Follow RT-Thread coding standards / 遵循 RT-Thread 编码标准
- Maintain consistent naming conventions / 保持一致的命名约定
- Ensure proper code comments (not documentation) / 确保适当的代码注释（而非文档）
4. **PR Title Naming Guidelines / PR 标题命名规范**
- **Specify the module or keyword / 明确模块或关键字**：
- 标题需明确指出涉及的具体模块、子系统或关键字，例如具体的 BSP（Board Support Package）或芯片厂商名称（如 STM32, ESP32, NXP 等）。
- 示例：[STM32][I2C] Fix Kconfig parsing error 而非 fix:I2C——Kconfig修改。
- **Clearly describe the content being repaired or modified / 清晰描述修复或更改内容**：
- 标题需简洁清晰地描述修复的问题、添加的功能或修改的内容，避免模糊或过于简略的描述。
- 示例：[STM32][SPI] Fix buffer overflow in SPI driver 而非 SPI bug fix。
- **Format Recommendations / 格式建议**：
- 推荐使用 [模块/厂商][子系统] 具体描述 的格式，确保标题结构化且信息完整。
- 使用英文描述问题（除非项目明确要求使用其他语言），以提高国际化可读性。
- 示例：[NXP][UART] Add timeout handling for UART receive。
- **Issues to Avoid / 避免的问题**：
- 不要使用模糊的术语，如“修复问题”或“代码优化”，需具体说明问题或优化的内容。
- 避免使用不规范的符号（如 ——），建议使用标准英文字符（如 - 或 :）。
- 不要省略关键上下文信息，如 BSP 或芯片厂商。
4. **PR Review Checklist / PR 审查清单**
- **PR Title Review / PR 标题审查**：
- Check if PR title has proper prefix format / 检查 PR 标题是否有正确的前缀格式
- Verify prefix follows pattern: `[module/vendor][subsystem]` or `[module/vendor]` in lowercase / 验证前缀遵循格式：小写的 `[模块/厂商][子系统]` 或 `[模块/厂商]`
- Verify title describes changes based on modified files / 验证标题基于修改的文件描述变更
- Check if title is specific enough (avoid vague terms like "fix bug", "optimize code") / 检查标题是否足够具体（避免模糊术语如"修复问题"、"代码优化"）
- If title lacks prefix or uses incorrect format, suggest: "PR title should follow format: `[module][subsystem] Description`. Example: `[stm32][drivers] Fix UART interrupt handling issue`" / 如果标题缺少前缀或格式错误，建议："PR 标题应遵循格式：`[模块][子系统] 描述`。示例：`[stm32][drivers] Fix UART interrupt handling issue`"
- **PR Description Review / PR 内容审查**：
- Check if PR description provides overview of modified files / 检查 PR 描述是否提供了修改文件的总概
- Verify description explains: What (what changes), Why (why needed), How (which files modified) / 验证描述是否说明：What（做了什么修改）、Why（为什么需要）、How（修改了哪些文件）
- If description is missing or insufficient, suggest adding description with modified files list / 如果描述缺失或不充分，建议添加包含修改文件列表的描述
- **PR File Modification Review / PR 修改文件审查**：
- Check if PR contains multiple unrelated features / 检查 PR 是否包含多个不相关的特性
- If PR mixes multiple features, suggest splitting into separate PRs / 如果 PR 混杂多个特性，建议拆分为多个 PR
- Verify all file changes are related to the same feature/bug fix / 验证所有文件修改是否与同一功能/错误修复相关
- **PR Commit Review / PR Commit 审查**：
- Check commit message format (should follow PR title format) / 检查 commit 消息格式（应遵循 PR 标题格式）
- Verify if commits are properly organized / 验证 commit 是否组织得当
- If routine changes (style fixes, minor bugs, docs, typos) are split into multiple commits, suggest squashing them / 如果常规修改（风格修复、小错误、文档、拼写）被拆分为多个 commit，建议压缩它们
- Important commits (major features, refactoring, critical bugs) can remain separate / 重要提交（主要功能、重构、关键错误）可以保持独立
- If commit messages don't follow format, suggest: "Commit message should follow format: `[module][subsystem] Description`. Consider squashing routine changes into one commit." / 如果 commit 消息不符合格式，建议："Commit 消息应遵循格式：`[模块][子系统] 描述`。考虑将常规修改压缩为一个 commit。"

### PR Review Instructions / PR 审查指令

**When reviewing a PR, you MUST systematically check the following items and provide feedback for any violations / 审查 PR 时，必须系统性地检查以下项目，并对任何违规行为提供反馈：**

#### Step 1: PR Title Check / 步骤 1：PR 标题检查

1. **Check prefix format / 检查前缀格式**:
- Extract the PR title from the PR / 从 PR 中提取 PR 标题
- Verify if it starts with `[module][subsystem]` or `[module]` pattern in lowercase / 验证是否以小写的 `[模块][子系统]` 或 `[模块]` 格式开头
- Check if prefix matches the modified files (e.g., if files are in `bsp/stm32/drivers/`, prefix should be `[stm32][drivers]` or similar) / 检查前缀是否与修改的文件匹配（例如，如果文件在 `bsp/stm32/drivers/`，前缀应为 `[stm32][drivers]` 或类似）
- If prefix is missing, incorrect case (e.g., `[STM32]`), or doesn't match files, provide feedback / 如果前缀缺失、大小写错误（如 `[STM32]`）或不匹配文件，提供反馈
- **Feedback template / 反馈模板**:
```
🟡 [PR Title/PR 标题]: Missing or incorrect prefix format / 缺少或错误的前缀格式

English: PR title should follow format: `[module][subsystem] Description` in lowercase.
Current title: `{current_title}`.
Based on modified files, suggested title: `{suggested_title}`.

中文：PR 标题应遵循格式：小写的 `[模块][子系统] 描述`。
当前标题：`{current_title}`。
基于修改的文件，建议标题：`{suggested_title}`。
```

2. **Check title specificity / 检查标题具体性**:
- Analyze modified files to understand what changes were made / 分析修改的文件以了解所做的更改
- Verify if title accurately describes changes based on modified files / 验证标题是否基于修改的文件准确描述更改
- Check for vague terms: "fix bug", "optimize code", "update", "modify", etc. / 检查模糊术语："修复问题"、"代码优化"、"更新"、"修改"等
- If title is vague or doesn't match modified files, suggest a more specific title / 如果标题模糊或不匹配修改的文件，建议更具体的标题
- **Feedback template / 反馈模板**:
```
🟡 [PR Title/PR 标题]: Title is too vague or doesn't match modified files / 标题过于模糊或不匹配修改的文件

English: PR title should specifically describe changes based on modified files.
Current title: `{current_title}`.
Suggested: `{suggested_title}` based on files: {list_modified_files}.

中文：PR 标题应基于修改的文件具体描述更改。
当前标题：`{current_title}`。
建议：基于文件 {list_modified_files} 的 `{suggested_title}`。
```

#### Step 2: PR Description Check / 步骤 2：PR 内容检查

1. **Check description completeness / 检查描述完整性**:
- Read the PR description / 阅读 PR 描述
- Verify if it includes: / 验证是否包含：
- Overview of modified files / 修改文件的总概
- What changes were made / 做了什么修改
- Why changes are needed / 为什么需要这些修改
- List of modified files (optional but recommended) / 修改文件列表（可选但推荐）
- If description is missing, empty, or insufficient, provide feedback / 如果描述缺失、为空或不充分，提供反馈
- **Feedback template / 反馈模板**:
```
🟢 [PR Description/PR 描述]: Missing or insufficient description / 缺少或不充分的描述

English: PR description should include: (1) Overview of modified files, (2) What changes were made, (3) Why changes are needed, (4) List of modified files (optional).
Please add/modify the PR description.

中文：PR 描述应包含：(1) 修改文件的总概，(2) 做了什么修改，(3) 为什么需要这些修改，(4) 修改文件列表（可选）。
请添加/修改 PR 描述。

Example format / 示例格式:
## Description / 描述
This PR fixes the UART interrupt handling issue in STM32 serial driver.
本次 PR 修复了 STM32 串口驱动中的中断处理问题。

## Modified Files / 修改文件
- `bsp/stm32/drivers/drv_usart.c`: Fixed interrupt handler logic
- `bsp/stm32/drivers/drv_usart.h`: Updated function declarations
```

#### Step 3: PR File Modification Check / 步骤 3：PR 修改文件检查

1. **Check feature separation / 检查特性分离**:
- List all modified files in the PR / 列出 PR 中的所有修改文件
- Group files by feature/functionality / 按特性/功能对文件进行分组
- Identify if multiple unrelated features are mixed / 识别是否混杂了多个不相关的特性
- Unrelated features include: different drivers, different subsystems, unrelated bug fixes, etc. / 不相关的特性包括：不同的驱动、不同的子系统、不相关的错误修复等
- If multiple unrelated features are found, provide feedback with specific suggestions / 如果发现多个不相关的特性，提供具体建议的反馈
- **Feedback template / 反馈模板**:
```
🟡 [PR Structure/PR 结构]: Multiple unrelated features in one PR / 一个 PR 中包含多个不相关的特性

English: This PR contains multiple unrelated features: {list_features}.
Please split into separate PRs, each focusing on one feature.
Suggested PRs:
- PR 1: `[module1][subsystem1] {feature1_description}` (files: {list_files1})
- PR 2: `[module2][subsystem2] {feature2_description}` (files: {list_files2})

中文：此 PR 包含多个不相关的特性：{list_features}。
请拆分为多个 PR，每个专注于一个特性。
建议的 PR：
- PR 1: `[模块1][子系统1] {特性1描述}` (文件: {list_files1})
- PR 2: `[模块2][子系统2] {特性2描述}` (文件: {list_files2})
```

#### Step 4: PR Commit Check / 步骤 4：PR Commit 检查

1. **Check commit message format / 检查 commit 消息格式**:
- Review all commit messages in the PR / 审查 PR 中的所有 commit 消息
- Verify if each commit message follows format: `[module][subsystem] Description` / 验证每个 commit 消息是否遵循格式：`[module][subsystem] 描述`
- Check if commit message prefix matches PR title prefix / 检查 commit 消息前缀是否与 PR 标题前缀匹配
- If commit messages don't follow format, provide feedback / 如果 commit 消息不符合格式，提供反馈
- **Feedback template / 反馈模板**:
```
🟡 [Commit Message/Commit 消息]: Commit message format violation / Commit 消息格式违规

English: Commit message should follow format: `[module][subsystem] Description`.
Invalid commits: {list_invalid_commits}.
Example: `[stm32][drivers] Fix UART interrupt handling issue`.

中文：Commit 消息应遵循格式：`[模块][子系统] 描述`。
无效的 commit：{list_invalid_commits}。
示例：`[stm32][drivers] Fix UART interrupt handling issue`。
```

2. **Check commit organization / 检查 commit 组织**:
- Identify routine changes: style fixes, minor bugs, documentation updates, typo corrections / 识别常规修改：风格修复、小错误、文档更新、拼写错误修正
- Identify important changes: major features, significant refactoring, critical bug fixes / 识别重要更改：主要功能、重大重构、关键错误修复
- Check if routine changes are split into multiple commits / 检查常规修改是否被拆分为多个 commit
- If routine changes are split, suggest squashing them / 如果常规修改被拆分，建议压缩它们
- **Feedback template / 反馈模板**:
```
🟢 [Commit Organization/Commit 组织]: Routine changes should be squashed / 常规修改应压缩

English: Routine changes (style fixes, minor bugs, docs, typos) should be squashed into one commit.
Commits to squash: {list_commits_to_squash}.
Please use `git rebase -i` to squash these commits.

中文：常规修改（风格修复、小错误、文档、拼写）应压缩为一个 commit。
要压缩的 commit：{list_commits_to_squash}。
请使用 `git rebase -i` 压缩这些 commit。
```

### Review Comment Format / 审查评论格式

Expand All @@ -59,6 +202,8 @@ Example/示例:
// Your code example here / 你的代码示例
```
```

**For PR-related issues, use severity level 🟡 Minor or 🟢 Suggestion / 对于 PR 相关的问题，使用严重程度级别 🟡 Minor 或 🟢 Suggestion**
### Common Issues to Check / 常见问题检查

1. **Resource Management / 资源管理**
Expand Down