菜单
根据 git diff 分析变更并生成符合 Conventional Commits 规范的提交信息。当用户提到"写commit"、"提交信息"、"commit message"、"帮我提交"、"整理改动"、"拆分提交"、暂存区代码变更、或需要按约定式提交规范撰写消息时使用此技能。生成后展示给用户确认，不主动执行 git commit。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
使用 ImageMagick 压缩本地图片文件，使用 ffmpeg 压缩本地视频文件。当 Codex 需要缩小 JPEG、PNG、WebP、HEIC、TIFF、MP4、MOV、MKV 或其他本地媒体体积时使用；适用于批量压缩文件夹、分享前缩放图片、将照片或截图默认转换为同目录同名 WebP、将视频默认压缩为同路径 MP4/H.265，保留源文件时输出到 compressed 压缩目录并镜像源目录结构，并在压缩成功后检查输出尺寸、重试 0KB 输出、默认删除或替换原文件并汇报压缩前后体积变化。
在用户需要查询 YAPI 接口文档、确认请求参数、查看响应结构、按路径或标题定位接口定义、核对某个接口的 body schema、或希望从 YAPI 拉取最新文档时使用。只要用户提到"查 YAPI""接口文档""请求参数""响应体""某个 path 的定义""YAPI 上这个接口怎么写"，即使没有明确点名这个 skill，也应优先使用。
对前端代码进行全面的代码审查，包括代码规范、性能优化、可访问性、安全性、TypeScript类型检查、React/Vue等框架最佳实践。在以下场景使用：(1) 审查前端代码质量，(2) 检查性能问题，(3) 验证可访问性，(4) 发现安全漏洞，(5) TypeScript类型检查，(6) 框架特定最佳实践检查
自动生成周报。当用户说"写周报"、"生成本周总结"时触发。
蓝湖应用开发技能，用于构建和管理蓝湖相关的应用功能
| name | git-commit-message |
| description | 根据 git diff 分析变更并生成符合 Conventional Commits 规范的提交信息。当用户提到"写commit"、"提交信息"、"commit message"、"帮我提交"、"整理改动"、"拆分提交"、暂存区代码变更、或需要按约定式提交规范撰写消息时使用此技能。生成后展示给用户确认，不主动执行 git commit。 |
基于实际 git diff 判断合适的提交类型、作用域和摘要，生成统一、语义明确的 Conventional Commits 提交信息。
优先针对已暂存内容生成提交信息；如果尚未暂存，先确认本次提交应包含的文件范围，再继续操作。
按以下模板输出可复制的提交信息。message header 中的 type 和 scope 使用英文（Conventional Commits 标准），description 和正文使用中文：
<type>[optional scope]: <description>
- 详细变更点1（中文）
- 详细变更点2（中文）
[optional footer(s)]
编写标题时注意：
| 类型 | 适用场景 |
|---|---|
feat | 新增功能 |
fix | 修复缺陷 |
docs | 仅修改文档 |
style | 仅格式或样式调整，不改变逻辑 |
refactor | 重构代码，但不是修复缺陷也不是新增功能 |
perf | 性能优化 |
test | 新增或更新测试 |
build | 构建系统、依赖或打包流程变更 |
ci | CI/CD 或自动化流程配置变更 |
chore | 维护性杂项修改 |
revert | 回滚历史提交 |
遇到破坏性变更时，使用以下两种方式之一明确标记：
feat!: 移除已废弃的 API 端点
feat(config): 支持扩展共享配置
BREAKING CHANGE: 变更 extends 字段的解析方式，旧的扁平结构不再兼容
只有在接口、行为或兼容性确实被破坏时才添加 ! 或 BREAKING CHANGE。
先检查当前仓库状态，再决定基于哪份 diff 生成提交信息：
git status --porcelain
git diff --staged
git diff
按以下规则处理：
git diff --staged每个 commit 只处理一个清晰的逻辑变更。
先向用户说明建议的文件范围，由用户决定暂存哪些文件。确认后再使用明确的暂存命令：
git add path/to/file1 path/to/file2
git add '*.test.*'
git add src/components/*
git add -p
绝不提交敏感信息，例如：
.envcredentials.json根据 diff 判断以下三个核心字段：
type：这次改动属于什么类别scope：影响的是哪个模块、目录或子系统；不明确时可以省略description：一句话概括改动结果需要补充正文或 footer 时，优先用于以下内容：
Refs #123、Closes #456生成提交信息后，以可复制的格式展示给用户确认，不主动执行提交。
仅当用户明确要求"提交"、"执行"、或给出肯定确认后，再执行。此时使用以下命令：
单行提交：
git commit -m "<type>[scope]: <description>"
需要正文或 footer 时：
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
<optional body>
<optional footer>
EOF
)"
type，不要机械按文件类型分类scope 只在确实有助于理解时使用，避免写得过细或过泛git status --short，确认不会把无关文件一起带上--no-verifyhard reset 或其他破坏性 git 操作