| name | commit |
| description | Stage and commit changes following OpenStack git commit message guidelines. Use when the user wants to commit code changes. |
| disable-model-invocation | false |
| allowed-tools | Bash Read Edit Grep Glob |
| argument-hint | ["optional message hint"] |
OpenStack-Style Git Commit
Create a git commit following the OpenStack commit message guidelines
(https://wiki.openstack.org/wiki/GitCommitMessages).
User hint: $ARGUMENTS
Committer identity:
- Name: !
git config user.name
- Email: !
git config user.email
Step 1: Understand the changes
Run these in parallel:
git status (never use -uall)git diff and git diff --cached to see staged and unstaged changesgit log --oneline -10 to see recent commit style
Read changed files as needed to fully understand the change.
Step 2: Draft the commit message
Follow this structure strictly:
<subject line>
<body>
<footer>
Subject line rules
- Maximum 50 characters
- No period at the end
- Mention the affected component if applicable (e.g., "libvirt: ...")
- Use imperative mood ("Add feature" not "Added feature")
- Be specific, not vague ("Fix NPE in volume migration" not "Fix bug")
Body rules
- Separate from subject with a blank line
- Wrap all lines at 72 characters
- Explain what the problem was, why the change is needed, and how
the solution works
- The message must contain all information required to fully understand and review the patch
- Mention known limitations or future work if relevant
- "Less is not more. More is more." -- provide comprehensive context
- Do NOT include information only relevant to earlier patch iterations
Footer rules
Add relevant trailers, each on its own line, in this order:
DocImpact -- if documentation changes are neededAPIImpact -- if public HTTP APIs change (include reasoning)SecurityImpact -- if security review is warrantedUpgradeImpact -- if there are upgrade implicationsCloses-Bug: #NNNNNNN -- if this fully fixes a Launchpad bugPartial-Bug: #NNNNNNN -- if this partially fixes a bugRelated-Bug: #NNNNNNN -- if merely related to a bugStory: NNNNNNN / Task: NNNNN -- for Storyboard referencesImplements: blueprint <name> -- if implementing a blueprint
Only include trailers that are actually relevant. Do not invent bug numbers or references.
Always include the following trailers (in this exact order, Signed-off-by MUST be last):
Assisted-by: AGENT_NAME[:MODEL_VERSION]
Signed-off-by: <user name> <user email>
Assisted-by is required on commits created with the help of an AI coding
assistant.
AGENT_NAME is the name of the AI assistant that produced the change.
Identify yourself: if you are Claude, use Claude; another assistant uses
its own name.MODEL_VERSION is the exact model identifier you are running on (for
example claude-opus-4-8), appended after a colon. Include it only when the
exact identifier is directly available in your runtime context. Do not
inspect logs or configuration solely to determine it. Otherwise, omit
:MODEL_VERSION and emit AGENT_NAME alone rather than guessing.- An optional space-separated list of specialized analysis tools used (e.g.
coccinelle sparse) may follow. OSISM does not routinely use these, so
omit them unless one actually contributed.
- Concrete examples:
Assisted-by: Claude:claude-opus-4-8 (model known),
Assisted-by: Claude (model version unknown).
Signed-off-by is required on every commit. Obtain the name and email from git config user.name and git config user.email. The Signed-off-by line must always be the very last line of the commit message, after all other trailers.
Step 3: Structural check
Before committing, verify:
- There is only one logical change per commit (the cardinal rule)
- Whitespace changes are not mixed with functional changes
- Unrelated functional changes are not combined
- If the user's arguments (
$ARGUMENTS) contain hints, incorporate them
Step 4: Commit
- Stage relevant files by name (avoid
git add -A or git add .)
- Do NOT stage files that likely contain secrets (.env, credentials, etc.)
- Create the commit using a HEREDOC for the message:
git commit -m "$(cat <<'EOF'
Subject line here
Body here, wrapped at 72 characters.
Relevant-Trailer: value
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Full Name <email@example.com>
EOF
)"
- Run
git status after committing to verify success
- Show the user the final commit message
Important
- Ask the user before committing if the change seems to bundle multiple logical changes
- If pre-commit hooks fail, fix the issue and create a NEW commit (never amend)
- When amending a commit, the commit message must describe the full commit as
it stands after the amendment, not just the changes made in the amendment. Read
the existing commit message with
git log -1 and update it to reflect the
complete change.
- Never push unless explicitly asked
