Git Commit Creation
Contract
Create one atomic commit containing one logical change, only for an explicit user
request with a finite file or hunk scope. Resolve the repository, branch, scope, message policy, and
agent attribution before mutation. Preserve unrelated staged and unstaged changes; do not re-request
authorization already supplied.
Under this skill's house policy, stop on main, master, or repository-declared protected
branches. Branch creation or switching requires separate authorization. At any step, stop if
authorization, scope, or attribution is missing; resume only when the blocking condition is
resolved.
Workflow
1. Inspect Without Mutation
- Read applicable repository instructions. Inspect the root, branch, worktree, and index with
git rev-parse --show-toplevel, git branch --show-current, git status --short --branch, git diff, and git diff --staged. Record pre-existing staged content and remaining changes.
- Resolve
HEAD with git rev-parse --verify HEAD. Record its OID when it exists; otherwise
confirm an unborn branch before treating the next commit as a root commit. Other errors require
diagnosis.
2. Establish the Staged Scope
- Stage only authorized paths or hunks using explicit path arguments; do not stage a whole file when
authorization covers only part of its changes. Include pre-existing staged changes only when the
user explicitly included them.
- Run
git diff --staged --check and inspect git diff --staged. Proceed only if the staged diff
is non-empty, contains one logical change, and matches the authorized scope. If unrelated staged
content cannot be separated while preserving user work, ask how to scope the commit.
3. Commit and Verify
- Prepare the message using the policy below. Immediately before committing, confirm the recorded
HEAD and reviewed staged diff still match. Reassess any changes before proceeding.
- Pass the message through a file with
git commit -F <message-file>, preserving actual newlines.
- Check
git rev-list --parents -n 1 HEAD: the new commit must have exactly one parent equal to the
recorded OID, or no parents for an unborn branch. Verify the committed diff matches the reviewed
staged diff and the full message contains the required attribution exactly once.
- Inspect
git status --short --branch and report the new OID, summary, and remaining changes.
Report failures or mismatches without claiming completion or altering unrelated work.
Message
Follow repository instructions first. The following defaults are house policy, not Git requirements:
- Use Conventional Commit-style titles:
<type>(<scope>): <subject>; omit an uninformative scope. Use a concise imperative subject
without a trailing period, aiming for a title of 50 characters or fewer.
- Use
feat for features, fix for bug fixes, refactor for code restructuring without behavior
changes, docs for documentation, test for tests, and chore for maintenance.
- Omit the body when the title suffices. Otherwise separate it with a blank line and use concise
-
bullets under useful Problem:, Change:, and Rationale: sections. Add Alternatives: only
for meaningful rejected options or trade-offs. Omit empty sections and repeated points; wrap at
about 72 columns where practical.
- Include relevant issue references or breaking-change footers when applicable.
- Append exactly one current runtime-supplied attribution block, verbatim, after other footers. For
Codex, use
Co-authored-by: Codex <noreply@openai.com> unless the runtime supplies a different
block. For other runtimes, require their supplied attribution; if unavailable, request it before
committing. Do not invent identities, copy illustrative signatures, or combine runtime signatures.
Sources
1---2name: git-commit-creation3description: Create authorized, atomic Git commits with repository-compliant messages and current-agent attribution. Use only when the user explicitly asks to create a commit or to commit already-scoped changes. Do not use for requests limited to staging, status inspection, commit planning, or drafting a message.4---56# Git Commit Creation78## Contract910Create one [atomic commit][atomic-commits] containing one logical change, only for an explicit user11request with a finite file or hunk scope. Resolve the repository, branch, scope, message policy, and12agent attribution before mutation. Preserve unrelated staged and unstaged changes; do not re-request13authorization already supplied.1415Under this skill's house policy, stop on `main`, `master`, or repository-declared protected16branches. Branch creation or switching requires separate authorization. At any step, stop if17authorization, scope, or attribution is missing; resume only when the blocking condition is18resolved.1920## Workflow2122### 1. Inspect Without Mutation2324- Read applicable repository instructions. Inspect the root, branch, worktree, and index with `git25 rev-parse --show-toplevel`, `git branch --show-current`, `git status --short --branch`, `git26 diff`, and `git diff --staged`. Record pre-existing staged content and remaining changes.27- Resolve `HEAD` with `git rev-parse --verify HEAD`. Record its OID when it exists; otherwise28 confirm an unborn branch before treating the next commit as a root commit. Other errors require29 diagnosis.3031### 2. Establish the Staged Scope3233- Stage only authorized paths or hunks using explicit path arguments; do not stage a whole file when34 authorization covers only part of its changes. Include pre-existing staged changes only when the35 user explicitly included them.36- Run `git diff --staged --check` and inspect `git diff --staged`. Proceed only if the staged diff37 is non-empty, contains one logical change, and matches the authorized scope. If unrelated staged38 content cannot be separated while preserving user work, ask how to scope the commit.3940### 3. Commit and Verify4142- Prepare the message using the policy below. Immediately before committing, confirm the recorded43 HEAD and reviewed staged diff still match. Reassess any changes before proceeding.44- Pass the message through a file with `git commit -F <message-file>`, preserving actual newlines.45- Check `git rev-list --parents -n 1 HEAD`: the new commit must have exactly one parent equal to the46 recorded OID, or no parents for an unborn branch. Verify the committed diff matches the reviewed47 staged diff and the full message contains the required attribution exactly once.48- Inspect `git status --short --branch` and report the new OID, summary, and remaining changes.49 Report failures or mismatches without claiming completion or altering unrelated work.5051## Message5253Follow repository instructions first. The following defaults are house policy, not Git requirements:5455- Use [Conventional Commit-style](https://www.conventionalcommits.org/en/v1.0.0/) titles:56 `<type>(<scope>): <subject>`; omit an uninformative scope. Use a concise imperative subject57 without a trailing period, aiming for a title of 50 characters or fewer.58- Use `feat` for features, `fix` for bug fixes, `refactor` for code restructuring without behavior59 changes, `docs` for documentation, `test` for tests, and `chore` for maintenance.60- Omit the body when the title suffices. Otherwise separate it with a blank line and use concise `-`61 bullets under useful `Problem:`, `Change:`, and `Rationale:` sections. Add `Alternatives:` only62 for meaningful rejected options or trade-offs. Omit empty sections and repeated points; wrap at63 about 72 columns where practical.64- Include relevant issue references or breaking-change footers when applicable.65- Append exactly one current runtime-supplied attribution block, verbatim, after other footers. For66 Codex, use `Co-authored-by: Codex <noreply@openai.com>` unless the runtime supplies a different67 block. For other runtimes, require their supplied attribution; if unavailable, request it before68 committing. Do not invent identities, copy illustrative signatures, or combine runtime signatures.6970## Sources7172- [Git commit documentation source](https://github.com/git/git/blob/master/Documentation/git-commit.adoc)73 describes index-based commits, message files, and short titles separated from bodies by a blank74 line.75- [Git contribution guidance](https://github.com/git/git/blob/master/Documentation/SubmittingPatches)76 explains imperative subjects and motivation; these are Git project conventions.77- [GitHub co-author documentation](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors)78 documents co-author trailers; requiring agent attribution is this skill's house policy.7980[atomic-commits]: https://github.com/git/git/blob/master/Documentation/SubmittingPatches#separate-commits