commit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<EXTREMELY-IMPORTANT> Before creating ANY commit, you **ABSOLUTELY MUST**:
  1. Read the actual diff content (not just file names)
  2. Scan for secrets, .env files, and credentials
  3. Check for conflict markers (<<<<<<<, =======, >>>>>>>)
  4. Run type checking (tsc --noEmit)
  5. Stage files explicitly by name (never git add -A or git add .)
Committing without verification = leaked secrets, broken builds, lost work
This is not optional. Every commit requires disciplined verification. </EXTREMELY-IMPORTANT>
<非常重要> 在创建任何提交之前,你绝对必须
  1. 阅读实际的代码差异内容(不只是文件名)
  2. 扫描机密信息、.env文件和凭证
  3. 检查冲突标记(<<<<<<<、=======、>>>>>>>)
  4. 运行类型检查(tsc --noEmit)
  5. 按名称显式暂存文件(绝不使用git add -A或git add .)
未经验证就提交 = 泄露机密、构建失败、丢失工作成果
这不是可选步骤。每一次提交都需要严谨的验证。 </非常重要>

Git Commit

Git提交

MANDATORY FIRST RESPONSE PROTOCOL

强制初始响应流程

Before creating ANY commit, you MUST complete this checklist:
  1. ☐ Run
    git status --short
    to see all changes
  2. ☐ Run
    git diff HEAD
    to read actual code changes
  3. ☐ Run
    git branch --show-current
    for scope inference
  4. ☐ Scan for secrets/credentials in changed files
  5. ☐ Scan for conflict markers
  6. ☐ Run
    npx tsc --noEmit
    for type checking
  7. ☐ Determine commit type from diff content
  8. ☐ Announce: "Committing type: [description]"
Creating commits WITHOUT completing this checklist = broken code in history.
在创建任何提交之前,你必须完成以下检查清单:
  1. ☐ 运行
    git status --short
    查看所有更改
  2. ☐ 运行
    git diff HEAD
    阅读实际代码更改
  3. ☐ 运行
    git branch --show-current
    推断提交范围
  4. ☐ 扫描已更改文件中的机密信息/凭证
  5. ☐ 扫描冲突标记
  6. ☐ 运行
    npx tsc --noEmit
    进行类型检查
  7. ☐ 根据代码差异内容确定提交类型
  8. ☐ 告知用户:"正在提交type: [描述]"
未完成此检查清单就创建提交 = 代码历史中混入损坏代码。

Overview

概述

Analyze all uncommitted changes, run quality checks, draft a Conventional Commits message with intelligent scope detection, stage files explicitly, and commit. No co-author trailers.
分析所有未提交的更改,运行质量检查,生成带有智能范围检测的Conventional Commits格式提交信息,显式暂存文件并完成提交。不添加共同作者信息。

When to Use

使用场景

  • User says "commit", "commit this", "make a commit", "/commit"
  • User asks to commit after completing work
  • $ARGUMENTS provided as commit guidance (e.g.,
    /commit fix the auth bug
    )
Never commit proactively. Only when explicitly requested.
  • 用户说"commit"、"commit this"、"make a commit"或使用指令
    /commit
  • 用户完成工作后要求提交
  • 用户提供了提交指导参数(例如:
    /commit fix the auth bug
绝不要主动提交。仅在明确请求时执行。

Step 1: Gather Context

步骤1:收集上下文

Gate: Full diff read and understood before proceeding to Step 2.
Run these commands to understand the full picture:
bash
undefined
准入条件:完全阅读并理解代码差异后,才能进入步骤2。
运行以下命令以全面了解当前状态:
bash
undefined

Current state (never use -uall flag)

当前状态(绝不使用-uall参数)

git status --short
git status --short

Full diff content — read the actual code changes, not just file names

完整代码差异内容 — 阅读实际代码更改,不只是文件名

git diff HEAD
git diff HEAD

Branch name — used for scope inference

分支名称 — 用于推断提交范围

git branch --show-current
git branch --show-current

Recent commits on this branch — for convention and scope consistency

当前分支的最近提交 — 用于匹配提交规范和范围

git log --oneline -15
git log --oneline -15

Check if branch is ahead/behind remote

检查分支是否领先/落后于远程仓库

git status -sb

**Read the actual diff output.** `--stat` only shows file names. You need the full diff to understand what changed (new functions vs bug fixes vs refactors).
git status -sb

**务必阅读实际的差异输出。**`--stat`仅显示文件名,你需要完整的差异内容来了解更改类型(新增功能、修复Bug、重构等)。

Step 2: Analyze Changes

步骤2:分析更改

Gate: Type and scope determined before proceeding to Step 3.
准入条件:确定提交类型和范围后,才能进入步骤3。

Determine Commit Type

确定提交类型

Read the diff content and classify:
TypeSignal
feat
New functions, new files, new endpoints, new capabilities
fix
Bug fix, error handling correction, wrong logic fixed
docs
Only markdown, comments, or JSDoc changed
style
Formatting, semicolons, whitespace only
refactor
Restructured code, renamed variables, moved files, no behavior change
perf
Caching added, query optimized, algorithm improved
test
Test files added or modified
build
package.json, tsconfig, Dockerfile, CI config
chore
Maintenance, dependency bumps, config tweaks
阅读代码差异内容并分类:
类型判断依据
feat
新增函数、新文件、新接口、新功能
fix
修复Bug、修正错误处理、修复逻辑问题
docs
仅修改markdown文档、注释或JSDoc
style
仅修改格式、分号、空白字符
refactor
重构代码、重命名变量、移动文件,无行为变化
perf
添加缓存、优化查询、改进算法
test
添加或修改测试文件
build
修改package.json、tsconfig、Dockerfile、CI配置
chore
维护工作、依赖版本更新、配置微调

Detect Scope

检测提交范围

Follow this priority order:
  1. Branch name — If branch is
    feat/auth-system
    or
    fix/cart-totals
    , extract
    auth
    or
    cart
    as scope
  2. File paths — If all changes are in
    src/mastra/tools/search/
    , scope is
    search
    . If in
    src/services/product/
    , scope is
    product
  3. Recent commits — Match scope conventions from
    git log
    . If recent commits use
    feat(agents):
    , use the same vocabulary
  4. Omit scope — If changes span too many areas or no clear scope exists, omit it:
    feat: description
按照以下优先级顺序确定:
  1. 分支名称 — 如果分支是
    feat/auth-system
    fix/cart-totals
    ,提取
    auth
    cart
    作为范围
  2. 文件路径 — 如果所有更改都在
    src/mastra/tools/search/
    目录下,范围为
    search
    ;如果在
    src/services/product/
    目录下,范围为
    product
  3. Git提交历史 — 参考
    git log
    中的范围规范。如果最近的提交使用
    feat(agents):
    ,则使用相同的词汇
  4. 省略范围 — 如果更改涉及多个领域或无明确范围,则省略范围:
    feat: 描述

Check for Splits

检查是否需要拆分提交

If changes serve different purposes, split into multiple commits:
  • Changes in
    src/services/product/
    fixing a bug + changes in
    src/mastra/agents/
    adding a feature → two commits
  • Changes all related to the same feature across multiple files → one commit
To split: identify the file groups, then execute Step 4-7 for each group sequentially.
如果更改服务于不同目的,则拆分为多个提交:
  • src/services/product/
    目录下的Bug修复 +
    src/mastra/agents/
    目录下的功能新增 → 拆分为两个提交
  • 同一功能涉及多个文件的更改 → 合并为一个提交
拆分方法: 确定文件分组,然后依次为每个组执行步骤4-7。

Commit Chain Consistency

提交链一致性

Check
git log
for recent commits on the same branch. If previous commits use
feat(search):
, maintain the same scope spelling. Don't switch between
search
/
product-search
/
typesense
inconsistently.
检查当前分支的
git log
最近提交。如果之前的提交使用
feat(search):
,则保持相同的范围拼写。不要在
search
/
product-search
/
typesense
之间随意切换。

Step 3: Pre-Commit Safety Scan

步骤3:提交前安全扫描

Gate: No secrets or conflict markers before proceeding to Step 4.
Before staging, scan changed files for problems.
准入条件:未发现机密信息或冲突标记后,才能进入步骤4。
在暂存文件前,扫描已更改文件中的问题。

Secrets and Sensitive Files

机密信息和敏感文件

Block these from being committed:
  • .env
    ,
    .env.*
    files
  • Files containing
    API_KEY=
    ,
    SECRET=
    ,
    PASSWORD=
    ,
    TOKEN=
    with actual values
  • *.pem
    ,
    *.key
    ,
    credentials.json
    ,
    serviceAccount.json
  • Files over 1MB (likely binary or data)
If found, warn the user and exclude from staging.
禁止提交以下内容:
  • .env
    .env.*
    文件
  • 包含
    API_KEY=
    SECRET=
    PASSWORD=
    TOKEN=
    及实际值的文件
  • *.pem
    *.key
    credentials.json
    serviceAccount.json
  • 超过1MB的文件(可能是二进制文件或数据文件)
如果发现上述内容,警告用户并排除在暂存范围外。

Debug Artifacts

调试遗留代码

Search changed files for leftover debug code:
bash
undefined
在已更改文件中搜索遗留的调试代码:
bash
undefined

Check changed files for debug statements

检查已更改文件中的调试语句

git diff HEAD --name-only | xargs grep -n 'console.log|debugger|TODO.*REMOVE|FIXME.*REMOVE' 2>/dev/null

If found, warn the user. Suggest removing before commit. Do not block — the user decides.
git diff HEAD --name-only | xargs grep -n 'console.log|debugger|TODO.*REMOVE|FIXME.*REMOVE' 2>/dev/null

如果发现,警告用户。建议在提交前移除。不要阻止提交 — 由用户决定。

Conflict Markers

冲突标记

bash
git diff HEAD --name-only | xargs grep -n '<<<<<<<\|=======\|>>>>>>>' 2>/dev/null
If found, do NOT commit. These must be resolved first.
bash
git diff HEAD --name-only | xargs grep -n '<<<<<<<\|=======\|>>>>>>>' 2>/dev/null
如果发现,绝不提交。必须先解决冲突。

Step 4: Run Quality Checks

步骤4:运行质量检查

Gate: Type errors resolved before proceeding to Step 5.
Run on changed
.ts
files only (not the entire codebase) for speed.
准入条件:类型错误已解决后,才能进入步骤5。
仅对已更改的
.ts
文件运行检查(而非整个代码库)以提高速度。

TypeScript Type Check

TypeScript类型检查

bash
npx tsc --noEmit
If type errors exist in changed files, show them and do NOT commit until resolved.
bash
npx tsc --noEmit
如果已更改文件中存在类型错误,显示错误信息并绝不提交,直到错误解决。

ESLint (if configured)

ESLint(如果已配置)

bash
undefined
bash
undefined

Check if ESLint config exists

检查是否存在ESLint配置

ls .eslintrc* eslint.config.* 2>/dev/null
ls .eslintrc* eslint.config.* 2>/dev/null

If config exists, lint changed files only

如果存在配置,仅对已更改文件执行lint检查

git diff HEAD --name-only --diff-filter=d -- '*.ts' | xargs npx eslint

If no ESLint config exists, skip with a note: "ESLint skipped — no config found."
If lint errors found, show them. Auto-fixable errors: offer `npx eslint --fix <files>`.
git diff HEAD --name-only --diff-filter=d -- '*.ts' | xargs npx eslint

如果不存在ESLint配置,跳过并说明:"ESLint已跳过 — 未找到配置文件。"
如果发现lint错误,显示错误信息。对于可自动修复的错误:提供`npx eslint --fix <files>`指令。

Prettier (always runs — works without config)

Prettier(始终运行 — 无需配置即可工作)

bash
undefined
bash
undefined

Check formatting on changed files

检查已更改文件的格式

git diff HEAD --name-only --diff-filter=d -- '.ts' '.json' '*.md' | xargs npx prettier --check

If formatting issues found:
1. Offer to auto-fix: `npx prettier --write <files>`
2. After fixing, the files will show as modified — they'll be included in staging
git diff HEAD --name-only --diff-filter=d -- '.ts' '.json' '*.md' | xargs npx prettier --check

如果发现格式问题:
1. 提供自动修复选项:`npx prettier --write <files>`
2. 修复后,文件会显示为已修改 — 这些文件将被包含在暂存范围中

If Checks Fail

检查失败处理

  • Type errors: Must fix. Do NOT commit.
  • Lint errors (auto-fixable): Fix with
    --fix
    , then continue.
  • Lint errors (manual): Show to user, ask whether to proceed or fix first.
  • Formatting issues: Auto-fix with
    prettier --write
    , then continue.
  • After any auto-fixes: Re-check to confirm clean.
  • 类型错误: 必须修复。绝不提交。
  • 可自动修复的lint错误: 使用
    --fix
    修复,然后继续。
  • 手动修复的lint错误: 显示给用户,询问是继续提交还是先修复。
  • 格式问题: 使用
    prettier --write
    自动修复,然后继续。
  • 任何自动修复后: 重新检查以确保无问题。

Step 5: Draft Commit Message

步骤5:生成提交信息

Gate: Message follows conventions before proceeding to Step 6.
准入条件:提交信息符合规范后,才能进入步骤6。

Format

格式

<type>(<scope>): <description>

[body — when 5+ files changed or multiple logical areas]
<类型>(<范围>): <描述>

[正文 — 当更改涉及5个以上文件或多个逻辑领域时添加]

Rules

规则

  • Imperative mood: "add feature" not "added feature"
  • Subject line: Under 72 characters, no period
  • Breaking changes: Add an exclamation mark after scope, e.g.
    feat(api)!: remove legacy endpoint
  • 祈使语气: 使用"add feature"而非"added feature"
  • 主题行: 不超过72个字符,结尾无句号
  • 破坏性更改: 在范围后添加感叹号,例如
    feat(api)!: remove legacy endpoint

Body Generation

正文生成

Add a body when:
  • 5+ files changed
  • Changes span multiple logical areas
  • The "why" isn't obvious from the subject
Body format — bullet points, each starting with imperative verb:
feat(search): add vector similarity scoring

- Add cosine similarity function to search service
- Update product schema with embedding field
- Add migration for new vector column
- Update search tool to use new scoring
在以下情况添加正文:
  • 更改涉及5个以上文件
  • 更改跨越多个逻辑领域
  • 从主题行无法明确了解更改的"原因"
正文格式 — 项目符号列表,每个项目以祈使动词开头:
feat(search): 添加向量相似度评分

- 为搜索服务添加余弦相似度函数
- 更新产品 schema 以包含嵌入字段
- 为新向量列添加迁移脚本
- 更新搜索工具以使用新的评分机制

$ARGUMENTS

$ARGUMENTS参数

If the user provided arguments (e.g.,
/commit fix the payment bug
), use them as guidance:
  • If it's a clear commit message, use it directly (respecting format rules)
  • If it's guidance ("fix the payment bug"), use it to inform type and description
如果用户提供了参数(例如:
/commit fix the payment bug
),将其作为指导:
  • 如果是明确的提交信息,直接使用(需符合格式规则)
  • 如果是指导内容("fix the payment bug"),使用它来确定提交类型和描述

Step 6: Stage Files

步骤6:暂存文件

Gate: Only intended files staged before proceeding to Step 7.
Always stage files explicitly by name. Never use
git add -A
or
git add .
.
bash
git add src/path/to/file1.ts src/path/to/file2.ts
Never stage:
  • .env
    ,
    .env.*
  • node_modules/
  • *.pem
    ,
    *.key
    , credentials
  • .DS_Store
    ,
    Thumbs.db
  • Files the user didn't intend to commit
If unsure whether a file should be included, ask the user.
准入条件:仅暂存目标文件后,才能进入步骤7。
始终按名称显式暂存文件。绝不使用
git add -A
git add .
bash
git add src/path/to/file1.ts src/path/to/file2.ts
绝不暂存:
  • .env
    .env.*
    文件
  • node_modules/
    目录
  • *.pem
    *.key
    、凭证文件
  • .DS_Store
    Thumbs.db
  • 用户无意提交的文件
如果不确定是否应包含某个文件,请询问用户。

Step 7: Create Commit

步骤7:创建提交

Gate: Commit created successfully before proceeding to Step 8.
Use heredoc for proper message formatting:
bash
git commit -m "$(cat <<'EOF'
type(scope): description

Optional body with bullet points
EOF
)"
No co-author trailers. The commit appears as solely the user's work.
Never:
  • --amend
    unless user explicitly requests it
  • --no-verify
    (never skip hooks)
  • --allow-empty
准入条件:提交创建成功后,才能进入步骤8。
使用heredoc确保提交信息格式正确:
bash
git commit -m "$(cat <<'EOF'
type(scope): description

Optional body with bullet points
EOF
)"
不添加共同作者信息。 提交将仅显示为用户的工作成果。
绝不:
  • 除非用户明确请求,否则不使用
    --amend
  • 不使用
    --no-verify
    (绝不跳过提交前钩子)
  • 不使用
    --allow-empty

Step 8: Verify and Report

步骤8:验证并报告

Gate: Commit verified in log before proceeding to Step 9.
After committing:
bash
undefined
准入条件:提交在历史记录中存在后,才能进入步骤9。
提交完成后:
bash
undefined

Confirm commit was created

确认提交已创建

git log --oneline -1
git log --oneline -1

Check remaining state

检查剩余状态

git status --short
git status --short

Check if ahead of remote

检查是否领先于远程仓库

git status -sb

Report to the user:
- The commit hash and message
- Whether the branch is ahead of remote (suggest `git push` if so)
- Whether there are remaining uncommitted changes
- If split commits were made, summarize all of them
git status -sb

向用户报告:
- 提交哈希和信息
- 分支是否领先于远程仓库(如果是,建议使用`git push`)
- 是否存在未提交的剩余更改
- 如果拆分了提交,汇总所有提交信息

Safety Rules

安全规则

RuleReason
Never commit proactivelyOnly when explicitly asked
Never use
git add -A
or
git add .
Risks staging secrets, binaries
Never use
--amend
unprompted
Destroys previous commit
Never use
--no-verify
Never skip pre-commit hooks
Never force pushData loss risk
Never commit with type errorsBroken code should not be committed
Never commit conflict markersIndicates unresolved merge
Never commit
.env
files
Contains secrets
Never add co-author trailersUser's explicit preference
规则原因
绝不要主动提交仅在明确请求时执行
绝不要使用
git add -A
git add .
可能会暂存机密信息、二进制文件
绝不要未经提示使用
--amend
会覆盖之前的提交
绝不要使用
--no-verify
绝不跳过提交前钩子
绝不要强制推送存在数据丢失风险
绝不要提交存在类型错误的代码损坏的代码不应进入提交历史
绝不要提交冲突标记表示存在未解决的合并冲突
绝不要提交
.env
文件
包含机密信息
绝不要添加共同作者信息用户明确偏好

Quick Reference: Scope Detection

快速参考:提交范围检测

1. Branch name?  feat/cart-totals → scope: cart
2. File paths?   src/mastra/tools/search/* → scope: search
3. Git log?      Recent commits use feat(agents): → scope: agents
4. None clear?   Omit scope: feat: description
1. 分支名称?  feat/cart-totals → 范围: cart
2. 文件路径?   src/mastra/tools/search/* → 范围: search
3. Git提交历史?      最近的提交使用feat(agents): → 范围: agents
4. 无明确范围?   省略范围: feat: 描述

Quick Reference: Quality Check Order

快速参考:质量检查顺序

1. Scan for conflict markers     → BLOCK if found
2. Scan for secrets/sensitive    → BLOCK those files
3. Scan for debug artifacts      → WARN (user decides)
4. Run tsc --noEmit              → BLOCK if type errors
5. Run eslint (if config exists) → FIX or WARN
6. Run prettier --check          → AUTO-FIX
7. All clear → proceed to stage and commit
1. 扫描冲突标记     → 发现则阻止提交
2. 扫描机密信息/敏感内容    → 阻止这些文件提交
3. 扫描调试遗留代码      → 警告用户(由用户决定)
4. 运行tsc --noEmit              → 存在类型错误则阻止提交
5. 运行eslint(如果已配置) → 修复或警告
6. 运行prettier --check          → 自动修复
7. 全部通过 → 进入暂存和提交步骤

Step 9: Verification (MANDATORY)

步骤9:验证(强制)

After committing, verify complete workflow:
提交完成后,验证整个工作流:

Check 1: Commit Exists

检查1:提交是否存在

  • git log --oneline -1
    shows the new commit
  • Commit hash and message match expectations
  • git log --oneline -1
    显示新提交
  • 提交哈希和信息符合预期

Check 2: No Unintended Changes

检查2:无意外更改

  • git status --short
    shows expected remaining state
  • No secrets or sensitive files were staged
  • git status --short
    显示预期的剩余状态
  • 未暂存机密信息或敏感文件

Check 3: Message Quality

检查3:提交信息质量

  • Type is correct (feat/fix/refactor/etc.)
  • Scope matches affected area
  • Description is imperative mood, under 72 chars
  • 类型正确(feat/fix/refactor等)
  • 范围与受影响区域匹配
  • 描述为祈使语气,不超过72个字符

Check 4: Branch State

检查4:分支状态

  • Branch is ahead of remote (if pushing needed)
  • No accidental commits to wrong branch
  • 分支是否领先于远程仓库(如果需要推送)
  • 未意外提交到错误分支

Check 5: Clean Working State

检查5:工作区状态干净

  • All intended changes are committed
  • Remaining uncommitted files are expected
Gate: Do NOT mark commit complete until all 5 checks pass.

  • 所有预期更改已提交
  • 剩余未提交文件符合预期
准入条件:所有5项检查通过后,才能标记提交完成。

Quality Checklist (Must Score 8/10)

质量检查清单(必须达到8/10分)

Score yourself honestly before marking commit complete:
在标记提交完成前,诚实地为自己评分:

Context Gathering (0-2 points)

上下文收集(0-2分)

  • 0 points: Committed without reading diff
  • 1 point: Read file names only (--stat)
  • 2 points: Read full diff content, understood changes
  • 0分: 未阅读代码差异就提交
  • 1分: 仅阅读文件名(--stat)
  • 2分: 阅读完整代码差异内容,理解更改

Safety Scanning (0-2 points)

安全扫描(0-2分)

  • 0 points: Skipped security scan
  • 1 point: Partial scan (checked some patterns)
  • 2 points: Full scan: secrets, conflict markers, debug artifacts
  • 0分: 跳过安全扫描
  • 1分: 部分扫描(仅检查部分模式)
  • 2分: 完整扫描:机密信息、冲突标记、调试遗留代码

Quality Checks (0-2 points)

质量检查(0-2分)

  • 0 points: Skipped type checking / linting
  • 1 point: Ran checks but proceeded with errors
  • 2 points: All checks pass (or user explicitly approved proceeding)
  • 0分: 跳过类型检查/ lint检查
  • 1分: 运行了检查但存在错误仍继续提交
  • 2分: 所有检查通过(或用户明确批准继续)

Staging Discipline (0-2 points)

暂存规范性(0-2分)

  • 0 points: Used git add -A or git add .
  • 1 point: Staged files but didn't verify list
  • 2 points: Staged files explicitly by name, verified before commit
  • 0分: 使用git add -A或git add .
  • 1分: 暂存了文件但未验证列表
  • 2分: 按名称显式暂存文件,提交前验证

Message Quality (0-2 points)

提交信息质量(0-2分)

  • 0 points: Generic message ("fix bug", "update")
  • 1 point: Has type but vague description
  • 2 points: Proper conventional commit with type, scope, imperative description
Minimum passing score: 8/10

  • 0分: 通用信息("fix bug"、"update")
  • 1分: 包含类型但描述模糊
  • 2分: 符合Conventional Commits规范,包含类型、范围和祈使语气描述
最低及格分数:8/10

Common Rationalizations (All Wrong)

常见错误借口(全错)

These are excuses. Don't fall for them:
  • "It's just a small change" → STILL read the full diff
  • "I know what files changed" → STILL run git status and diff
  • "The type check is slow" → STILL run tsc --noEmit before committing
  • "git add . is faster" → STILL stage files explicitly by name
  • ".env is in .gitignore" → STILL verify it wasn't staged
  • "I'll fix the commit message later" → Get it right NOW, amending is risky
  • "There are no secrets" → STILL scan for API_KEY, SECRET, TOKEN patterns
  • "Pre-commit hooks will catch it" → YOU are responsible, not just hooks

这些都是借口,不要轻信:
  • "只是一个小更改" → 仍需阅读完整代码差异
  • "我知道哪些文件被更改了" → 仍需运行git status和diff
  • "类型检查太慢了" → 仍需在提交前运行tsc --noEmit
  • "git add .更快" → 仍需按名称显式暂存文件
  • ".env已在.gitignore中" → 仍需验证它未被暂存
  • "我稍后再修改提交信息" → 现在就改好,修改提交信息有风险
  • "没有机密信息" → 仍需扫描API_KEY、SECRET、TOKEN等模式
  • "提交前钩子会检测到" → 你要负责,而不只是依赖钩子

Failure Modes

失败场景

Failure Mode 1: Leaked Secrets

失败场景1:泄露机密

Symptom: .env file or API key committed to repository Fix: Immediately rotate the secret. Use
git filter-branch
or BFG to remove from history.
症状: .env文件或API密钥被提交到仓库 修复: 立即轮换机密。使用
git filter-branch
或BFG从历史记录中删除。

Failure Mode 2: Conflict Markers Committed

失败场景2:提交冲突标记

Symptom: Code has
<<<<<<<
,
=======
,
>>>>>>>
in committed files Fix: Resolve conflicts properly, amend the commit with --amend.
症状: 提交的代码中包含
<<<<<<<
=======
>>>>>>>
修复: 正确解决冲突,使用--amend修改提交。

Failure Mode 3: Type Errors in Committed Code

失败场景3:提交存在类型错误的代码

Symptom: Build fails after commit, tsc shows errors Fix: Fix type errors, create new commit (or --amend if not pushed).
症状: 提交后构建失败,tsc显示错误 修复: 修复类型错误,创建新提交(如果未推送,可使用--amend)。

Failure Mode 4: Wrong Commit Type

失败场景4:提交类型错误

Symptom: Feature labeled as fix, or vice versa Fix: If not pushed, use
git commit --amend
to correct message.
症状: 功能被标记为修复,反之亦然 修复: 如果未推送,使用
git commit --amend
修改提交信息。

Failure Mode 5: Committed to Wrong Branch

失败场景5:提交到错误分支

Symptom: Changes on main/master instead of feature branch Fix: Create new branch from HEAD, reset main:
git branch feature && git reset --hard origin/main

症状: 更改提交到main/master分支而非功能分支 修复: 从当前HEAD创建新分支,重置main分支:
git branch feature && git reset --hard origin/main

Quick Workflow Summary

工作流快速总结

STEP 1: GATHER CONTEXT
├── git status --short
├── git diff HEAD (read actual changes!)
├── git branch --show-current
└── Gate: Full diff understood

STEP 2: ANALYZE CHANGES
├── Determine type (feat/fix/refactor/etc.)
├── Detect scope from branch/files/log
├── Check if split needed
└── Gate: Type and scope determined

STEP 3: PRE-COMMIT SAFETY SCAN
├── Scan for secrets (.env, API_KEY, etc.)
├── Scan for conflict markers
├── Scan for debug artifacts
└── Gate: No blocking issues

STEP 4: RUN QUALITY CHECKS
├── tsc --noEmit (type check)
├── eslint (if configured)
├── prettier --check
└── Gate: Checks pass or user approves

STEP 5: DRAFT COMMIT MESSAGE
├── type(scope): description
├── Imperative mood, <72 chars
├── Body if 5+ files
└── Gate: Message ready

STEP 6: STAGE FILES
├── git add <files explicitly>
├── Never git add -A or git add .
├── Verify staged files
└── Gate: Correct files staged

STEP 7: CREATE COMMIT
├── git commit with heredoc
├── No --amend unless requested
├── No --no-verify ever
└── Gate: Commit created

STEP 8: VERIFY AND REPORT
├── git log --oneline -1
├── git status --short
└── Gate: Commit verified

STEP 9: VERIFICATION
├── Check 1: Commit exists
├── Check 2: No unintended changes
├── Check 3: Message quality
├── Check 4: Branch state
├── Check 5: Clean working state
└── Gate: All 5 checks pass

步骤1:收集上下文
├── git status --short
├── git diff HEAD(务必阅读实际更改!)
├── git branch --show-current
└── 准入条件:完全理解代码差异

步骤2:分析更改
├── 确定类型(feat/fix/refactor等)
├── 从分支/文件/提交历史检测范围
├── 检查是否需要拆分提交
└── 准入条件:确定类型和范围

步骤3:提交前安全扫描
├── 扫描机密信息(.env、API_KEY等)
├── 扫描冲突标记
├── 扫描调试遗留代码
└── 准入条件:无阻止问题

步骤4:运行质量检查
├── tsc --noEmit(类型检查)
├── eslint(如果已配置)
├── prettier --check
└── 准入条件:检查通过或用户批准

步骤5:生成提交信息
├── type(scope): description
├── 祈使语气,<72字符
├── 更改涉及5个以上文件时添加正文
└── 准入条件:提交信息就绪

步骤6:暂存文件
├── git add <显式指定文件>
├── 绝不使用git add -A或git add .
├── 验证暂存文件
└── 准入条件:暂存正确文件

步骤7:创建提交
├── 使用heredoc执行git commit
├── 除非请求,否则不使用--amend
├── 绝不使用--no-verify
└── 准入条件:提交已创建

步骤8:验证并报告
├── git log --oneline -1
├── git status --short
└── 准入条件:提交已验证

步骤9:验证(强制)
├── 检查1:提交存在
├── 检查2:无意外更改
├── 检查3:提交信息质量
├── 检查4:分支状态
├── 检查5:工作区状态干净
└── 准入条件:所有5项检查通过

Completion Announcement

完成公告

When commit is complete, announce:
Commit complete.

**Quality Score: X/10**
- Context Gathering: X/2
- Safety Scanning: X/2
- Quality Checks: X/2
- Staging Discipline: X/2
- Message Quality: X/2

**Commit:**
- Hash: [short hash]
- Message: [full message]
- Files: [count] files changed

**Verification:**
- Commit exists: ✅
- No secrets staged: ✅
- Type errors: None
- Branch: [branch name] (ahead by [N] commits)

**Next steps:**
[Push, create PR, or continue work]

提交完成后,向用户公告:
提交完成。

**质量评分:X/10**
- 上下文收集:X/2
- 安全扫描:X/2
- 质量检查:X/2
- 暂存规范性:X/2
- 提交信息质量:X/2

**提交信息:**
- 哈希:[短哈希]
- 信息:[完整提交信息]
- 文件:[数量]个文件被更改

**验证结果:**
- 提交存在:✅
- 无机密信息被暂存:✅
- 类型错误:无
- 分支:[分支名称](领先远程仓库[N]个提交)

**下一步建议:**
[推送提交、创建PR或继续工作]

Integration with Other Skills

与其他技能的集成

The
commit
skill integrates with:
  • start
    — Use
    start
    to identify if commit is needed after work
  • create-pr
    — After committing, invoke
    create-pr
    to submit for review
  • git-merge-expert-worktree
    — Commit within worktrees follows same workflow
Workflow Chain:
Work completed
commit skill (this skill)
create-pr skill (if submitting for review)
Auto-Invoke Pattern:
When
create-pr
detects uncommitted changes, it automatically invokes
commit
first. You don't need to manually sequence them.
commit
技能可与以下技能集成:
  • start
    — 工作完成后,使用
    start
    确定是否需要提交
  • create-pr
    — 提交完成后,调用
    create-pr
    提交审核
  • git-merge-expert-worktree
    — 工作区中的提交遵循相同工作流
工作流链:
工作完成
commit技能(本技能)
create-pr技能(如果需要提交审核)
自动调用模式:
create-pr
检测到未提交更改时,会自动先调用
commit
技能。无需手动排序。