$ ~/registry/skill/microsoft-src-vs-sessions-skills-commit

SKILL

commit

Name: commit
Author: microsoft

Create commits for code changes with AI-generated messages matching repo style.

Stars

★ 187,441

Source

GitHub

Updated

2026-07-11

// securityCaution

Prompt only, no code
Open source

Summary

This skill is an open-source, prompt-only commit helper with no declared secrets or remote endpoints, so overall risk is low. Its instructions explicitly involve reading git history/diffs and executing local git commit commands, so the main concerns are local data access and local command execution scope.

CredentialsLow risk

The materials state that no keys or environment variables are required, and the README does not request tokens, accounts, or credentials; no explicit credential collection or misuse path is evident.

Network egressLow risk

No remote endpoints are declared, and the content is limited to local git status, diff, and commit operations; the materials do not describe sending code, diffs, or user data to external services.

Code executionCaution

The README explicitly instructs execution of local git commands such as git log, git status, git add -A, git diff, and git commit. This kind of local command execution is a normal tool capability, but it can change repository state and trigger local hooks, so users should be aware.

Data accessCaution

This skill needs to read commit history, author information, working tree status, and staged/modified diffs, and it may run git add -A when only unstaged changes exist. The access and write scope is broadly consistent with the stated purpose of committing changes, but it does touch repository contents, so users should watch for sensitive files or accidentally included changes.

Supply chainLow risk

The system marks it as prompt-only and open-source, with the source pointing to microsoft/vscode on GitHub, making the code auditable and providing a strong positive trust signal. Although the provided star/maintenance metadata is incomplete, there are no clear red flags of closed-source distribution, abandonment, or suspicious packaging in the materials.

Recommendations

Review git status and diffs before committing to ensure no sensitive files, secrets, or generated artifacts are accidentally included.
If the repository uses pre-commit or commit-msg hooks, understand their behavior first to avoid unexpected changes during commit.
Perform a final review of the generated commit message to ensure it does not leak internal details and matches project conventions.

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 "commit" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/vscode/main/src/vs/sessions/skills/commit/SKILL.md
2. Save it as ~/.claude/skills/commit/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Commit current changes

Prompt

Please commit the current changes in this repository and make the commit message match the project's existing commit style.

Expected

A new commit is created with a message consistent with the repository's existing history.

Save unstaged work

Prompt

Help me handle these unstaged changes and commit them together with a concise message that follows the repository conventions.

Expected

The relevant changes are included in a commit with a clear, convention-aligned message.

Create a commit after finishing a feature

Prompt

I've finished this feature. Create a commit and automatically write the commit message based on the changes, keeping it consistent with past commits.

Expected

A commit is created that summarizes the feature changes while matching the repository's tone and format.

// docs

Commit Changes

Help the user commit code changes with a well-crafted commit message derived from the diff, following the conventions already established in the repository.

Guidelines

Never amend existing commits without asking.
Never force-push or push without explicit user approval.
Never skip pre-commit hooks (do not use --no-verify).
Never skip signing commits (do not use --no-gpg-sign).
Never revert, reset, or discard user changes unless the user explicitly asked for that.
Check for obvious secrets or generated artifacts that should not be committed. If something looks risky - ask the user.
When in doubt about staging, convention, or message content — ask the user.

Workflow

1. Discover the repository's commit convention

Run the following to sample recent commits and the user's own commits:

# Recent repo commits (for overall style)
git log --oneline -20

# User's recent commits (for personal style)
git log --oneline --author="$(git config user.name)" -10

Analyse the output to determine the commit message convention used in the repository (e.g. Conventional Commits, Gitmoji, ticket-prefixed, free-form). All generated messages must follow the detected convention.

2. Check repository status

git status --short

If there are no changes (working tree clean, nothing staged), inform the user and stop.
If there are staged changes, proceed with those and do not stage any unstaged changes.
If there are only unstaged changes, stage everything (git add -A), and proceed with those.

3. Generate the commit message

Obtain the full diff of what will be committed:

git diff --cached --stat
git diff --cached

Using the diff and the commit convention detected in step 1, draft a commit message with:

A subject line (≤ 72 characters) that summarises the change, following the repository's convention.
An optional body that explains why the change was made, only when the diff is non-trivial.
Reference issue/ticket numbers when they appear in branch names or related context.
Focus on the intent of the change, not a file-by-file inventory.

4. Commit

Construct the git commit command with the generated message.

Execute the commit:

git commit -m "<subject>" -m "<body>"

5. Confirm

After the commit:

Run git status --short to confirm the commit completed.
Run git log --oneline -1 to show the new commit.
If pre-commit hooks changed files or blocked the commit, summarize exactly what happened.
If hooks rewrote files after the commit attempt, do not amend automatically. Tell the user what changed and ask whether they want you to stage and commit those follow-up edits.