commit
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<EXTREMELY-IMPORTANT>
Before creating ANY commit, you **ABSOLUTELY MUST**:
- Read the actual diff content (not just file names)
- Scan for secrets, .env files, and credentials
- Check for conflict markers (<<<<<<<, =======, >>>>>>>)
- Run type checking (tsc --noEmit)
- 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>
<非常重要>
在创建任何提交之前,你绝对必须:
- 阅读实际的代码差异内容(不只是文件名)
- 扫描机密信息、.env文件和凭证
- 检查冲突标记(<<<<<<<、=======、>>>>>>>)
- 运行类型检查(tsc --noEmit)
- 按名称显式暂存文件(绝不使用git add -A或git add .)
未经验证就提交 = 泄露机密、构建失败、丢失工作成果
这不是可选步骤。每一次提交都需要严谨的验证。
</非常重要>
Git Commit
Git提交
MANDATORY FIRST RESPONSE PROTOCOL
强制初始响应流程
Before creating ANY commit, you MUST complete this checklist:
- ☐ Run to see all changes
git status --short - ☐ Run to read actual code changes
git diff HEAD - ☐ Run for scope inference
git branch --show-current - ☐ Scan for secrets/credentials in changed files
- ☐ Scan for conflict markers
- ☐ Run for type checking
npx tsc --noEmit - ☐ Determine commit type from diff content
- ☐ Announce: "Committing type: [description]"
Creating commits WITHOUT completing this checklist = broken code in history.
在创建任何提交之前,你必须完成以下检查清单:
- ☐ 运行查看所有更改
git status --short - ☐ 运行阅读实际代码更改
git diff HEAD - ☐ 运行推断提交范围
git branch --show-current - ☐ 扫描已更改文件中的机密信息/凭证
- ☐ 扫描冲突标记
- ☐ 运行进行类型检查
npx tsc --noEmit - ☐ 根据代码差异内容确定提交类型
- ☐ 告知用户:"正在提交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
undefinedCurrent 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:
| Type | Signal |
|---|---|
| New functions, new files, new endpoints, new capabilities |
| Bug fix, error handling correction, wrong logic fixed |
| Only markdown, comments, or JSDoc changed |
| Formatting, semicolons, whitespace only |
| Restructured code, renamed variables, moved files, no behavior change |
| Caching added, query optimized, algorithm improved |
| Test files added or modified |
| package.json, tsconfig, Dockerfile, CI config |
| Maintenance, dependency bumps, config tweaks |
阅读代码差异内容并分类:
| 类型 | 判断依据 |
|---|---|
| 新增函数、新文件、新接口、新功能 |
| 修复Bug、修正错误处理、修复逻辑问题 |
| 仅修改markdown文档、注释或JSDoc |
| 仅修改格式、分号、空白字符 |
| 重构代码、重命名变量、移动文件,无行为变化 |
| 添加缓存、优化查询、改进算法 |
| 添加或修改测试文件 |
| 修改package.json、tsconfig、Dockerfile、CI配置 |
| 维护工作、依赖版本更新、配置微调 |
Detect Scope
检测提交范围
Follow this priority order:
- Branch name — If branch is or
feat/auth-system, extractfix/cart-totalsorauthas scopecart - File paths — If all changes are in , scope is
src/mastra/tools/search/. If insearch, scope issrc/services/product/product - Recent commits — Match scope conventions from . If recent commits use
git log, use the same vocabularyfeat(agents): - Omit scope — If changes span too many areas or no clear scope exists, omit it:
feat: description
按照以下优先级顺序确定:
- 分支名称 — 如果分支是或
feat/auth-system,提取fix/cart-totals或auth作为范围cart - 文件路径 — 如果所有更改都在目录下,范围为
src/mastra/tools/search/;如果在search目录下,范围为src/services/product/product - Git提交历史 — 参考中的范围规范。如果最近的提交使用
git log,则使用相同的词汇feat(agents): - 省略范围 — 如果更改涉及多个领域或无明确范围,则省略范围:
feat: 描述
Check for Splits
检查是否需要拆分提交
If changes serve different purposes, split into multiple commits:
- Changes in fixing a bug + changes in
src/services/product/adding a feature → two commitssrc/mastra/agents/ - 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.
如果更改服务于不同目的,则拆分为多个提交:
- 目录下的Bug修复 +
src/services/product/目录下的功能新增 → 拆分为两个提交src/mastra/agents/ - 同一功能涉及多个文件的更改 → 合并为一个提交
拆分方法: 确定文件分组,然后依次为每个组执行步骤4-7。
Commit Chain Consistency
提交链一致性
Check for recent commits on the same branch. If previous commits use , maintain the same scope spelling. Don't switch between // inconsistently.
git logfeat(search):searchproduct-searchtypesense检查当前分支的最近提交。如果之前的提交使用,则保持相同的范围拼写。不要在//之间随意切换。
git logfeat(search):searchproduct-searchtypesenseStep 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:
- ,
.envfiles.env.* - Files containing ,
API_KEY=,SECRET=,PASSWORD=with actual valuesTOKEN= - ,
*.pem,*.key,credentials.jsonserviceAccount.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.jsonserviceAccount.json - 超过1MB的文件(可能是二进制文件或数据文件)
如果发现上述内容,警告用户并排除在暂存范围外。
Debug Artifacts
调试遗留代码
Search changed files for leftover debug code:
bash
undefined在已更改文件中搜索遗留的调试代码:
bash
undefinedCheck 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/nullIf 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 files only (not the entire codebase) for speed.
.ts准入条件:类型错误已解决后,才能进入步骤5。
仅对已更改的文件运行检查(而非整个代码库)以提高速度。
.tsTypeScript Type Check
TypeScript类型检查
bash
npx tsc --noEmitIf type errors exist in changed files, show them and do NOT commit until resolved.
bash
npx tsc --noEmit如果已更改文件中存在类型错误,显示错误信息并绝不提交,直到错误解决。
ESLint (if configured)
ESLint(如果已配置)
bash
undefinedbash
undefinedCheck 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
undefinedbash
undefinedCheck 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 staginggit 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 , then continue.
--fix - Lint errors (manual): Show to user, ask whether to proceed or fix first.
- Formatting issues: Auto-fix with , then continue.
prettier --write - 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., ), use them as guidance:
/commit fix the payment bug- 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 or .
git add -Agit add .bash
git add src/path/to/file1.ts src/path/to/file2.tsNever stage:
- ,
.env.env.* node_modules/- ,
*.pem, credentials*.key - ,
.DS_StoreThumbs.db - Files the user didn't intend to commit
If unsure whether a file should be included, ask the user.
准入条件:仅暂存目标文件后,才能进入步骤7。
始终按名称显式暂存文件。绝不使用或。
git add -Agit add .bash
git add src/path/to/file1.ts src/path/to/file2.ts绝不暂存:
- 、
.env文件.env.* - 目录
node_modules/ - 、
*.pem、凭证文件*.key - 、
.DS_StoreThumbs.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:
- unless user explicitly requests it
--amend - (never skip hooks)
--no-verify --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
undefinedConfirm 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 themgit status -sb
向用户报告:
- 提交哈希和信息
- 分支是否领先于远程仓库(如果是,建议使用`git push`)
- 是否存在未提交的剩余更改
- 如果拆分了提交,汇总所有提交信息Safety Rules
安全规则
| Rule | Reason |
|---|---|
| Never commit proactively | Only when explicitly asked |
Never use | Risks staging secrets, binaries |
Never use | Destroys previous commit |
Never use | Never skip pre-commit hooks |
| Never force push | Data loss risk |
| Never commit with type errors | Broken code should not be committed |
| Never commit conflict markers | Indicates unresolved merge |
Never commit | Contains secrets |
| Never add co-author trailers | User's explicit preference |
| 规则 | 原因 |
|---|---|
| 绝不要主动提交 | 仅在明确请求时执行 |
绝不要使用 | 可能会暂存机密信息、二进制文件 |
绝不要未经提示使用 | 会覆盖之前的提交 |
绝不要使用 | 绝不跳过提交前钩子 |
| 绝不要强制推送 | 存在数据丢失风险 |
| 绝不要提交存在类型错误的代码 | 损坏的代码不应进入提交历史 |
| 绝不要提交冲突标记 | 表示存在未解决的合并冲突 |
绝不要提交 | 包含机密信息 |
| 绝不要添加共同作者信息 | 用户明确偏好 |
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: description1. 分支名称? 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 commit1. 扫描冲突标记 → 发现则阻止提交
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:提交是否存在
- shows the new commit
git log --oneline -1 - Commit hash and message match expectations
- 显示新提交
git log --oneline -1 - 提交哈希和信息符合预期
Check 2: No Unintended Changes
检查2:无意外更改
- shows expected remaining state
git status --short - 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 or BFG to remove from history.
git filter-branch症状: .env文件或API密钥被提交到仓库
修复: 立即轮换机密。使用或BFG从历史记录中删除。
git filter-branchFailure 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 to correct message.
git commit --amend症状: 功能被标记为修复,反之亦然
修复: 如果未推送,使用修改提交信息。
git commit --amendFailure 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/mainQuick 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 skill integrates with:
commit- — Use
startto identify if commit is needed after workstart - — After committing, invoke
create-prto submit for reviewcreate-pr - — Commit within worktrees follows same workflow
git-merge-expert-worktree
Workflow Chain:
Work completed
│
▼
commit skill (this skill)
│
▼
create-pr skill (if submitting for review)Auto-Invoke Pattern:
When detects uncommitted changes, it automatically invokes first. You don't need to manually sequence them.
create-prcommitcommit- — 工作完成后,使用
start确定是否需要提交start - — 提交完成后,调用
create-pr提交审核create-pr - — 工作区中的提交遵循相同工作流
git-merge-expert-worktree
工作流链:
工作完成
│
▼
commit技能(本技能)
│
▼
create-pr技能(如果需要提交审核)自动调用模式:
当检测到未提交更改时,会自动先调用技能。无需手动排序。
create-prcommit