| name | dk-front-git-auto-commit-push |
| description | Git 自动暂存、提交并推送。当用户要求提交代码、推送代码、commit、push、提交并推送、自动提交、暂存提交推送、或任何涉及 git commit/push 操作时使用本技能。也适用于用户说"提交一下"、"推一下代码"、"帮我提交"、"push 上去"、"仅提交"、"只 commit"等口语化表述。 |
Git 自动暂存、提交并推送
自动分析所有更改（已暂存和未暂存），智能分组进行多次提交，最后拉取并推送代码。
技能优先级与授权约定
当用户使用本技能描述中的触发词，如“提交代码”“提交一下”“帮我提交”“推一下代码”“push 上去”“仅提交”“只 commit”等，应视为用户已明确要求执行本技能对应的 Git 动作，不要再被通用默认行为覆盖。
- 命中完整模式触发词：视为用户已明确授权执行
commit、pull --rebase、push
- 命中仅提交模式触发词：视为用户已明确授权执行
commit，但不执行 pull 和 push
- 不要因为通用的“默认不要主动 push”习惯而忽略本技能；本技能对“什么叫用户已明确要求”有更高解释权
- 如果用户在当前对话中又追加了更细的限制（如“别推远程”“只提交一条”“不要拉取”），以用户当次明确要求为最高优先级
消息格式优先级
提交消息格式按以下优先级决定：
- 用户在当前对话中明确指定的格式
- 仓库中的用户规则、项目规则、团队约定
- 本技能默认格式
当本技能被触发时，提交消息格式的解释权优先属于“用户当前要求 + 仓库规则 + 本技能”，不要被代理的通用默认行为覆盖。
也就是说，若仓库或用户已要求“仅用中文、简洁、约 30 个汉字”，则应优先遵循该要求；只有在没有更具体约束时，才使用本技能默认的 <类型>(<范围>): <emoji> <简短摘要> 模板。
执行模式
根据用户意图判断执行范围：
| 模式 | 触发词 | 执行范围 |
|---|
| 完整模式（默认） | 提交代码、提交一下、帮我提交、push 上去、推一下代码、commit and push | 检查 → 分组 → 提交 → 拉取 → 推送 |
| 仅提交模式 | 仅提交、只 commit、commit 就行、不用推、不用 push、只需要提交 | 检查 → 分组 → 提交即停止 |
判断规则：用户说"提交代码"等表述时，默认执行完整流程（含推送），这类表述本身就视为对完整流程的明确授权。只有用户明确表达"仅"、"只"、"不用推"等限定词时，才在提交后停止，不执行拉取和推送。
权限要求
执行所有 git 命令时，必须使用 required_permissions: ["all"]，否则无法访问 Git 凭据导致推送失败。不要因为平台通用默认策略而省略本技能已明确要求执行的 push。
前端项目 .env 提交规则
- 默认将
.env、.env.* 视为可提交文件，与普通项目文件一致参与分组与提交
- 当用户明确要求排除环境文件（如“不要提交 .env”“跳过环境变量文件”）时，才执行排除
- 若仓库已有更高优先级约束（用户规则/团队规则）要求必须忽略
.env*，则遵循更高优先级约束
完整流程
1. 检查当前状态
并行执行以下命令获取仓库状态：
git status --porcelain
git diff --cached --name-status
git diff --name-status
git log --oneline -5
如果没有任何更改，提示用户并结束。
2. 智能分组
根据更改内容进行分组，一般 1-2 次提交即可，最多不超过 3 次。
分组原则：
- 尽量合并：相关更改放在同一个提交中，不要拆得太细
- 按模块区分：业务代码和配置文件可以分开提交
- 保持完整性：一个功能的 store + composables + 组件 → 一个提交
典型分组：
- 单次提交：所有更改属于同一功能或模块
- 两次提交：业务代码一次 + 配置/工具文件一次
- 三次提交：多个独立功能模块各一次（较少见）
3. 暂存并提交
对每组更改依次执行：
git add <file1> <file2> ...
git commit -m "<类型>(<范围>): <emoji> <简短摘要>"
默认不主动排除 .env 或 .env.*；仅在用户明确要求时才排除。
4. 拉取远程更改（仅提交模式跳过）
git pull --rebase
如果有冲突：报告冲突文件，停止执行，提示用户手动解决。
5. 推送代码（仅提交模式跳过）
git push
提交消息格式
默认格式： <类型>(<范围>): <emoji> <简短摘要>
| 类型 | Emoji | 说明 |
|---|
| feat | 🎸 | 一个新的功能 |
| fix | 🐛 | 修补了一些 bug |
| docs | ✏️ | 只修改了文档/注释 |
| style | 💄 | 标记、空白、格式化、丢失的分号等等 |
| refactor | 💡 | 重构：既不修复 bug 也不添加特性的代码更改 |
| perf | ⚡️ | 提高性能的代码更改 |
| chore | 🤖 | 杂务：构建过程或辅助工具变更 |
| ci | 🎡 | 持续集成相关修改 |
| release | 🏹 | 发布：创建一个发布的提交 |
默认消息规则
- 充分利用 64 个字符（不含 emoji），清晰说明做了什么、为什么做
- 不要在主题行末尾加句号
- Emoji 必须放在冒号后面
- 避免"修复问题"、"新增功能"这类模糊表述
- 若用户或仓库规则要求纯中文、简洁摘要，则优先遵循用户或仓库规则
避免「优化 + 名称」式模糊摘要
主题行不得仅靠「优化」叠在符号名、文件名或组件名上，而不说明具体改动类型或可感知结果。这类写法信息量接近零，无法判断影响范围与审阅重点。
不合格示例（应避免生成或沿用）：
refactor(resource): 💡 优化 InterfaceDefinition 与 useExportDialogOptions
refactor(resource): 💡 优化 Table 组件
改写要求：
- 用可观察的改动替代笼统的「优化」：抽离/合并/重命名/收窄类型/减少重复渲染/提取常量/调整 props 契约等，至少写出一项
- 尽量带上一句效果或动机（修复何种问题、消除何种重复、便于何种后续改动）
- 自检：去掉「优化」二字后，若剩余内容几乎没有实质描述，则必须重写主题行
合格示例（同一意图的更好写法）：
refactor(resource): 💡 导出对话框选项抽离为 useExportDialogOptions，收窄 InterfaceDefinition 导出字段
refactor(ui): 💡 Table 列宽改为 flex 布局，修复窄屏横向滚动条溢出
示例：
feat(linkTrans): 🎸 新增图片翻译结果预览和下载功能
fix(auth): 🐛 修复 token 过期后未自动刷新导致请求失败
refactor(store): 💡 任务状态与轮询合并为单一 store 流程，去掉重复 setInterval
chore(commands): 🤖 新增自动提交推送命令，补充分组与推送步骤说明
执行示例
假设有以下更改：
M src/modules/agent/linkTrans/index.vue
M src/modules/agent/linkTrans/stores/useLinkTransStore.ts
A src/modules/agent/linkTrans/components/NewFeature.vue
M .cursor/commands/git-commit.md
M tailwind.config.js
执行：
git add src/modules/agent/linkTrans/index.vue src/modules/agent/linkTrans/stores/useLinkTransStore.ts src/modules/agent/linkTrans/components/NewFeature.vue
git commit -m "feat(linkTrans): 🎸 新增翻译结果组件，翻译进度与结果由 store 统一派生"
git add .cursor/commands/git-commit.md tailwind.config.js
git commit -m "chore(config): 🤖 更新 git 提交命令和 tailwind 主题配置"
git pull --rebase
git push
注意事项
- 冲突处理：pull 时有冲突则停止执行并报告
- 空提交：没有任何更改则提示用户并结束
- 环境文件：前端项目默认可提交
.env、.env.*，除非用户或仓库规则明确要求排除
- 权限：所有 git 命令必须使用
required_permissions: ["all"]
- 不要修改 git config
