smart-commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Smart Commit

智能提交

Trigger

触发条件

Use when saying "commit", "save changes", or ready to commit after making changes.

当用户说“commit”、“save changes”，或完成修改后准备提交时使用。

Workflow

工作流

Check current state and identify what to commit.
Run quality gates (lint, typecheck, tests on affected files).
Scan staged changes for issues.
Draft a conventional commit message from the diff.
Stage specific files, create the commit.
Prompt for learnings from this change.

检查当前状态并确定需要提交的内容。
运行质量门禁（lint、typecheck，以及对受影响文件执行测试）。
扫描已暂存的变更，找出潜在问题。
根据 diff 起草符合 Conventional Commits 规范的提交信息。
暂存指定文件并创建提交。
询问此次变更值得记录的经验。

Commands

命令

bash

git status
git diff --stat

npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10

git add <specific files>
git commit -m "<type>(<scope>): <summary>"

bash

git status
git diff --stat

npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10

git add <specific files>
git commit -m "<type>(<scope>): <summary>"

Code Review Scan

代码审查扫描

Before committing, check staged changes in production code (not test files) for:

```
console.log
```
/
```
debugger
```
statements (suppressed in test files — see Review Suppressions)
TODO/FIXME/HACK comments without ticket references (e.g.,
```
TODO(JIRA-123)
```
is fine)
Hardcoded secrets or API keys
Leftover test-only code

Flag any issues before proceeding.

提交前，检查 production code（而非测试文件）中的已暂存变更是否存在以下问题：

```
console.log
```
/
```
debugger
```
语句（测试文件中允许使用——参见“审查排除项”）
未关联工单编号的 TODO/FIXME/HACK 注释（例如，
```
TODO(JIRA-123)
```
符合要求）
硬编码的 secret 或 API key
遗留的仅供测试使用的代码

继续操作前，标记发现的任何问题。

Commit Message Format

提交信息格式

<type>(<scope>): <short summary>

<body - what changed and why>

Types: feat, fix, refactor, test, docs, chore, perf, ci, style

<type>(<scope>): <short summary>

<body - what changed and why>

类型： feat、fix、refactor、test、docs、chore、perf、ci、style

Guardrails

防护规则

Never skip quality gates unless user explicitly says to.
Stage specific files by name. Never
```
git add -A
```
or
```
git add .
```
.
Summary under 72 characters. Body explains why, not what.
No generic messages ("fix bug", "update code").
Reference issue numbers when applicable.

除非用户明确要求，否则绝不能跳过质量门禁。
按文件名暂存指定文件。绝不能使用
```
git add -A
```
或
```
git add .
```
。
摘要不超过 72 个字符。正文应解释原因，而不是具体改动。
禁止使用泛化的提交信息（如“fix bug”、“update code”）。
适用时引用 issue 编号。

Output

输出

Quality gate results (pass/fail)
Issues found in staged changes
Suggested commit message
Commit hash after committing
Prompt: any learnings to capture?

质量门禁结果（通过/失败）
在已暂存变更中发现的问题
建议的提交信息
提交后的 commit hash
询问：是否有需要记录的经验？

Review Suppressions

审查排除项

Do NOT flag these during the pre-commit scan. They add noise without catching real bugs:

Threshold, config value, or feature flag changes (limits, timeouts, retry counts)
Import reordering that does not change runtime behavior
Whitespace-only or formatting-only changes
Adding or removing
```
console.log
```
in test files
TODO/FIXME comments (tracked separately in issue trackers)
Variable or parameter renames that do not change behavior

在提交前扫描中，不要标记以下内容，否则只会增加噪声，无法发现真正的 bug：

阈值、配置值或 feature flag 的变更（限制值、超时时间、重试次数）
不改变运行时行为的 import 顺序调整
仅涉及空白字符或格式的变更
在测试文件中添加或删除
```
console.log
```
TODO/FIXME 注释（在 issue tracker 中单独跟踪）
不改变行为的变量或参数重命名