Review and commit a small change with an agent skill

Use an agent skill to organize a small local change, while keeping the decision to commit grounded in a diff you can inspect. The Git Commits with Conventional Messages resource packages a community contribution from GitHub Awesome Copilot under MIT. It is an instruction file, not a Git executable, a secret scanner or a certification from GitHub.

Choose the boundary before the message

Write down the intended change and the files it should affect. A useful boundary might be “handle blank input in the parser”; the documentation change explaining it can be a separate commit. A message that sounds plausible is not evidence that the staged files belong together.

This workflow needs Git, a Bash-compatible shell and an agent allowed to inspect your local repository. The upstream instructions target GitHub Copilot. The package is free to download and redistribute with its notice; an agent client or model plan can have separate costs. You can inspect a diff and make a local Git commit without a GitHub account or a remote repository.

Before installation, read the original source, prerequisites and full license on the resource page. Compare the ZIP checksum with the published SHA-256. The installation and verification guide explains the local installer.

Review the index and the working tree separately

Git keeps the staged snapshot in its index. Changes in the working tree can differ from the staged copy of the same file. Start with these read-only commands in the repository you intend to work on:

git status --porcelain
git diff
git diff --staged

The unstaged diff and staged diff answer different questions. Inspect both before choosing the files for a commit. An empty unstaged diff does not mean that the index is empty, and an existing staged change does not automatically belong to your task.

Choose explicit paths when adding a small change:

git add -- src/parser.py
git diff --staged --name-only
git diff --staged

Replace the example path with the intended file. Do not copy it into an unrelated repository. A file can contain both intended and unrelated changes; reviewing a path list alone will miss that. Use interactive staging only when you understand its prompts, and inspect the resulting staged patch again.

Make the message describe the actual change

A Conventional Commit has a type, an optional scope and a description, such as “fix(parser): handle blank input”. Use a body when the reason or constraint needs explanation. Check your repository’s own conventions before applying a generic format.

For a multiline message, a quoted heredoc keeps shell-like text literal:

git commit -m "$(cat <<'EOF'
fix(parser): handle blank input

Explain the reason for the changed behavior.

Refs #123
EOF
)"

Replace the example description and issue reference with truthful details. Do not add an issue number, test result or breaking-change declaration that does not apply. An agent can draft a message, but review its claims against the staged diff.

Let repository checks run

A commit can execute repository hooks. Inspect hooks and repository rules before granting an agent permission to commit. If a hook rejects the change, read the failure, correct the relevant input and retry normally. Do not silently bypass the hook, disable checks or amend an unrelated commit to make the command succeed.

An ignored file is not automatically safe. Ignore rules do not remove a secret already tracked by Git, and inspecting a diff is not a comprehensive secret scan. Stop if the staged patch contains credentials, private keys or data you are not authorized to publish.

What our fixture checks established

Our scoped record uses synthetic files in a temporary Linux container with no network, production mounts or model client. It checks package hashes, explicit file staging, separation of staged and unstaged changes, literal multiline text, normal commit history, a rejecting pre-commit hook and a corrected retry. It also checks that an ignored fixture environment file never enters the history.

These observations do not test whether an AI model chooses a good scope, detects every secret, follows every instruction or handles interactive staging well. Read the exact cases and version binding in the resource’s scenario record before relying on them.

For your own trial, record the resource checksum, Git version, intended paths, staged patch, hook output and final commit identifier. Keep private repository content out of a public report. The skill evaluation process provides a structure for distinguishing a planned trial from a reported outcome.

Sources

The upstream GitHub Awesome Copilot skill defines this workflow. Consult the primary Git diff reference, Git hook documentation, Conventional Commits specification and GitHub agent skill documentation for command and client behavior.