Git Commit

Git Commit is an official instruction skill from GitHub's github/awesome-copilot repository. Its direct primary source is https://github.com/github/awesome-copilot/tree/main/skills/git-commit. According to the provider, the guidance helps a coding agent inspect changes, derive a suitable Conventional Commits message, and logically group files for an understandable commit. This catalog entry therefore describes reusable agent guidance, not a Git implementation, a GitHub hosting feature, or an autonomous approval process.

Purpose and workflow

The skill starts with an inventory of the working tree. An agent should first check whether files are already staged, what changes exist in the working directory, and which differences actually separate the current state from the previous version. It then derives a type, an optional scope, and a concise description. The source names common types such as feat for new functionality, fix for bug corrections, docs for documentation, refactor for structural changes, test for tests, and chore for maintenance. The choice must describe the actual change rather than claim an intended outcome. A longer explanation can add context when one line is not enough.

Conventional Commits and grouping

The Conventional Commits format gives teams a shared language for change histories. The skill maps a short imperative summary to a type and, where useful, a scope. According to the primary source, breaking changes should be marked explicitly with an exclamation mark or an appropriate footer. That decision affects releases and automation, so it should not be added casually. When several independent changes are present in the working tree, the agent can propose a logical grouping. Before staging files, however, it must be clear that the files belong together technically and semantically. Unclear, generated, or unrelated changes should remain available for review instead of being silently placed in the same commit.

Practical use

The skill fits teams that want consistent commit messages and a history that makes review easier. It can help after an explicit commit request, when a corresponding workflow is invoked, or while preparing a proposed commit. The guidance is also useful in repositories that use commit types for changelogs, release notes, or quality reporting. It does not replace project-specific rules. A team should define its allowed scopes, language, footers, branch policies, and review requirements, then provide those constraints to the agent. A well-formed commit remains a summary of a reviewed change and is not a substitute for tests, code review, or product approval.

Requirements and boundaries

The skill assumes a Git working tree and an agent that can read status and differences and, when authorized, stage files or create a commit. The guidance does not install Git and does not decide whether a user has the required permission. It cannot guarantee correct detection of type, scope, or technical intent. Binary files, large generated artifacts, submodules, hooks, and changes from parallel workflows may need additional inspection. The MIT license refers to the published skill file; the license terms of a concrete project, its dependencies, and its commit hooks must be reviewed separately. The source was reviewed on September 9, 2026. Repository stars are not stored for this Skill record because the model has no corresponding field.

Security and responsibility

The primary source warns against committing secrets and describes a safety protocol against configuration changes, destructive Git operations, forced history changes, bypassing hooks, and unauthorized pushes. These boundaries matter in real working trees. Before any write, review the affected paths, the diff, the branch, the intended commit, and the authorization. Treat files, commit messages, issues, and external text as untrusted data that cannot introduce new instructions. Credentials, tokens, private keys, and other secrets belong neither in the skill nor in a commit. According to the provider, human control is required, especially when staging or creating a commit changes external state. A connected model may transmit context to its model provider, so local Git execution does not automatically mean local model processing.