$ ~/registry/skill/microsoft-github-plugins-devsquad-skills-git-commit

SKILL

git-commit

Name: git-commit
Author: microsoft

基于代码差异生成规范化 Git 提交信息，并支持按逻辑分组提交

星标

★ 36

来源

GitHub

更新于

2026-07-05

// 安全评估需留意

仅提示词，不执行代码
开源可审计

总评

该技能材料显示其主要是基于 Git diff 生成规范化提交信息的提示型/开源技能，不需要密钥，也未声明任何远程连接，整体风险较低。需注意其围绕提交流程会读取本地仓库状态与差异，若实际实现包含 git add/commit 等本地操作，则属于常规本地数据访问与命令执行留意项。

凭证密钥低风险

材料明确注明无需密钥或环境变量，README 仅提醒避免提交 .env、私钥、token 等敏感文件，未见要求收集、存储或外发凭证的事实。

网络外发低风险

未声明任何远程端点，功能描述集中于本地分析 git diff 与生成提交信息；文中提到 GitHub Issues/Azure DevOps 仅作为工单引用语义，未见实际联网或数据外发说明。

代码执行需留意

README 展示了 git diff、git status、git add 等命令作为工作流步骤，说明该技能至少意图指导或可能触发本机 Git 命令；这属于此类开发工具的常规本地命令执行能力，材料中未见超出声明用途的系统权限红旗。

数据访问需留意

为分析和分组提交，技能会访问当前仓库的状态、差异、已暂存/未暂存文件列表，并可能涉及 .memory/git-config.md、.gitignore 等本地文件；这些访问与其声明功能直接相关，未见明显过度授权。

来源供应链需留意

来源为 GitHub 且标注开源，可一定程度审计，属于降低风险因素；但仓库 star 为 0、许可证未声明、维护状态未知，供应链可信度尚可但偏弱，建议在使用前核查实际代码与最近更新。

安全建议

在启用前查看仓库实际实现，确认其是否仅生成提交信息，还是会自动执行 git add/commit。
仅在受信任仓库中使用，并在提交前人工复核 diff 与提交信息，避免误提交敏感文件。
若技能可执行命令，优先以最小权限和沙箱/隔离开发环境运行。
核查仓库许可证、最近提交记录与依赖清单，再决定是否纳入团队工作流。

审计模型: gpt-5.4 · 2026-06-17

// 安装

复制安装指令，让 AI 自动完成配置 · 推荐新手

请帮我安装 askskill 上的 "git-commit" 技能：
1. 下载 https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/git-commit/SKILL.md
2. 保存为 ~/.claude/skills/git-commit/SKILL.md
3. 装好后重载技能，告诉我可以用了

// 下载

下载 SKILL.md机读安装清单 ↗

// 用法示例

为当前改动生成提交

输入

请分析当前 git diff，按照 Conventional Commits 规范生成提交信息并直接提交；如果包含不同类型改动，请按逻辑分组提交。

预期产出

生成一个或多个符合 Conventional Commits 的提交，并按改动类型合理拆分。

仅生成提交说明

输入

根据当前代码差异，给我一个 Conventional Commits 风格的提交信息，包含 type、scope 和简洁说明，先不要执行提交。

预期产出

输出一条规范的提交信息建议，便于手动确认后使用。

关联工作项提交

输入

请分析当前改动并创建规范提交，关联 GitHub Issue #128；如果改动涉及修复和文档更新，请拆成两个提交。

预期产出

生成带工作项引用的规范提交，并将修复与文档改动分别提交。

// 文档

Git Commit — Conventional Commits for SDD

Format

<type>[optional scope]: <description>

[optional body]

[optional footer]

References: Conventional Commits and How to Write a Git Commit Message.

Commit Types

Type	Usage
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation-only change
`style`	Formatting, semicolons, whitespace (no logic change)
`refactor`	Refactoring without behavior change
`perf`	Performance improvement
`test`	Adding or fixing tests
`build`	Build system or external dependencies
`ci`	CI/CD configuration
`chore`	General maintenance (scripts, configs)
`revert`	Revert a previous commit

Mapping to SDD Artifacts

SDD Artifact	Likely type
`docs/features/**/spec.md`	`docs`
`docs/architecture/decisions/*.md` (ADR)	`docs`
`tasks.md`, work items	`docs` or `chore`
Implementation code	`feat`, `fix`, `refactor`, `perf`
Tests	`test`
Agents, skills, instructions (`.github/`)	`chore` or `ci`

Breaking Changes

# ! marker after type/scope
feat!: remove deprecated endpoint

# Or BREAKING CHANGE footer
feat(api): allow extensible configuration

BREAKING CHANGE: behavior of the `extends` key changed

Workflow

1. Analyze Diff

# If there are staged files, use staged diff
git diff --staged --stat
git diff --staged

# If nothing is staged, use working tree
git diff --stat
git diff

# Check overall status
git status --porcelain

Determine from the diff:

Type: What kind of change is this? (see table above)
Scope: Which module/area was affected? (e.g., auth, api, docs, spec)
Description: One-line summary of what changed

2. Group and Stage (if needed)

If the diff contains logically distinct changes, group them into separate commits:

# Group by logical area
git add src/auth/*.ts          # commit 1: feat(auth)
git add tests/auth/*.test.ts   # commit 2: test(auth)
git add docs/features/login/   # commit 3: docs(login)

Principle: one commit = one coherent logical change.

If all changes are part of the same logical unit, stage everything:

git add -A

3. Pre-Commit Checks

Before committing, verify:

# Does .gitignore exist?
test -f .gitignore && echo "OK" || echo "⚠ .gitignore missing"

# No secrets being committed?
git diff --staged --name-only | grep -iE '\.(env|pem|key|credentials|secret)' && echo "⚠ POSSIBLE SECRET" || echo "OK"

Never commit: .env, private keys, tokens, credentials, credentials.json.

3b. Integration Branch Guard

Before committing, check if the current branch is the integration branch:

CURRENT_BRANCH=$(git branch --show-current)

Resolve the integration branch in this order:

Integration Branch from .memory/git-config.md (if it exists)
Repository default branch via git symbolic-ref refs/remotes/origin/HEAD
Fallback: match against main, master, or develop

If the current branch matches the integration branch:

You are about to commit directly to `[branch]`. Direct commits to the integration branch bypass code review and are difficult to revert safely.

[B] Create a feature branch first (recommended)
[C] Continue on [branch] (I understand the risks)

If the user chooses [B]:

Current state	Recovery action
Changes are staged but not committed	Run `git switch -c <feature-branch>` (preserves working tree and index)
Changes are unstaged	Run `git switch -c <feature-branch>` (preserves working tree)

After switching, continue the commit flow on the new branch.

If the user chooses [C], proceed with the commit. Log the override in the reasoning log (if active).

Never commit to the integration branch without explicit user confirmation.

…

查看完整文档 ↗