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 的中文描述>

要求：

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



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



说明：

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



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

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



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

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



分别列出：

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

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



列出实际执行过的验证：

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

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

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

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



说明：

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



根据实际情况说明：

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

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



列出必要的：

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

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



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

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



指出 Reviewer 应重点检查：

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



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



创建完成后返回：

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

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