kh4f Workflow
- Analyze staged git changes
- Use any user note as supporting context for intent, motivation, or footer details
- Follow the commit message guidelines below
- Produce a commit message in a fenced
markdowncode block
Commit Message Guidelines
Style
- Use American English
- Use backticks for code entities and paths
- Preserve official capitalization of tech/brand names (e.g., Node.js, GitHub, Bun, tsdown)
Format
<type>(<scope>): <subject>
<body>
<breaking changes>
<footer>
<type>,<scope>, and<subject>are mandatory<body>,<breaking changes>, and<footer>are optional
Header
type
Pick the best match for the primary intent of the change:
feat: add a new user-facing capabilityfix: correct broken or incorrect behaviorrefactor: improve code or structureperf: improve performancestyle: change formatting, styling, or purely visual presentationchore: perform maintenance, dependency, tooling, or housekeeping workbuild: change build tooling, packaging, or bundling behaviortest: add or update testsci: change CI workflows or automationdocs: add or update documentation
scope
Choose the narrowest stable area that best describes the change.
Prefer a feature or subsystem name.
subject
The subject should be:
- imperative
- present-tense
- lowercase (except for proper nouns, acronyms, and official tech/brand names)
- concise and specific
- free of a trailing period
Prefer the outcome over implementation trivia. Good subjects usually start with verbs like add, fix, update, remove, refactor, rename, improve, and similar verbs.
Details
body
Skip the body if the header is self-explanatory.
Add a body when:
- the reason for the change is not obvious from the subject
- the behavior change needs a little extra context
- the user supplied motivation is worth preserving
BREAKING CHANGE
If the change is breaking:
- add
!before the colon in the header - add a
BREAKING CHANGE:section in the details
Use BREAKING CHANGE: only when the diff clearly introduces an incompatible API, config, CLI, output, or behavior change.
For multiple breaking changes, use bullet points after BREAKING CHANGE:.
footer
Add a footer when the user asks to include issue or PR references.
Typical footer verbs:
Fixes #123Closes #123Refs #123
Commit Message Examples
feat(playlist-sorting): auto-refresh grid on playlist rename
Monitor `browse/edit_playlist` requests and refresh the grid to reflect updated playlist names.
fix(changelog-gen): use correct content for `BREAKING CHANGES` section
Previously, when a commit had a `breakingChanges` property, the changelog would incorrectly display the commit's `subject` in the `BREAKING CHANGES` section instead of the actual `breakingChanges` content.
Fixes #123
test(cli): use `runCli` function instead of executing `dist/cli.js`
Remove the need for building the project before running tests.
feat(config)!: add support for multiple profiles with CLI `--profile` flag
BREAKING CHANGE: Changed alias for `prerelease` option to `P` to reserve `p` for the new `--profile` option.
Closes #123
refactor(config)!: simplify config by always reading current version from `package.json`
BREAKING CHANGE: The `packageFiles` option has been removed. The current version is now always read from `package.json`.
refactor(changelog-gen)!: replace `stdout` and `outputFile` options with unified `output`
BREAKING CHANGE: The `stdout` and `outputFile` options have been removed from changelog configuration. Use the new `output` option with `stdout` for console output or a file path string for file output.