Menu
使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Grok 实时联网搜索与事实核验技能，调用 scripts/grok_search.py 获取带来源链接的 JSON 研究结果。凡是用户明确要求搜索、联网、查最新、核实资料、找来源、查官网文档、查新闻、版本、价格、法规、API 变更、错误信息、模型发布、竞品资料，或问题可能因时间变化而过期时，都应积极触发；即使用户没有明说搜索，只要答案需要外部证据、当前状态或精确出处，也优先使用本技能。输出和后续总结默认使用简体中文。
代码库 Wiki 文档生成助手，用于深度分析现有代码库、项目目录、模块边界、核心流程、配置入口和开发路径， 并将结论沉淀为结构化 Markdown 技术文档。适用于用户要求"分析这个项目/代码库"、"生成 wiki"、 "写架构文档"、"整理模块说明"、"输出技术文档"、"生成项目文档"、"梳理目录结构"、 "说明某个模块怎么开发/怎么扩展/怎么排查"、"把代码分析结果保存成文档"等场景。 当任务核心是代码库理解、架构说明、模块地图、数据流/调用流梳理、开发指南或文档沉淀时触发， 也兼容 /wiki-with-docs 显式调用。若用户只想学习一个通用概念，使用 learn 或 learn-with-docs 更合适； 若用户要求评审代码质量，使用 review 语气而不是本文档生成流程。
知识学习助手（带文档沉淀），帮助用户理解和学习各种知识点，并将讲解内容保存为独立的 Markdown 文件。 使用费曼解释法和苏格拉底式引导，将复杂概念拆解为易懂的解释、关键概念、示例图解、易错点和思考问题， 最后把整理好的知识点以独立文档形式沉淀下来，方便日后复习。 当用户提到"帮我理解"、"解释一下"、"学习"、"什么是"、"为什么"、"怎么理解"、 "讲讲"、"科普一下"、"入门"、"概念"、"原理"、"区别是什么"等学习类表达，并且 明确希望"保存"、"记录"、"写成文档"、"沉淀"时自动触发，也兼容 /learn-with-docs 显式调用。 若用户问概念性问题又想保留笔记，优先使用此 skill；若只是随手问问，使用 learn skill 更轻量。
从视频中提取连续帧、然后用视觉逐帧分析画面内容的技能，专为嵌入式软件开发调试设计。 当用户需要分析装置录像、找出显示屏中的逻辑异常（数值跳位、状态异常、界面错误等）时使用此技能。 触发场景（符合其中一条即触发，不要等用户说"用视频分析技能"）： - 用户提供了视频路径，要求分析、查问题、看哪里有异常 - 用户说视频里有"跳位""跳号""报告不连续""状态异常""数据乱跳"等现象 - 用户想从录像中找出某个具体问题发生的时间点 - 用户描述了嵌入式装置的显示屏或操作界面出现了异常，附有录像 注意：此技能不依赖预设规则——异常判断完全由 Claude 视觉分析完成，每次根据用户描述的具体现象来判断。
知识学习助手，帮助用户理解和学习各种知识点。使用费曼解释法和苏格拉底式引导， 将复杂概念拆解为易懂的解释、关键概念、示例图解、易错点和思考问题。 当用户提到"帮我理解"、"解释一下"、"学习"、"什么是"、"为什么"、"怎么理解"、 "讲讲"、"科普一下"、"入门"、"概念"、"原理"、"区别是什么"等学习类表达时自动触发， 也兼容 /learn 显式调用。即使用户只是问一个概念性问题（如"什么是闭包"、 "TCP 三次握手为什么不是两次"），触发准则：用户提问核心是理解概念（如"什么是""为什么""怎么理解"）， 而非请求代码实现（如"写一个…""实现…"）时触发此 skill；若问题同时涉及概念理解与编码， 优先触发此 skill 提供概念解释，并在必要时辅以少量代码示例。
Based on SOC occupation classification
| 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 冲突中，应先停止并说明原因。