SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscodeguard-git-commit

codeguard-git-commit

Coding & development

View repository

Updated 10-15 21:47

About this skill

Commit log conventions (integration of three mainstream styles)

Capability Boundaries

✅ Strengths

  1. Team wiki conventions implemented as executable gates (regex/commands)
  2. Full coverage of mainstream styles, AI drafting is evidence-based
  3. Clear integration path with pre-commit / CI

⚠️ Prerequisites

  1. git; some tools need to be prepared according to installation instructions (commitlint / pre-commit framework)

❌ Out of Scope

  1. Code content review (lint-level matters belong to the corresponding language skill)
  2. Branch naming and merge direction → codeguard-git-branch

Basis: PartMe.AI Commit log conventions (Angular regex) + mainstream industry practice. For an in-depth comparison see references/commit-style-comparison.md。

1. First identify the project's existing style

git log --oneline -20 Look at team habits: most commits look like feat(x): y use Conventional; with ✨/🐛 emoji use Gitmoji; first line around 50 characters, body after a blank line uses Udacity. If it cannot be identified, follow Conventional (designated by the team wiki).

2. Conventional Commits (team-designated, de facto standard)

Format regex (gate)

^(feat|fix|docs|style|refactor|test|chore|ci)((.+))?: .{1,100}

Supporting validation script:linters/git/commit-msg(compatible with half-width/full-width colons, optional space after the colon, Gitmoji prefix stripping).

Three elements

Element Description
type fix / feat / test / style / docs / refactor / chore / ci (+ commonly used in the industry perf, revert)
scope Scope of impact: module, library, method (can be omitted)
subject Brief description ≤60 characters; it is recommended to note the associated Bug ID

Full type reference (Conventional Commits 1.0.0)

type Meaning Version semantics
feat New feature MINOR +1
fix Bug fix PATCH +1
perf Performance optimization PATCH +1
refactor Refactor (no behavior change) —
style Formatting/comments (no logic change) —
test Tests —
docs Documentation —
build Build system/dependencies —
ci CI configuration —
chore Chores —
revert Revert —

（feat/fix append ! or the body contains BREAKING CHANGE: to indicate a breaking change → MAJOR +1)

Examples

fix(首页模块)：修复弹窗 JS Bug
feat(美团对接)：新增门店 OAuth 授权链接生成
refactor(token)!: 双轨刷新合并为单一入口（升级需重配 cron）
docs(readme)：补充三端安装说明

3. Gitmoji (emoji-prefix style)

In the form :emoji: subject or directly unicode emoji. Common mappings:

emoji Meaning Corresponding conventional
✨ :sparkles: New feature feat
🐛 :bug: Bug fix fix
📝 :memo: Documentation docs
🎨 :art: Formatting/structure style/refactor
⚡ :zap: Performance perf
♻️ :recycle: Refactor refactor
✅ :white_check_mark: Tests test
🔧 :wrench: Configuration/chores chore
👷 :construction_worker: CI ci
🔥 :fire: Delete code/files —

codeguard rule: Gitmoji can be used as a prefix (the script will automatically strip it and then validate according to Conventional), e.g. ✨ feat(美团对接)：新增授权链接生成——emoji + type written together, machine-readable + intuitive for humans.

4. Udacity style (long-description type)

首行：变更摘要（≤50 字符，祈使句）

正文：解释 what 与 why（而非 how），每行 ≤72 字符。
      可分段说明动机、方案对比、副作用。

Suitable for: complex refactors, architectural changes, and other commits that need to explain decisions to future readers. Not mandatory for the team's everyday iterations.

V. Workflow (Standard Order for AI-Written Submissions)

  1. git diff --cached Review the actual changes
  2. According to git log --oneline -20 identify the team style
  3. Draft the message (type + scope + subject)
  4. Pass linters/git/commit-msg the gate
  5. Commit

VI. Tooling

  • Gate script:linters/git/commit-msg(pre-commit template has been preset with stages: [commit-msg]）
  • commitlint (Node projects): 
    npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
  • Manually enable hook:cp linters/git/commit-msg .git/hooks/commit-msg && chmod +x .git/hooks/commit-msg

VI. Rules for AI-Written Commits

  1. First git diff --cached reviewthe actual changes, do not fabricate from conversation memory
  2. Choose type according to the substance of the change; split mixed changes into separate commits or take the dominant type
  3. scope should be consistent with the project's existing commit style (git log --oneline -20 for reference)
  4. subject should clearly state "what was done"; vague words such as update / fix are prohibited
  5. Committer and author email must use a verified email
  6. When uncertain, ask the user;must notuse --no-verify to bypass the gate

Out of Scope (When Not to Use)

  • If only designing a branch model or merge strategy is required, hand over to the codeguard-git-branch skill.
  • No staged diff but asked to generate and commit directly based on the conversation.
  • Need to amend, rebase, or rewrite pushed history, but the impact scope has not been confirmed.

Data and Security

By default, only the staged diff and local commit metadata are read; source code and credentials are not collected, uploaded, sent, or stored. Commit messages must not contain tokens, passwords, customer personal data, or undisclosed vulnerability details.

Evidence-Based Workflow

Step 1: Check the staged scope

Run git diff --cached --stat and git diff --cached, confirm there are no credentials, generated noise, or unrelated changes.

Step 2: Identify the repository style

Read recent commits, commitlint/hook configuration, and CONTRIBUTING; do not impose external styles on an existing project.

Step 3: Classify the changes

Choose type/scope based on the actual diff; when mixed unrelated changes are present, recommend splitting into separate commits.

Step 4: Draft the message

Write a concise subject; for complex changes, add what/why, risks, and breaking change.

Step 5: Run the gate

Validate with the repository's existing commit-msg/commitlint. If it fails, fix the message; do not use --no-verify。

Gotchas

  1. unstaged changes do not belong to the current commit: they should not be written into subject/body.
  2. Pure formatting is not equal to refactor: follow the project's semantics for style and refactor .
  3. breaking change cannot be hidden: use ! or BREAKING CHANGE: and explain the migration.
  4. Machine-generated files can obscure the main change: scope should describe the logical module it belongs to.
  5. Gitmoji support must be based on repository history: do not add it arbitrarily based on personal preference.
  6. Verified email and signing are independent gates: a compliant message does not mean the identity or GPG/SSH signature is compliant.

Load Resources on Demand

  • When comparing styles, read references/commit-style-comparison.md。
  • When deciding or handing over, read references/rules/decision-contract.md and references/operations/evidence-playbook.md。
  • Only open examples/ example that matches the current task.