| name | hdb-commit-msg |
| description | Use when creating a new commit, making a commit, committing changes, or writing a commit message in node-hdb. |
hdb-commit-msg
Generates a well-formatted git commit message for node-hdb following project conventions. Always confirms the message with the user before committing.
When to Use This Skill
- User asks to make a new commit or commit changes
- User asks to write or generate a commit message
- User says "let's commit", "I want to commit", "commit this", or similar
- User asks to amend a commit or update a commit message
Workflow
-
Run git status to check staged and unstaged changes
-
Determine what to commit:
- Staged files exist: use them as-is
- No staged files, user specified files explicitly: stage those files with
git add
- No staged files, user described the change: infer relevant files from the description and
git status, show them, and ask — "I'll stage these files: [list]. Does that look right?" — wait for confirmation, then stage
- No staged files, no files or description mentioned: stage all changed files with
git add -A
-
Run git diff --staged to analyze the staged changes
-
Infer the commit type from the diff (see Types below)
-
Use no scope by default unless the user specifies one
-
Ask: "Does this commit relate to a public issue? If so, what's the issue number?"
-
Draft the commit message (header + body)
-
Show the full message, then ask:
"Does this commit message look good?"
- Yes, commit
- Suggest changes
-
On option 1, commit using a heredoc to preserve formatting:
git commit -m "$(cat <<'EOF'
[TYPE](#issue)(scope) <summary description>
Relates to issue [#N](https://github.com/SAP/node-hdb/issues/N)
- <change 1>
- <change 2>
EOF
)"
(Omit (#issue) and the Relate to line together if no public issue; omit (scope) if no scope.)
On option 2, apply the suggestion, revise, and re-ask
Commit Message Guidelines
Format
[header line]
[body]
The header and body are separated by a blank line.
Header Line
[TYPE](#issue)(scope) <summary description>
(#issue) and (scope) are both optional and independent- No period at end of header line
- Brief and accurate; aim for under 72 characters but longer is fine if needed
Examples from this repo:
[FEATURE](stmt distr) add topology update records in reply[INTERNAL] refactor vars to const/let in Connection.js[FIX] fix failing compression unit-test after removing packet size checking[FIX](#42) correct type mapping for DECIMAL columns — with public issue[FIX](#42)(datatype) correct type mapping for DECIMAL columns — with both
Body
Use bullet points to summarize notable changes — include what changed and why/benefit, skip trivial or self-explanatory edits.
- <change 1> [and why/benefit if non-obvious]
- <change 2> [and why/benefit if non-obvious]
Example:
- add SystemInfo class to store and update connection topology information
- remove redundant _connect() method from Connection as it's now handled by PhysicalConnection
Types
Mutually exclusive — one per commit:
| Type | When to use |
|---|
FEATURE | New feature visible to users or callers |
FIX | Bug fix |
TEST | Adding or updating tests only |
DOC | README.md changes only |
INTERNAL | Non-functional changes, refactoring, comments |
RELEASE | Version bumps, release assembly |
INFRA | Build or test infrastructure only |
Rules
- Imperative mood throughout — use the base verb form for header and every body bullet (e.g., "add" not "added"/"adds", "remove" not "removed"/"removes")
- No AI attribution footers (
Co-Authored-By: Claude, 🤖 Generated with...)
Interactive Prompts
-
Scope: No scope by default; only include if the user specifies one
-
Public issue reference: Ask the user if the commit relates to a public issue before drafting. Only applicable for [FIX] (bug label) and [FEATURE] (enhancement label) commits. If yes, include (#issue) in the header and a Relates to line as the first line of the body:
[FIX](#42)(stmt distr) correct type mapping for DECIMAL columns
Relates to issue [#42](https://github.com/SAP/node-hdb/issues/42)
- fix DECIMAL type mapping to return correct JS number
(#issue) and (scope) are both optional and independent — include neither, either, or both as appropriate.
-
Breaking changes: If the diff suggests a breaking API/behavior change, ask the user to confirm, then include (BREAKING CHANGE) on its own line in the body
-
Multi-area changes: If changes span clearly unrelated areas, suggest splitting into multiple commits before proceeding
