🇨🇳中文介绍

原子提交

适用于非 TDD 工作流的独立技能。通过分析变更和检测混合关注点，帮助创建清晰、原子的提交。

原子提交定义

• 只做一件事（一个功能/修复/重构）
• 使代码库保持在可工作状态（构建和测试通过）
• 可以独立回滚
• 不混合无关的关注点

工作流程

1. 分析变更

git status && git diff && git diff --staged

2. 检测混合关注点

查找混合了以下内容的文件：

• 多个功能
• 错误修复 + 功能
• 重构 + 新功能
• 多个不相关的错误修复
• 代码 + 文档（除非针对同一功能）
• 针对多个功能的测试

3. 分组提交

按共同目的对文件进行分组。将分组结果呈现给用户确认。

示例：

分组 1: "添加用户认证" → auth/login.ts, auth/session.ts, tests/auth/login.test.ts
分组 2: "修复密码验证" → validators/password.ts, tests/validators/password.test.ts

4. 创建每个提交

对于每个分组：

1. 暂存: git add <file1> <file2> (不要使用 git add .)
2. 审查: git diff --staged
3. 测试: 运行测试，确保通过
4. 构建: 如果适用，运行构建，确保成功
5. 提交: 使用约定式提交格式
6. 验证: git log -1 --oneline

约定式提交类型: feat|fix|refactor|docs|test|chore|perf|style

5. 最终检查

git log --oneline -n <N>

问题集成

• 检查用户消息或分支名称中是否有问题编号
• 如果没有问题：询问用户是否想创建一个
  • 如果用户不想提供，则留空
• 如果是：帮助编写描述，提供 gh issue create 或 glab issue create 选项
  • 在提交中包含："feat: 描述 (#42)"

指南

应该做： 一个逻辑变更，包含相关测试，运行测试，清晰的消息，问题编号 不要做： 混合功能/修复/重构，提交损坏的代码，模糊的消息，调试代码

TODO 模式

☐ 分析: git status/diff ☐ 识别文件目的 ☐ 检测混合关注点 ☐ 分组为原子提交 ☐ 与用户确认 ☐ 对于每个：暂存 → 审查 → 测试 → 构建 → 提交 → 验证 ☐ 最终审查

激活

当用户说以下内容时使用："atomic", "clean commits", "break down commits", "split commits" 不要用于 TDD 工作流（使用 TDG 技能）。

结束语

"已创建 N 个原子提交。测试通过。您想查看历史记录、推送还是创建 PR？"

每周安装次数

–

来源

smithery.ai/ski…c-commit

首次出现

–

git status && git diff && git diff --staged

Group 1: "Add user auth" → auth/login.ts, auth/session.ts, tests/auth/login.test.ts
Group 2: "Fix password validation" → validators/password.ts, tests/validators/password.test.ts