Commit Assistant
Creates repository-style commit messages and safely commits code changes.
The skill explicitly forbids unauthorized amend, force-push, push, skipped hooks, skipped signing, and reverting or discarding user changes, and tells the agent to ask about suspicious secrets or generated artifacts. These controls reduce external-impact and destructive risks. Deductions apply because secret inspection is underspecified, data flow, isolation, and rollback are not documented, and `git add -A` is prescribed for all-unstaged changes without a more granular confirmation boundary.
The workflow is internally coherent: discover commit style, inspect status, review the staged diff, commit, and verify the result, with feedback for a clean tree and hook changes or failures. Static files do not prove the commands run, and handling is thin for missing `user.name`, nonstandard repositories, command failures, or unusual paths, so the score is conservative and subject to the static ceiling.
Trigger phrases are clear, and the skill targets committing staged or unstaged changes with an explicit staging policy and message format. Deductions apply because it does not define non-Git or ambiguous-convention cases, Chinese-language commit conventions, cross-platform shell assumptions, or scenarios where automatic staging is unsuitable; mainland-China environment fit is not evidenced.
The document has clear progressive structure, guidelines, workflow steps, command examples, limitations, and failure notes. Repository materials establish MIT licensing, Microsoft attribution, and repository context. Deductions apply because the skill itself lacks a version, changelog, explicit maintenance owner, update path, installation/dependency notes, and FAQ, and its ongoing maintenance cannot be established from the supplied files alone.
The skill specifies a directly relevant output: a repository-style commit message and a commit followed by status and log confirmation, including subject length, body, and issue-reference guidance. Static review cannot verify actual commit completion or message quality, and the user may still need to resolve questions, hooks, or follow-up changes, so the score remains below the execution-dependent maximum.
The commands, safeguards, and expected workflow are auditable in the skill source, while the README, LICENSE, package metadata, and CI provide repository identity, licensing, and general testing or hook context. There is no dedicated test or third-party execution evidence covering this skill's key paths, so the score stays below the static maximum.
- When only unstaged changes exist, the skill directs `git add -A`, which may include files the user did not explicitly select; confirm the scope before execution.
- Commit, hook, and signing behavior depends on local Git configuration and environment, but recovery guidance for cross-platform or missing-configuration cases is not provided.
- No dedicated execution evidence verifies this skill's behavior; the assessment is based only on static source review.
What it does & when to use it
This Agent Skill helps commit Git changes when a user asks to commit, save, or check in code. It reviews recent repository commits and the user's own recent commits to identify the established commit-message style. It then checks repository status, preserves existing staging boundaries, or stages all changes when everything is unstaged. From the staged diff, it creates a subject of no more than 72 characters, commits it, and verifies the result.
It runs git log --oneline -20 and a user-filtered git log --oneline --author="$(git config user.name)" -10 to analyze commit conventions; runs git status --short to inspect the worktree; runs git add -A when changes are only unstaged; and runs git diff --cached --stat plus git diff --cached to read the commit candidate. It drafts a repository-style subject and, when the change is non-trivial, an optional body; runs git commit; then runs git status --short and git log --oneline -1 for confirmation. It also checks for obvious secrets or generated artifacts and asks the user when risk, staging scope, convention, or message content is unclear.
- A developer has completed code changes and wants a commit message aligned with the repository's recent history.
- A user has only unstaged changes and wants them all staged and committed in one workflow.
- A user has staged a specific set of changes and wants to commit without including other unstaged edits.
- A team follows a recognizable commit format and wants new commits to match it.
- A possible secret or generated artifact appears in the candidate diff and needs user confirmation before committing.
Pros & cons
- Uses both recent repository commits and the current user's recent commits when determining message style.
- Explicitly prevents unauthorized amend, force-push, push, reset, revert, and deletion of user changes.
- Does not skip pre-commit hooks or commit signing.
- Checks status and shows the latest commit after committing, while reporting hook failures or file rewrites.
- The skill file does not document a standalone installation process or a platform support matrix.
- It asks for obvious secret and generated-artifact checks but does not specify a dedicated secret scanner.
- It recommends a body only for non-trivial diffs and provides no more detailed commit-message template.
- The supplied source provides no test-suite or cross-platform validation evidence for this skill.
How to install
The repository bundles 61 separate skills; this profile covers only src/vs/sessions/skills/commit/SKILL.md. The README does not document a standalone installation procedure or a target client directory for this skill, so the exact installation method is undocumented. The repository source is licensed under the MIT license.
How to use
In an existing Git repository with local changes, send the Agent a request such as “commit changes”, “create a commit”, “save my work”, or “check in code”. If changes are already staged, the skill works only with those changes; if all changes are unstaged, it stages them with git add -A. If there are no changes, it reports that and stops. It asks the user when staging scope, commit convention, message content, or a potentially risky file is unclear.