zui-commit

name	zui-commit
description	分析 ZUI 主仓库的提交范围、生成英文 commit message，或执行用户明确要求的 Git 提交。仅分析或生成 message 时保持只读。

ZUI 提交

操作边界

先判断用户意图，再执行对应模式：

• 只读模式：用户仅要求分析变更、规划提交或生成 commit message 时，只读取仓库状态并返回建议，不运行 git add、git commit 或其他写操作。
• 提交模式：仅在用户明确要求提交、保存或入库改动时，才暂存并提交请求范围内的变更。

始终遵守以下边界：

• 保留用户已有的暂存、未暂存和未跟踪改动，不修改或提交无关内容。
• 不擅自执行 --amend、--no-verify、push、force push、reset 或清理工作区。
• 遇到未解决冲突、正在进行但意图不明的 merge/rebase/cherry-pick，或无法可靠判断提交范围时，停止写操作并请求用户决定。

提交规范

• 首行格式：<type> <scope>: <description>
  • <type>：* = change、+ = addition、- = removal。按提交的主要语义判断，不按文件的 A/M/D 状态机械拆分；新增功能即使同时修改旧文件，仍可使用 +。
  • <scope>：lib/<name>/ 内的变更使用 <name>；仓库根、开发基础设施或不可拆分的跨库变更使用 proj。
  • <description>：使用简洁的英文祈使句，建议不超过 72 个字符且结尾不加句号。
• 提交信息全部使用英文，不使用 emoji。
• 如需详细说明，与首行空一行后用 Markdown 撰写，多条变更使用列表项。
• 不添加 Co-authored-by 等 Agent 相关信息。

示例：

* form-builder: add textarea option to form field panel
+ utilities: add new whiteboard extension
* proj: update pnpm-lock.yaml after dependency bump

与代码评审技能协作

候选范围、写操作授权、验证编排和最终提交结果始终由本技能负责。审查候选组时，完整读取 ZUI 代码评审，只复用其中与评审阶段有关的只读边界、评审方法、严重度和 findings 输出规则。

• 将当前候选提交组声明为显式评审范围，不让代码评审技能重新执行默认范围选择。
• 现有暂存快照只评审 cached 内容；尚未暂存的候选组只评审精确 diff、pathspec 或 hunk；用户明确给出的 revision/range 保留原有语义。
• 不混入其他工作区改动；候选组为空时直接报告无可提交内容，不回退评审未推送提交。
• 确认所有被当前变更新增引用的兄弟技能和 reference 已在基线中受跟踪，或被纳入同一原子候选组；否则引用断链本身就是 finding。
• 评审阶段保持只读。仅有提交授权时，只允许后续按已确认范围暂存和提交，不包含修复代码、刷新生成物或推送。提交模式下，若本任务已有仍适用的修复授权，且相应实施确认要求已满足，则在评审后完成范围内修复、重新评审和验证，再继续提交；不重复询问是否修复。
• 验证由本技能统一编排；同一候选快照已有的有效结果可以复用，快照变化后必须重新评审并补充受影响验证。

步骤

1. 收集上下文：先并行运行 git --no-optional-locks status --short --branch、git diff --cached --name-status、git diff --name-status、git ls-files --others --exclude-standard -z 和 git log --oneline -10，只收集分层状态、路径和历史，不读取全部无关变更内容。

2. 确定候选范围：

   • 用户明确点名的文件、hunk、暂存层级或其他提交范围优先。若非空暂存快照与该范围不一致，不得把范围外暂存内容一并提交，也不得自行改写暂存区；先说明差异并取得用户对暂存区处理方式的许可，除非当前请求已经明确授权相应的整体调整。
   • 用户未指定不同范围且暂存区已有变更时，将现有暂存快照视为用户主动点名的提交范围；忽略未暂存和未跟踪变更，除非用户明确要求纳入。
   • 对现有暂存快照的范围、逻辑归属或敏感性有任何不确定性时，停止写操作并询问用户，不自行改变暂存区或猜测意图。
   • 暂存区为空时，只选择用户点名或当前任务直接产生的变更，不默认暂存整个工作区。
   • 用户明确要求提交“全部当前改动”时，也先排除无关生成物以及 .env*、凭据、token、私钥、私有配置等敏感内容。
   • 候选范围确定后，才读取该范围的 git diff --cached --no-ext-diff --find-renames、git diff --no-ext-diff --find-renames 和候选未跟踪文件；pathspec 始终放在 -- 后。不要读取候选范围外的未提交变更内容；评审时仍可只读查看判断所需的基线源码、调用方、测试和引用目标。

3. 规划原子提交：先按逻辑目的分组，再决定 type 和 scope。

   • 现有暂存快照如无明显的范围、逻辑或敏感性问题，优先保持为一个提交；用户的主动暂存意图高于通常的按库拆分惯例。
   • 对尚未暂存、由本技能规划的范围，不同库通常分别提交；仓库级改动通常使用 proj。
   • 同一功能涉及新增、修改和删除文件时可以保持为一个提交。
   • 只有逻辑独立，或没有单一主要语义时，才继续拆分。
   • 已有暂存快照需要拆分时，先说明拆分方案并取得用户许可，再改变暂存区；不得破坏部分暂存内容。

4. 审查每组变更：

   • 按“与代码评审技能协作”审查当前候选快照。
   • 另外检查提交专属问题：console.log、console.debug、debugger、临时 alert 等调试残留，无关文件或生成物，source-of-truth 不一致，以及 .env*、凭据、token、私钥和私有配置等疑似敏感信息。

   有 confirmed finding 或疑似敏感信息时先按严重度和文件/行号报告。只读模式将 commit message 标记为“修复或明确接受后可用”；只有剩余变化仍构成独立完整提交时，才另外给出不含问题部分的分组建议。提交模式先核对本任务已有的修复授权；已有适用批准时按前述流程修复，没有修复授权或需要接受未解决问题时，暂停受影响的写操作并由用户决定；不确定事项单列为风险，不冒充 finding。修复或候选范围变化后，重新收集上下文、审查并验证。

5. 执行验证：

   • 始终对候选或暂存的 tracked diff 运行相应的 git diff --check；未跟踪文本文件使用 zui-review 的等价 whitespace 检查。
   • 选择覆盖候选风险的最小充分组合，不机械运行全部命令：
     • 仓库内 .agents/skills/*、skills/* 和 skills-exts/* 使用 skill-creator 的 quick_validate.py 并检查引用；另行解析 agents/openai.yaml，核对界面字段、$skill-name 默认提示及资源路径，因为 quick validator 不覆盖该文件。修改 的脚本或检查器时再运行 。