dizzy-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dizzy Commit

This skill is a safety workflow, not permission to modify the repository.

这个技能是一个安全工作流，而不是修改仓库的许可。

Policy precedence

策略优先级

Read

references/policy-configuration.md

. Resolve rules in this order:

Platform and system safety constraints.
Repository policy and contribution instructions.
Explicit user instructions.
This skill's portable defaults.

阅读

references/policy-configuration.md

。按以下顺序解决规则：

平台和系统安全约束。
仓库策略和贡献说明。
明确的用户指令。
本技能的可移植默认值。

Conflict resolution

冲突解决

When the user's request conflicts with a safety or policy rule, the higher-precedence rule wins. Do not downgrade a safety boundary because the user asked for speed or convenience. If a request would violate a hard boundary, stop and explain what conflicts and what the safer path is.

Never invent branch names, scopes, authorship, remotes, commit formats, or required checks.

当用户请求与安全或策略规则冲突时，优先级更高的规则获胜。不要因为用户要求速度或便利而降低安全边界。如果请求会违反硬性边界，停下并解释冲突所在以及更安全的路径。

绝不虚构分支名称、范围、作者、远程仓库、提交格式或必需检查。

Safety boundary

安全边界

Inspection is safe by default. Mutation is not.

Without explicit authorization, do not:

stage or unstage files,
create or amend commits,
push or force-push,
restore or delete files,
clean untracked files,
rewrite history,
change Git configuration.

Treat pre-existing changes as user-owned unless provenance is clear.

检查默认是安全的。变更操作不是。

未经明确授权，不要：

暂存或取消暂存文件，
创建或修改提交，
推送或强制推送，
恢复或删除文件，
清理未跟踪文件，
重写历史，
更改Git配置。

将预先存在的更改视为用户所有，除非来源明确。

Step 0: Establish intent and mode

第0步：确定意图和模式

Determine whether the user wants inspection, preparation, commit creation, push, or the full sequence. If the request authorizes only one side effect, do not silently perform the next one.

Read

references/host-adapters.md

when the environment is not ordinary Git CLI usage.

确定用户想要的是检查、准备、创建提交、推送，还是完整流程。如果请求只授权一个副作用，不要静默地执行下一个。

当环境不是普通的Git CLI使用时，阅读

references/host-adapters.md

。

Step 1: Inspect before deciding

第1步：在决定之前检查

At minimum, inspect status and the relevant diff. Check branch/upstream information and repository policy when committing or pushing. Identify generated files, secrets, unrelated changes, merge conflicts, and staged-versus-unstaged differences.

Read

references/clean-tree-checklist.md

and

references/staging-and-gitignore.md

至少检查状态和相关的差异。在提交或推送时检查分支/上游信息和仓库策略。识别生成的文件、机密、无关更改、合并冲突，以及已暂存与未暂存的差异。

阅读

references/clean-tree-checklist.md

和

references/staging-and-gitignore.md

。

Step 2: Scope the change

第2步：限定更改范围

Separate task-related changes from pre-existing or unrelated work. Never stage "everything" merely because it is convenient. Prefer explicit paths and verify the staged diff before commit.

将任务相关更改与预先存在的或无关的工作分开。绝不要仅仅因为方便就暂存“所有内容”。优先使用显式路径，并在提交前验证暂存的差异。

Step 3: Determine the commit message

第3步：确定提交消息

Read

references/message-style.md

. Use repository conventions if present. Conventional Commits is a fallback, not a universal law. The subject should describe the resulting change, not the agent's process.

阅读

references/message-style.md

。如果存在仓库约定，则使用它。Conventional Commits是回退方案，不是普遍法则。主题应该描述结果性更改，而不是代理的过程。

Step 4: Verify

第4步：验证

Run the repository's documented checks when authorized and relevant. If checks are unavailable, say so. Never claim tests passed when only static inspection occurred.

Before a commit, verify the staged diff and intended paths. Before a push, verify the commit, remote, branch, and upstream relationship.

在授权且相关时运行仓库文档化的检查。如果检查不可用，请说明。绝不要声称测试通过，而实际上只进行了静态检查。

在提交之前，验证暂存差异和预期路径。在推送之前，验证提交、远程、分支和上游关系。

Step 5: Mutate only within the granted scope

第5步：仅在授予的范围内进行变更

After explicit authorization, stage exactly the intended paths, create the commit, and verify the result. Pushing requires explicit push authorization unless the user clearly requested a push.

在明确授权后，仅暂存预期路径，创建提交，并验证结果。推送需要明确的推送授权，除非用户清楚地要求推送。

Anti-patterns

反模式

```
git add .
```
without reviewing scope.
Cleaning a dirty tree to make a task easier.
Amending or force-pushing without explicit instruction.
Hiding unrelated changes in a commit.
Claiming hooks/tests passed without evidence.
Changing Git config to satisfy a local policy.
Treating a dirty working tree as an error that must be "fixed".
Using em dashes in commit messages.

不审查范围就执行
```
git add .
```
清理脏树以简化任务
未经明确指示就修改或强制推送
在提交中隐藏无关更改
声称钩子/测试通过但没有证据
更改Git配置以满足本地策略
将脏工作树视为必须“修复”的错误
在提交消息中使用em dash（长破折号）

Caveman mode

穴居人模式

If the user explicitly asks for a direct commit and the repository is straightforward, still perform the minimum safety checks. Direct intent is authorization to mutate, not authorization to skip review.

如果用户明确要求直接提交且仓库简单，仍然执行最低限度的安全检查。直接意图是授权变更，而不是跳过审查。

Bundled references

捆绑引用

Load the specific policy, staging, message, verification, and push references required by the task:

```
references/policy-configuration.md
```
: policy precedence order and what never to invent.
```
references/host-adapters.md
```
: when the environment is not ordinary Git CLI usage and how to adapt.
```
references/clean-tree-checklist.md
```
: what to inspect before deciding to commit.
```
references/staging-and-gitignore.md
```
: group by logical concern, never cite ignored files, never add new ignored files, verify gitignore status before staging.
```
references/message-style.md
```
: commit message format, subject rules, body rules, prohibited content, AI co-author trailer, and type reference.
```
references/commit-execution.md
```
: duplicate-commit check, subject/body structure, avoiding literal
```
\n
```
in shell, two
```
-m
```
flags versus file plus
```
-F
```
, and post-commit verification.
```
references/proactive-trigger.md
```
: when to check in without an explicit commit request and the check-in flow.
```
references/strict-mode.md
```
: extra constraints for strict mode, applied on top of default rules.
```
references/push-and-upstream.md
```
: push authorization, upstream verification, and when to update the branch.
```
references/examples.md
```
: worked good/bad commit message examples.
```
references/verification-and-failure.md
```
: shared verification and failure-handling principles.

加载任务所需的特定策略、暂存、消息、验证和推送引用：

```
references/policy-configuration.md
```
：策略优先级顺序以及哪些内容绝不能虚构。
```
references/host-adapters.md
```
：当环境不是普通Git CLI使用时的适应方法。
```
references/clean-tree-checklist.md
```
：在决定提交之前要检查的内容。
```
references/staging-and-gitignore.md
```
：按逻辑关注点分组，绝不引用忽略的文件，绝不添加新的忽略文件，在暂存前验证gitignore状态。
```
references/message-style.md
```
：提交消息格式、主题规则、正文规则、禁止内容、AI联合作者尾注和类型参考。
```
references/commit-execution.md
```
：重复提交检查、主题/正文结构、避免在shell中使用字面
```
\n
```
、两个
```
-m
```
标志与文件加
```
-F
```
，以及提交后验证。
```
references/proactive-trigger.md
```
：何时在没有明确提交请求的情况下签入，以及签入流程。
```
references/strict-mode.md
```
：严格模式的附加约束，在默认规则之上应用。
```
references/push-and-upstream.md
```
：推送授权、上游验证以及何时更新分支。
```
references/examples.md
```
：好坏提交消息示例。
```
references/verification-and-failure.md
```
：共享的验证和失败处理原则。