القائمة
进行代码提交时触发。提供统一的提交标题（Conventional Commits）、正文模板、字段含义、写作风格和正反示例。应由 git-commit-standard 等提交流程 skill 强制加载。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例，自动走 TDD 流程：先实现测试 demo 代码（红灯），再实现被测代码（绿灯），测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论
| name | git-commit-template |
| description | 进行代码提交时触发。提供统一的提交标题（Conventional Commits）、正文模板、字段含义、写作风格和正反示例。应由 git-commit-standard 等提交流程 skill 强制加载。 |
提交说明的书写规范与模板。不负责提交流程（版本、固件、changelog 同步等），只定义 commit message 怎么写。
标题使用 Conventional Commits 格式，英文小写 type，可追加 scope，中文描述：
<type>[scope]: <中文描述>
| type | 用途 |
|---|---|
feat | 新功能 |
fix | 修复缺陷 |
docs | 文档变更 |
style | 格式/风格（无逻辑变更） |
refactor | 代码重构（无功能/修复变更） |
perf | 性能优化 |
test | 新增/更新测试 |
build | 构建/依赖变更 |
ci | CI/配置变更 |
chore | 维护/杂项 |
示例：
refactor: 简化编码规范流程并增强编译指令生成feat[agent-browser]: 新增截图对比功能fix: 修复 skills 链接在 Windows 下失效主题行可使用 Conventional Commits 简写（如 feat: xxx、fix: xxx），但正文必须包含以下字段（格式优先参考仓库既有提交历史）：
版本：<artifact-or-release-version，无版本号则填 N/A>
时间：<date>
修改者：<git config user.name>
更改点：
1）修改原因：
1. <why-1>
2. <why-2>
2）修改依据：
1. <basis-1>
2. <basis-2>
3）修改方法：
1. <how-1>
2. <how-2>
4）修改影响：
1. <impact-1>
2. <impact-2>
若仓库已有自己的模板，按仓库模板。
| 字段 | 来源 | 说明 |
|---|---|---|
| type[scope] | 标题 | Conventional Commits 格式 |
| 版本 | 版本源文件或发布版本号；若无版本号，填 N/A | 不把长版本信息塞进标题；禁止在没有版本号时尝试查找或推导版本号 |
| 时间 | 当前日期 | 格式沿用仓库历史；若无固定格式，使用 YYYY.MM.DD |
| 修改者 | git config user.name | 除非仓库另有要求 |
| 修改原因 | 本次改动要解决什么问题 | 从用户/产品/业务角度说明 |
| 修改依据 | 基于什么理由做这个修改 | 需求、bug、设计文档等 |
| 修改方法 | 关键实现手段摘要 | 只写方法摘要，不展开实现细节 |
| 修改影响 | 对用户/系统/兼容性的影响 | 只写关键结果，不写过细技术影响 |
type[scope]: 中文描述，聚焦提交目的，简练清晰。修改原因/修改依据/修改方法/修改影响 后直接跟一大句完整说明而不分点（除非仓库历史模板明确要求单段写法）。1. 2. 3. 子点，不要把多个主题塞进一个长句、分号串联句或并列从句里。推荐（短句概括，最多 3 点）：
3）修改方法：
1. 收口提交正文模板
2. 增加最多 3 点约束
3. 补充正反示例
不推荐（长句串联、函数级细节）：
3）修改方法：收口提交正文模板并增加最多 3 点约束，同时补充正反示例以
避免提交时继续输出整段长句。修改了 validate_template() 函数内部的状态机
处理，增加了字段级校验和回退逻辑。
推荐（用户/业务视角）：
4）修改影响：
1. 提交模板统一为四字段结构
2. 不再接受整段式提交说明
不推荐（过细技术影响）：
4）修改影响：
1. 旧的单段提交格式会被拒绝
2. 内部 session 状态切换逻辑不变
3. 兼容旧版本 review 工具
N/A。