Codex Git 提交/拉取请求指令

请为当前工作区完成一次专业、可审计的 Git 提交。

## 一、遵循仓库规范

1. 首先读取并遵循当前仓库中的开发规范，包括但不限于：
   - AGENTS.md
   - CLAUDE.md
   - CONTRIBUTING.md
   - README.md
   - .github/ 目录下的贡献规范
   - 项目既有分支和提交信息惯例

2. 如果仓库规范与本提示词冲突，以仓库规范为准。

3. 不得修改或提交任务范围之外的用户文件。

## 二、确认提交范围

本次提交目标：

{本次变更目标}

预期涉及文件：

{允许提交的文件或目录列表}

明确排除：

{禁止提交的文件、目录、生成物、密钥、大文件或无关改动}

提交前执行：

git status --short --branch
git diff
git diff --check

要求：

- 检查工作区是否包含无关修改。
- 如果存在无关修改，不得使用 git add . 或 git add -A。
- 使用显式文件路径暂存本次变更。
- 不得暂存密钥、凭据、环境变量文件、缓存、日志、构建产物或未经授权的大文件。
- 对超过远端限制的大文件，使用 Git LFS 或项目规定的产物存储，不得强行写入普通 Git 历史。
- 不得覆盖、回滚或删除用户已有改动。

## 三、验证要求

提交前运行与本次修改风险相匹配的检查：

{需要执行的测试、静态检查、构建、格式检查或手工验证}

必须遵守：

- 只记录实际执行过的验证。
- 不得把未运行的检查描述为已通过。
- 如果检查失败，先判断是否由本次修改引起。
- 本次修改引起的失败必须修复并重新验证。
- 既有或环境相关失败必须如实记录原因和影响范围。
- 运行 git diff --check，确认不存在空白符错误。
- 提交前再次检查 git diff --cached，确认暂存内容准确。

## 四、提交信息规范

提交信息应专业、可审计，但必须保持紧凑，避免写成变更报告。

使用以下结构：

<type>(<scope>): <简洁、准确的中文描述>

- <模块或文件组>：说明核心修改、实现方式及解决的问题。
- <模块或文件组>：说明关联行为、兼容处理或关键边界。
- 验证：<命令1>（<结果>）；<命令2>（<结果>）；git diff --check（<结果>）。
- 行为边界：说明本次未改变的关键行为、接口、数据、模型或发布状态。

格式约束：

- Header 与 Body 之间只保留一个空行。
- Body 各条目之间不得插入空行。
- 不要为“验证”“行为边界”单独创建段落标题。
- 验证命令尽量合并在同一条中，使用中文分号分隔。
- Body 建议控制在 3～6 条，总行数不超过 10 行。
- 单行建议不超过 120 个字符；过长时允许自然换行，但不得在同一条目内部插入空白行。
- 只描述对理解本次提交有价值的信息，不逐文件重复陈述。
- 多个同类文件或检查应归并描述，不要每个文件、每条命令单独占一段。
- 不得生成只有 Header 的单行提交。
- 不得记录未实际执行的验证。
- 存在破坏性变更时，在正文末尾增加：
  BREAKING CHANGE: <影响、迁移方法和兼容策略>

type 根据变更性质选择：

- feat：新增功能
- fix：修复缺陷
- refactor：不改变外部行为的重构
- perf：性能优化
- test：测试修改
- docs：文档修改
- chore：构建、工具或维护工作
- ci：持续集成修改
- build：构建系统或依赖修改

## 五、执行提交

按照确认后的范围显式暂存文件，并创建提交。

提交后执行：

git status --short
git show --stat --oneline HEAD
git log -1 --format=fuller

最终返回：

1. 当前分支名称；
2. 提交哈希；
3. 完整提交标题；
4. 已提交文件列表；
5. 验证结果；
6. 未提交或被排除的工作区修改；
7. 是否已经推送远端。

除非我明确要求，否则不要自动推送、合并、重写历史或创建标签。

请为当前分支创建一个专业、可审计的 Pull Request。

## 一、遵循仓库规范

1. 首先读取并遵循：
   - AGENTS.md
   - CLAUDE.md
   - CONTRIBUTING.md
   - README.md
   - Pull Request 模板
   - CODEOWNERS
   - 仓库既有 PR 标题和正文惯例

2. 如果仓库规范与本提示词冲突，以仓库规范为准。

## 二、PR 范围

Head 分支：

{功能分支名称}

Base 分支：

{目标集成分支名称}

PR 状态：

{Draft / Ready for review；未指定时默认 Draft}

本次 PR 目标：

{PR 要解决的问题或交付目标}

明确排除：

{不属于本 PR 的功能、数据、模型、配置、部署或重构}

创建前必须确认：

- 工作区状态清楚，没有遗漏的待提交源代码。
- 功能分支已经推送到远端。
- Base 和 Head 方向正确。
- PR diff 仅包含任务范围内的提交。
- 不包含密钥、凭据、缓存、日志、构建产物或未经授权的大文件。
- 不包含调试代码、临时文件或无关格式化修改。
- 所有声称通过的测试都确实执行过。
- 如果仓库使用 Git LFS，确认大文件已正确转换为 LFS 指针。
- 如果发现提交范围混杂，停止创建 PR 并先报告问题。

## 三、PR 标题

标题采用以下格式：

<type>(<scope>): <准确概括整个 PR 的中文描述>

要求：

- 标题概括整个 PR，而不是只描述最后一个提交。
- 避免“update”“changes”“misc fixes”等模糊表达。
- type 和 scope 应与仓库惯例一致。
- 存在破坏性变更时必须明确标识。

## 四、PR 正文结构

请使用以下结构撰写正文：

## 背景

说明：

- 当前存在什么问题或需求；
- 问题如何被发现；
- 根因是什么；
- 为什么需要现在处理；
- 对用户、业务、开发或运维有什么影响。

## 解决方案

说明总体实现策略，以及为什么选择该方案。

如存在备选方案，应简要说明没有采用的原因。

## 主要变更

按模块或文件组分点说明：

- 修改了什么；
- 采用什么实现方式；
- 解决什么问题；
- 对现有接口、数据和行为有什么影响；
- 如何处理兼容性和异常边界。

## 行为变化

分别列出：

- 新增行为；
- 修复行为；
- 保持不变的关键行为；
- 已弃用或移除的行为；
- 是否存在 Breaking Change。

如果没有外部行为变化，应明确写明。

## 验证

列出实际执行过的验证：

- `<命令>`：<结果和覆盖范围>
- `<命令>`：<结果和覆盖范围>
- 手工验证：<场景和结果>

不得把未执行的检查写成已通过。

如果存在未运行的检查，应写明：

- 未运行原因；
- 可能影响；
- 后续补充方式。

## 风险评估

说明：

- 主要技术风险；
- 数据或兼容性风险；
- 性能、资源和安全影响；
- 可能受影响的上下游；
- 风险缓解措施。

## 发布与迁移

根据实际情况说明：

- 是否需要数据库迁移；
- 是否需要配置变更；
- 是否需要重新构建或部署；
- 是否需要数据回填；
- 是否需要重新训练、重新索引或清缓存；
- 是否需要灰度发布；
- 是否支持回滚；
- 回滚步骤是什么。

无相关要求时明确写“无需”。

## 产物与证据

列出必要的：

- 报告；
- 截图或录屏；
- 性能数据；
- 测试结果；
- 模型或数据产物；
- SHA256、版本号或发布包；
- 关联 issue、设计文档或事故记录。

大文件应存放于 Git LFS、Release、制品库或项目规定的存储位置，不得直接塞入普通 Git 历史。

## 后续工作

列出不在本 PR 范围内、但需要继续跟踪的事项。

避免用本节掩盖当前 PR 必须解决的问题。

## Reviewer 指引

指出 Reviewer 应重点检查：

- 哪些文件或模块最关键；
- 哪些逻辑风险最高；
- 哪些行为需要特别验证；
- 是否存在需要业务、临床、安全或运维人员确认的决策。

## 五、创建规则

- 默认创建 Draft PR，除非我明确要求 Ready for review。
- 不得自动合并。
- 不得自动删除分支。
- 不得修改分支保护规则。
- 不得绕过必需检查或 Reviewer。
- 不得把失败检查描述为无关，除非有明确证据。
- 创建后检查 PR 的 Base、Head、Draft 状态、提交列表和文件范围。

## 六、最终返回

创建完成后返回：

1. PR 标题；
2. PR URL；
3. Base 和 Head 分支；
4. Draft/Ready 状态；
5. 包含的提交列表；
6. 变更文件数量和主要模块；
7. 验证结果；
8. 已知风险；
9. 未包含的事项；
10. Reviewer 应重点关注的内容。

除非我明确授权，否则不要执行 Merge。