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

SKILL

git-commit

Name: git-commit
Author: microsoft

Generate standardized Git commits from diffs with logical grouping support.

Stars

★ 36

Source

GitHub

Updated

2026-07-05

// securityCaution

Prompt only, no code
Open source

Summary

The material describes a mostly prompt-oriented, open-source skill for generating standardized commit messages from Git diffs, with no required secrets and no declared remote endpoints, so overall risk is low. Caution is still warranted because its workflow reads local repository status and diffs, and if the implementation performs git add/commit actions, that would be standard local data access and command execution behavior.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required. The README only warns against committing .env files, private keys, and tokens, with no evidence that the skill collects, stores, or exfiltrates credentials.

Network egressLow risk

No remote endpoints are declared. The described functionality focuses on locally analyzing git diffs and generating commit messages; mentions of GitHub Issues/Azure DevOps appear to be reference semantics only, with no stated network access or data exfiltration.

Code executionCaution

The README shows commands such as git diff, git status, and git add as part of its workflow, indicating that the skill at least intends to guide or potentially invoke local Git commands. This is standard local command execution for a developer tool, and no red flags suggest permissions beyond its stated purpose.

Data accessCaution

To analyze and group commits, the skill accesses the current repository’s status, diffs, and lists of staged/unstaged files, and may involve local files such as .memory/git-config.md and .gitignore. These accesses are directly related to the stated function, with no clear sign of excessive privilege.

Supply chainCaution

The source is on GitHub and marked open-source, which is a positive, auditable factor that lowers risk. However, the repository has 0 stars, no declared license, and unknown maintenance status, so supply-chain trust is only moderate and should be verified by reviewing the actual code and recent activity before use.

Recommendations

Review the actual repository implementation first to confirm whether it only generates commit messages or also performs git add/commit automatically.
Use it only in trusted repositories, and manually review the diff and commit message before committing to avoid accidentally including sensitive files.
If the skill can execute commands, run it with least privilege and preferably in a sandboxed or isolated development environment.
Check the repository license, recent commit history, and dependency list before adopting it into a team workflow.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "git-commit" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/git-commit/SKILL.md
2. Save it as ~/.claude/skills/git-commit/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Create a commit for current changes

Prompt

Analyze the current git diff, generate a Conventional Commits message, and commit the changes directly; if there are different types of changes, split them into logical commits.

Expected

One or more commits following Conventional Commits, sensibly grouped by change type.

Generate commit message only

Prompt

Based on the current code diff, give me a Conventional Commits style commit message with type, scope, and a concise description, but do not create the commit yet.

Expected

A well-formed commit message suggestion for manual review and use.

Commit with work item reference

Prompt

Analyze the current changes and create standardized commits linked to GitHub Issue #128; if the changes include both a fix and documentation updates, split them into two commits.

Expected

Standardized commits with a work item reference, separating the fix and documentation changes.

// docs

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.

…

View full docs ↗