菜单
进行代码提交时触发。提供统一的提交标题（Conventional Commits）、正文模板、字段含义、写作风格和正反示例。应由 git-commit-standard 等提交流程 skill 强制加载。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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。在当前会话里按已写好的实现计划顺序执行任务时使用
在已有规格或多步骤任务需求、且在动代码之前使用。若上游 ddev-pc-test 已产出测试用例，自动走 TDD 流程：先实现测试 demo 代码（红灯），再实现被测代码（绿灯），测试覆盖不到的部分直接开发。
文档审查技能。将文档审查任务派发给独立子代理，重点审查文档基于代码改动的合理性、说明正确性、前后一致性、错漏和逻辑谬误，以及 AI 实现过程中产生的决策记录（implementation-notes.md）。当用户需要审查技术文档、spec文档、设计文档、计划文档、API文档、README 或任何与代码改动相关的文档时使用。
代码修改场景下，spec 文档确认后，需要继续以图优先方式梳理结构体定义、数据流和流程时使用
在代码修改前需要编写 spec 文档且应优先用图表达边界、入口、流程和改动关系时使用（仅限代码改动场景，非项目级架构文档初始化）
在代码实现完成后、准备结束任务或进入发布前使用，用来核对代码实现是否与 spec 文档以及 detail 文档一致，并通过代码质量审查、清理、编码规范和注释审查后给出最终验收结论