菜单
使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/zhinkgit/normalskills --skill git-commit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
代码库 Wiki 文档生成助手，用于深度分析现有代码库、项目目录、模块边界、核心流程、配置入口和开发路径， 并将结论沉淀为结构化 Markdown 技术文档。适用于用户要求"分析这个项目/代码库"、"生成 wiki"、 "写架构文档"、"整理模块说明"、"输出技术文档"、"生成项目文档"、"梳理目录结构"、 "说明某个模块怎么开发/怎么扩展/怎么排查"、"把代码分析结果保存成文档"等场景。 当任务核心是代码库理解、架构说明、模块地图、数据流/调用流梳理、开发指南或文档沉淀时触发， 也兼容 /wiki-with-docs 显式调用。若用户只想学习一个通用概念，使用 learn 或 learn-with-docs 更合适； 若用户要求评审代码质量，使用 review 语气而不是本文档生成流程。
知识学习助手（带文档沉淀），帮助用户理解和学习各种知识点，并将讲解内容保存为独立的 Markdown 文件。 使用费曼解释法和苏格拉底式引导，将复杂概念拆解为易懂的解释、关键概念、示例图解、易错点和思考问题， 最后把整理好的知识点以独立文档形式沉淀下来，方便日后复习。 当用户提到"帮我理解"、"解释一下"、"学习"、"什么是"、"为什么"、"怎么理解"、 "讲讲"、"科普一下"、"入门"、"概念"、"原理"、"区别是什么"等学习类表达，并且 明确希望"保存"、"记录"、"写成文档"、"沉淀"时自动触发，也兼容 /learn-with-docs 显式调用。 若用户问概念性问题又想保留笔记，优先使用此 skill；若只是随手问问，使用 learn skill 更轻量。
从视频中提取连续帧、然后用视觉逐帧分析画面内容的技能，专为嵌入式软件开发调试设计。 当用户需要分析装置录像、找出显示屏中的逻辑异常（数值跳位、状态异常、界面错误等）时使用此技能。 触发场景（符合其中一条即触发，不要等用户说"用视频分析技能"）： - 用户提供了视频路径，要求分析、查问题、看哪里有异常 - 用户说视频里有"跳位""跳号""报告不连续""状态异常""数据乱跳"等现象 - 用户想从录像中找出某个具体问题发生的时间点 - 用户描述了嵌入式装置的显示屏或操作界面出现了异常，附有录像 注意：此技能不依赖预设规则——异常判断完全由 Claude 视觉分析完成，每次根据用户描述的具体现象来判断。
基于 SOC 职业分类
正在显示 SKILL.md
| name | git-commit |
| description | 使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。 |
当用户要求“提交一下”“commit”“创建 git commit”或使用 /commit 时，帮助完成一次安全、清晰、可追溯的 Git 提交。
核心目标：
优先使用单行中文 Conventional Commit：
<type>(<scope>): <中文描述>
示例：
fix(can): 修复 CAN7000 录波保存异常
docs(skills): 更新本地技能同步说明
chore(git): 调整提交助手规则
如果没有明确作用域，可以省略 scope：
docs: 更新技能列表
| 类型 | 使用场景 |
|---|---|
feat | 新增用户可见功能 |
fix | 修复缺陷、异常行为或回归 |
docs | 仅文档、说明、注释类改动 |
style | 格式、空白、排版等不影响逻辑的改动 |
refactor | 既非新增功能也非修复缺陷的代码重构 |
perf | 性能优化 |
test | 新增或调整测试 |
build | 构建系统、依赖、工程配置 |
ci | CI/CD 配置 |
chore | 维护性事务、脚本、工具配置 |
revert | 回滚已有提交 |
先查看工作区状态和分支：
git status --short --branch
必须识别：
如果工作区里有明显无关改动，不要全量暂存；只处理本次任务相关文件。
如果已有暂存内容，优先分析暂存区：
git diff --staged
如果没有暂存内容，分析工作区改动：
git diff
需要判断：
.env、真实服务器密码等敏感信息。只暂存与本次提交直接相关的文件：
git add path/to/file1 path/to/file2
禁止为了省事执行无差别暂存：
git add .
git add -A
除非用户明确要求“提交全部改动”，否则不要使用全量暂存。
对于大型混合改动，优先建议拆分提交；如果必须从同一文件里挑选部分改动，可以使用交互式暂存：
git add -p
但在自动化环境中，优先采用明确文件路径暂存，避免进入交互式流程。
提交描述应满足：
优先从文件路径、模块名、功能点推断 scope。例如：
sync-agent-skills.ps1 -> skillsembeddedskills/can/* -> canembeddedskills/gcc/* -> gccnormalskills/git-commit/* -> git单行提交：
git commit -m "type(scope): 中文描述"
需要补充正文时，使用多条 -m：
git commit -m "type(scope): 中文描述" -m "补充说明改动背景、验证结果或兼容性影响。"
提交后读取结果，向用户说明：
如果当前任务同时修改了多个独立 Git 仓库，应分仓提交。
每个仓库都要单独执行：
git status --short --branch
git diff
git add <相关文件>
git commit -m "type(scope): 中文描述"
不要跨仓库混淆提交结果。最终回复要分别列出每个仓库的提交 hash。
git reset --hard、git checkout -- <path> 等会丢弃改动的命令，除非用户明确要求。--force、--force-with-lease 推送，除非用户明确要求。--no-verify 跳过 hook，除非用户明确要求。如果提交失败：
如果发现当前状态不适合提交，例如无关改动过多、敏感文件已暂存、仓库处于 rebase/merge 冲突中，应先停止并说明原因。