Create a commit in a Git repository

Your user may invoke this skill explicitly with a slash command like /git:commit, or informally with a phrase like "commit this". If they use a loose instruction like "commit this" your first task is to determine whether you are working in a Git repository and should make a Git commit (using this /git:commit skill), or you are working in a Jujutsu repo and should create a Jujutsu commit (using the /jj:commit skill).

Creating Git commits

The most common case will be creating a commit in a Git repository. Usually, you will include all changes in the working directory in the commit (that is, you should run git diff to see what the changes are, and/or git diff --staged to see what has already been staged). Generally, if your user wants you to commit only a subset of the changes in the working directory, they will instruct you to do so.

Creating Jujutsu commits

Less frequently, you will find yourself in a Jujutsu repository (which you can determine via the presence of a .jj directory in the repository root). In Jujutsu repositories you should use the /jj:commit skill to create commits. For general information on Jujutsu, see the /jj:version-control skill.

Common instructions

1. Run the appropriate Git-specific or Jujutsu-specific commands to see what should be included in the commit.
2. Note that your user may have asked you to create or update "plan" files under .claude-notes/, a directory which may be ignored via the global ~/.config/git/ignore file: these plan files should never be included in a commit as they are intended to be local-only aids to development.
3. Create a commit message with:
   • A subject of 72 characters or less in Conventional Commits format (eg. "docs: add migration notes" or "fix: avoid double-render in list component"). In repositories that make use of scopes, you can include a scope in parentheses (eg. "chore(frontend): update copyright year" or "feat(login): add support for magic links").
   • A blank line.
   • A detailed description, wrapped to 72 characters, using basic Markdown syntax.
   • At the bottom, include the full text of all prompts that were used while preparing the changes that led to the commit; never omit any prompts.
   • If you were involved in the preparation of the changes, include a commit trailer of the form: "Co-Authored-By: Claude noreply@anthropic.com" (after "Claude", include the actual model name and version if it is available to you from the system prompt).

Best practices

• Subjects MUST start with a Conventional Commits type (eg. "docs", "fix", "feat", "chore" etc; see the table below for a full list) followed by a statement beginning with a verb (eg. "add", "remove", "rename" etc). The subject describes what the commit does.
• The body should explain the motivation for the change, and why the solution was chosen.
• Note alternatives which were considered but not implemented.
• Include references to previous commits or other artifacts (documentation, PRs) that are relevant.

Conventional Commits types

Example

refactor: remove unused `recurse` setting

We were never exposing a user-accessible setting here. It is always `true`
in practice, except in the benchmarks where we offered an override via the
environment.

If there is ever a call for this in the future, we can resurrect it, but
for now, leaving it out presents us with an opportunity to simplify.
It may even be a tiny bit faster (1.3% better CPU time, and 2.4%
better wall time), with reasonable confidence, due to saving us some
conditional checks.

Agent prompts used in preparing this commit:

> Search the codebase and confirm that the `recurse` setting isn't used
> anywhere outside of the benchmarks, where it is hardcoded to `true`.
> Once you've confirmed that, remove all traces of the setting. Run the
> benchmarks to see they still work, and the tests to see they still pass.