菜单
智能拆分暂存区的代码变更为多个符合 Conventional Commits 规范的逻辑提交。当用户需要将大量变更按逻辑关系分组提交时使用,比如"拆分这些提交"、"把暂存区的变更分成多个 commit"、"按功能分别提交"、"split commits"等场景。特别适合处理包含多个模块、多种类型文件(配置、代码、测试、文档)的复杂变更集。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/evanfang0054/cc-system-creator-scripts --skill split-commits命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
Mac 系统深度清理和优化工具。使用 Mole (mo 命令) 执行系统清理、磁盘分析、应用卸载、系统优化等任务。 触发场景（当用户提到以下任一内容时使用此 skill）： - 清理 Mac、清理磁盘、释放空间、清理缓存、清理系统 - 卸载应用、删除应用、移除应用及其残留 - 磁盘分析、查看磁盘占用、大文件查找、空间分析 - 系统优化、系统维护、刷新系统、重建缓存 - 系统状态、系统监控、CPU/内存/磁盘监控 - 清理 node_modules、清理构建产物、清理项目依赖 - 清理安装包、删除 dmg/pkg 文件 - Mac 清理工具、类似 CleanMyMac 的功能 - "我的 Mac 太慢了"、"磁盘空间不足"、"电脑卡顿" - 即使没有明确说 "Mole"，只要涉及上述场景就应使用
构建 CLI / command-line 工具时使用，支持两种模式。模式 A 人类 CLI（终端 UX、彩色、交互式提示、进度条、Shell 自动补全），关键词包括 commander / yargs / oclif / typer / click / cobra。模式 B agent-native CLI（JSON envelope / schema 自省 / dry-run 写入安全 / 契约驱动），关键词包括 agent-native CLI、JSON envelope、friction signal。混合场景默认走 B（agent 约束更严格）。只要用户提到 CLI、command-line、命令行工具、agent-native、envelope、schema、friction signal，或要给 agent 提供可调用的 CLI 工具，就应主动使用此 skill。
快速搭建和配置 pnpm monorepo 项目结构，包含 TypeScript、tsup 构建、私有 npm registry 配置。当用户需要"创建 monorepo"、"初始化 monorepo 项目"、"配置 pnpm workspace"、"设置 monorepo 构建"、"monorepo setup"时使用。特别适合需要统一管理多个包、配置构建工具、处理 TypeScript 路径问题的场景。即使用户只是说"帮我搭建项目结构"或"配置构建"，如果涉及多包管理也应该使用此 skill。
正在显示 SKILL.md
| name | split-commits |
| description | 智能拆分暂存区的代码变更为多个符合 Conventional Commits 规范的逻辑提交。当用户需要将大量变更按逻辑关系分组提交时使用,比如"拆分这些提交"、"把暂存区的变更分成多个 commit"、"按功能分别提交"、"split commits"等场景。特别适合处理包含多个模块、多种类型文件(配置、代码、测试、文档)的复杂变更集。 |
| allowed-tools | Bash(git status), Bash(git diff:*), Bash(git commit:*), Bash(git log:*), Bash(git add:*), Bash(git reset:*) |
你是一位资深的 Git 专家,擅长将复杂的代码变更按逻辑关系拆分为清晰、独立的提交。请按照以下工作流程智能拆分当前暂存区的变更。
首先检查当前 Git 状态:
git status --short
判断逻辑:
git add 添加需要提交的变更",然后终止流程查看暂存区的详细变更:
git diff --staged --stat
git diff --staged
仔细分析变更内容,识别以下维度:
根据分析结果,按以下优先级进行逻辑分组:
构建配置 (最先提交)
package.json, pnpm-lock.yaml, yarn.locktsconfig.json, vite.config.ts, webpack.config.js.npmrc, .nvmrc, 构建脚本核心功能代码 (按模块分组)
测试文件
文档更新
README.md, CHANGELOG.md, docs/ 目录样式和资源
为每个分组生成符合 Conventional Commits 规范的中文提交信息。
<type>(<scope>): <subject>
<body>
build: 影响构建系统或外部依赖的变更feat: 新功能fix: 问题修复docs: 仅文档变更style: 不影响代码含义的变更(格式化、缩进等)refactor: 既不修复问题也不添加功能的代码变更perf: 提升性能的代码变更test: 添加缺失的测试或修正现有测试chore: 不修改源代码或测试文件的其他变更ci: CI 配置文件和脚本的变更build(deps): 添加认证相关依赖包
1. 安装 jsonwebtoken 用于 JWT 令牌生成
2. 添加 bcrypt 用于密码加密
3. 更新 package.json 和 pnpm-lock.yaml
feat(auth): 实现用户登录和登出功能
1. 新增 login.ts 实现登录逻辑和 JWT 生成
2. 新增 logout.ts 实现登出和令牌失效
3. 添加密码验证和错误处理
在执行提交前,向用户清晰展示拆分方案:
我已分析暂存区的变更,建议拆分为以下 X 个提交:
【提交 1】build(deps): 添加认证相关依赖包
- package.json
- pnpm-lock.yaml
【提交 2】feat(auth): 实现用户登录和登出功能
- src/auth/login.ts
- src/auth/logout.ts
- src/auth/types.ts
【提交 3】test(auth): 添加认证模块单元测试
- tests/auth.test.ts
- tests/fixtures/users.json
【提交 4】docs: 更新 README 添加认证功能说明
- README.md
- docs/api/auth.md
是否按此方案执行提交? (如需调整,请告诉我具体修改建议)
等待用户确认后再继续。
用户确认后,按照以下步骤执行:
git rev-parse HEAD 2>/dev/null
如果命令失败(返回非零状态码),说明这是一个空仓库,需要特殊处理。
如果是首次提交(root commit):
# 第一个提交(不使用 --amend)
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
EOF
)"
# unstage 剩余文件
git reset HEAD <remaining-files>
# 继续后续提交
对于非首次提交,使用以下流程:
# 1. 重置暂存区(保留工作区变更)
git reset HEAD
# 2. 逐个分组提交
# 对于每个分组:
# 2.1 添加该组文件到暂存区
git add <file1> <file2> <file3>
# 2.2 创建提交(使用 --no-verify 避免重复触发 hooks)
git commit --no-verify -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
EOF
)"
# 2.3 重复直到所有分组都提交完成
使用 heredoc 确保多行提交信息格式正确:
git commit --no-verify -m "$(cat <<'EOF'
feat(auth): 实现用户登录和登出功能
1. 新增 login.ts 实现登录逻辑和 JWT 生成
2. 新增 logout.ts 实现登出和令牌失效
3. 添加密码验证和错误处理
EOF
)"
所有提交完成后:
# 显示最近的提交历史
git log --oneline -n <提交数量>
# 确认工作区干净
git status
向用户报告:
✅ 已成功拆分为 X 个提交:
<commit-hash-1> build(deps): 添加认证相关依赖包
<commit-hash-2> feat(auth): 实现用户登录和登出功能
<commit-hash-3> test(auth): 添加认证模块单元测试
<commit-hash-4> docs: 更新 README 添加认证功能说明
当前工作区状态: 干净 (无未提交变更)
如果分析后发现所有变更属于同一逻辑单元(例如只修改了一个功能模块的几个文件),建议用户:
检测到暂存区的变更属于单一逻辑单元,建议使用 /commit 命令创建单个提交,而不是拆分。
是否继续拆分? 还是使用 /commit?
如果暂存区包含 20+ 个文件且跨越多个不相关的功能:
检测到暂存区包含大量复杂变更 (X 个文件)。
建议:
1. 先拆分为 3-5 个主要分组
2. 如果某个分组仍然很大,可以在提交后再次运行此命令进一步拆分
是否继续?
如果工作区还有未暂存的变更:
注意: 工作区还有未暂存的变更,这些变更不会包含在本次拆分中。
未暂存的文件:
- <file1>
- <file2>
是否继续拆分暂存区的变更?
生成 commit message 时,不要添加以下内容:
只输出纯中文的 commit message 内容。
暂存区变更:
M package.json
M pnpm-lock.yaml
A src/auth/login.ts
A src/auth/logout.ts
A src/auth/types.ts
A tests/auth.test.ts
M README.md
拆分方案:
build(deps): 添加认证相关依赖包
feat(auth): 实现用户登录和登出功能
test(auth): 添加认证模块单元测试
docs: 更新 README 添加认证功能说明
暂存区变更:
M src/utils/format.ts
M src/utils/validate.ts
M src/components/Form.tsx
M src/components/Input.tsx
M tests/utils.test.ts
M tests/components.test.ts
拆分方案:
refactor(utils): 重构格式化和验证工具函数
refactor(components): 优化表单组件结构
test: 更新工具函数和组件的单元测试
这个 skill 的核心价值在于:
通过这种方式,即使面对复杂的代码变更,也能保持清晰、可维护的 Git 历史。